Skip to main content

Content and Access policy attributes

Both policy resources require exactly one match representation. module uses Policy-as-code. conditions uses the complete native condition language as native HCL objects, tuples, and values. No JSON encoding or escaping is needed. Shared attributes are:

Native condition language

Every condition is one HCL object. A predicate compares one canonical field:
Use all when every child must match, any when at least one must match, and not to invert one child. all and any each accept 1–64 condition objects. Trees may contain at most 512 nodes and 16 levels.
Predicate properties are exact; extra properties are rejected:

Field catalog

Terraform accepts the same canonical native-condition fields as the policy engine. The catalog is grouped by namespace so plans remain readable: See Conditions for every accepted field, its exact type, meaning, availability, and the separate Access catalog. A field from the other policy family is rejected. Content policies additionally support history-aware operators: within must be a positive integer followed by s, m, h, or d, such as 30s, 15m, 12h, or 7d, and cannot exceed 30 days. Count op is eq, gt, gte, lt, or lte; count value is an integer from 0 through 1,024.
The provider validates structure, family fields, enums, limits, durations, and regular expressions locally. Forge then applies the complete policy contract and runtime type rules authoritatively during the resource write. This second check prevents an older provider from weakening or reinterpreting a newer server contract.

forge_content_policy

The response checkpoint is endpoint- and capability-dependent. The LLM Gateway does not provide it. Timing constraints still apply: approval is pre_tool only, filtering is post_tool only, and path redaction is pre_tool or post_tool only.

forge_access_policy

Content and Access expose only their own family attributes. Terraform rejects cross-family fields instead of silently discarding or retaining them as null state.

Content Rego example

The complete action, evaluation-point, and action-specific attribute semantics are defined in forge_content_policy. Invalid cross-field combinations fail planning or server validation.

Readable references

Use exact user email and exact group, product, agent, route, MCP server/tool, or skill name/slug. Forge resolves names authoritatively. Missing and ambiguous matches fail apply rather than choosing arbitrarily. Forge retains the resolved bindings while refresh preserves readable configuration. Every policy resource with user or group subjects can disambiguate duplicate directory labels without putting a Forge object ID in configuration:
group_directory_ids works the same way for configured group names. Every map key must also appear in its matching users or groups set; empty qualifiers and unsupported names fail before mutation. Most organizations should omit these maps and use the concise unique email/name form. The same fields are available on MCP ACLs and skill ACLs. Policy id is different: it is a user-chosen durable key, immutable after creation and never reusable after deletion. Choose a stable, descriptive slug.

Import

Policy resources import by their durable policy ID:
Import reads the remote definition but does not claim authority. For a Forge-managed policy, first apply a matching forge_policy_authority resource at the exact reviewed revision, then import the policy into the same Terraform manager. After import, run a connected terraform plan and reproduce the complete remote scope, condition or module, action, and action-specific configuration in HCL. Omitted attributes are desired changes, not instructions to preserve unknown remote configuration.