Skip to main content
Use the Console policy editor to start with the people, AI systems, and activity you intend to govern, then choose the narrowest conditions and outcome that meet the requirement.

​
Choose a policy type

Create a Content policy for prompts, model responses, tool inputs, tool results, classifications, or MCP activity. Create an Access policy to govern whether a user, group, device, process, account, provider, or AI product can be used. Create a Resource policy to govern connections, HTTP requests, or PostgreSQL commands for configured Resources.

​
Define the scope

Select the identities and assets the policy should cover. Content offers service accounts, agents, products, MCP servers, and tools; Access offers users, groups, and devices alongside AI route conditions; Resource offers users, groups, service accounts, devices, and Resources. A directory group expands to its resolved members during evaluation; verify directory sync before relying on a new group. Keep the first scope narrow enough to test with a known identity and real activity. Scope determines where the policy applies; conditions determine whether an in-scope event matches.

​
Build match conditions

Use All when every condition must match and Any when one matching branch is sufficient. Conditions can use identity and product context as well as observed prompt, tool, response, model, destination, process, and classification fields. For sensitive-data controls, select the data labels Forge should match and the checkpoint where the data is available. For behavior that develops over time, use a prior-session condition such as a prior matching event, a sequence of events, or a count within a time window. Add an exception only when a narrower case should suppress an otherwise valid match. Exceptions do not create an allow that overrides another policy. Select Edit policy as code when a reviewed native condition tree or bounded Rego rule is easier to maintain in code. The visual editor and policy-as-code view describe the same saved policy rather than separate enforcement paths.

​
Select an outcome

Available outcomes depend on the policy type and evaluation checkpoint:
  • Allow records the match without overriding a stronger policy.
  • Nudge adds guidance when the enforcing surface can deliver it.
  • Flag for review allows the activity and records it for review.
  • Redact replaces sensitive content before it continues.
  • Filter removes matching items from a supported tool result.
  • Require approval holds supported activity until an allowed approval scope is granted.
  • Block prevents the operation at an enforcement-capable control point.
Forge prevents unsupported policy, checkpoint, and outcome combinations from being saved. See Actions for the compatibility reference. Resource Policies additionally choose Enforce or Monitor. Monitor keeps the policy enabled and records what it would have done without changing the connection, request, or command. Resource authoring uses the same nested condition groups, operators, named exceptions, messages, revisions, policy-as-code option, and backtest workflow as the other families. The editor narrows fields and actions to capabilities that every selected Resource protocol can execute. For Resource redaction or filtering, choose HTTP request body, HTTP response body, or PostgreSQL results. This data target says what Forge changes and does not add a generic evaluation-stage control. Request bodies can be redacted; response bodies and PostgreSQL results can be redacted or filtered. For Resource approval, choose administrator approval or requester confirmation. The editor rejects approval conditions that require response or result data. Prior-activity, sequence, count, and distinct-value conditions are available for bounded facts from the same authenticated Resource connection. Do not use them as a cross-connection or organization-wide rate limit.

​
Test before broad enforcement

  1. Save the policy disabled or scope it to a pilot identity.
  2. Run a backtest against compatible historical evidence.
  3. Review matches, unavailable fields, and exceptions.
  4. Enable the policy for the pilot.
  5. Wait for enforcement activation. If the editor shows Saved — activating…, refresh after a moment and do not run the acceptance test until the activation notice is gone.
  6. Generate fresh activity through the intended gateway, endpoint, or integration.
A backtest shows how the policy evaluates retained evidence; it does not prove that a live source can enforce the selected outcome. Resource backtests do not contain HTTP bodies, PostgreSQL or MySQL row values, or Redis arguments and replies, so they cannot preview exact transformed output. Policy API mutations use 202 Accepted and the X-Forge-Gateway-Authority-Propagation: propagation_pending response header when the definition is stored but gateway enforcement is still updating. In that case, wait before sending the live canary. Repeat the same narrow canary until it returns the intended policy outcome, and retain the policy revision and request ID with the test result.

​
Verify the result

For Content and Access activity, open the resulting Session to confirm the identity, source, event, policy, and outcome. For Resource traffic, open Live → Resources and expand the connection, request, or command. Check Violations for occurrences configured to create a violation. For supported approval policies, complete the decision in Responses and confirm the resulting grant and retried activity. If the policy does not match, first check source coverage, resolved identity and group membership, the selected checkpoint, and unavailable fields. If it matches but does not change the activity, confirm that the source supports enforcement for that outcome. Continue with Policy use cases, Resource policies, Linux access support, Conditions, Examples, and Lifecycle for the complete reference.