> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Author policies

> Create, test, and verify Content and Access policies in the Forge Console.

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](/secure/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](/secure/conditions), [Examples](/secure/examples),
and [Lifecycle](/secure/lifecycle) for the complete reference.