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.

​
Define the scope

Select the users, groups, service accounts, agents, products, providers, MCP servers, or tools the policy should cover. 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.

​
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. 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.

​
Verify the result

Open the resulting Session to confirm the identity, source, event, policy, and outcome. Check Violations for occurrences configured to create a violation. For 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 Conditions, Examples, and Lifecycle for the complete reference.