Overview

Forge policies define what people and agents can access, what data and actions are allowed inside AI workflows, and what happens when a rule matches. Policies are evaluated across routed endpoints, networks, providers, and Forge gateways so the same control follows activity across your AI estate.

​

Policy types

Forge has three organization-authored policy types:

​

Content policies

Content policies evaluate the data and actions inside an AI workflow at one or more checkpoints: Content policies can use identity, agent, product, model, MCP, classification, tool input, tool result, and response context when the enforcing surface provides it. The response checkpoint depends on the routed API surface and its response adapter.

​

Access policies

Access policies govern the routes and software through which AI is reached. They can evaluate:

• AI products and providers
• destinations and network routes
• processes and local runtimes
• browsers, extensions, and account posture
• users, groups, and devices
• source health and available enforcement capabilities

Access decisions can run through a supported endpoint or Forge network inspection path. Provider forwarding configuration selects traffic for that path; it does not substitute provider-native rules for Forge policy. A policy may also authorize a specific remediation, such as terminating a process, clearing site data, disabling an extension, or repairing a managed configuration.

​

Resource policies

Resource Policies govern connections and protocol operations for configured HTTP, HTTPS, PostgreSQL, MySQL, and Redis Resources. They can scope by authenticated user, group, service account, device, and Resource; match supported HTTP request or PostgreSQL, MySQL, or Redis command facts; enforce or monitor; and return a clear policy message when an operation is blocked or needs approval. They can redact bounded HTTP JSON request and response bodies, filter HTTP response arrays, and redact or filter supported PostgreSQL and MySQL results before delivery. They are not a lightweight Access-policy mode. Resource is a complete third authoring family over the same condition, outcome, exception, revision, Rego, backtest, and ownership systems. Its own field and action catalog follows the capabilities of each protocol. Protocol data controls reuse existing transformation and approval machinery where the semantics match. Resource Policies apply to customer-deployed Resource Gateways and automatic endpoint routing through the same proxy path. See Resource policies for setup, credentials, supported protocol depth, and activity.

​

Policy anatomy

Every policy contains:

1. A durable id, display metadata, and enabled state.
2. A typed scope defining the identities and assets to which it applies.
3. Native conditions or bounded Rego match logic.
4. An optional exception tree that suppresses an otherwise valid match.
5. A typed action such as block, redact, or require_approval.
6. Family-specific configuration for evaluation points, transformations, approvals, runtime detection, notifications, or remediation.

Forge records every matching policy and its immutable revision. When multiple policies match, all hits remain visible and the strongest compatible action determines the final outcome.

​

Enforcement

Policy behavior depends on the capabilities of the surface evaluating it. A routed endpoint, network control, or gateway can stop a pending action; an observe-only source can record the same match but cannot retroactively prevent completed activity. Forge validates family, checkpoint, action, and remediation compatibility when the policy is saved.