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

# Actions

> Policy outcomes, checkpoint compatibility, precedence, and failure behavior.

An action is the typed consequence of a matching policy. Match logic returns a
boolean result; it cannot invent or execute an action.

## Action reference

| Action             | Content | Access | Result when the policy matches                                                         |
| ------------------ | ------- | ------ | -------------------------------------------------------------------------------------- |
| `allow`            | Yes     | Yes    | Permits the operation and records the hit; never overrides a stronger matching action  |
| `nudge`            | Yes     | No     | Permits the operation and returns advisory context through a capable inline adapter    |
| `flag_for_review`  | Yes     | Yes    | Permits the operation and records it for subsequent review                             |
| `redact`           | Yes     | No     | Replaces the whole value or selected structured paths before the next processing step  |
| `filter`           | Yes     | No     | Removes matching elements from a structured post-tool collection                       |
| `require_approval` | Yes     | Yes    | Pauses or denies the pending operation until the required scoped approval grant exists |
| `block`            | Yes     | Yes    | Prevents the operation at an enforcement-capable control point                         |

At an observe-only source, Forge can record a policy hit but cannot
retroactively alter a completed action.

## Content compatibility

| Action                   | Valid checkpoints                 | Additional configuration                  |
| ------------------------ | --------------------------------- | ----------------------------------------- |
| `allow`                  | Any selected checkpoint           | None                                      |
| `block`                  | Any selected checkpoint           | Optional `message`                        |
| `flag_for_review`        | Any selected checkpoint           | None                                      |
| `nudge`                  | `prompt`, `pre_tool`, `post_tool` | Optional `message`; invalid at `response` |
| `require_approval`       | Exactly `pre_tool`                | `approval`; optional `message`            |
| Whole-value `redact`     | Any selected checkpoint           | `redaction`                               |
| Structured-path `redact` | `pre_tool`, `post_tool`           | `redaction.paths`                         |
| `filter`                 | Exactly `post_tool`               | `filter`                                  |

Invalid action/checkpoint combinations are rejected when the policy is saved.
See [Redaction](/secure/redaction) for transformation inputs and outputs.

## Approvals

Content approval policies run before tool execution. Their `approval` object
accepts:

| Field                  | Type    | Meaning                                                                        |
| ---------------------- | ------- | ------------------------------------------------------------------------------ |
| `autoApproveOnRequest` | boolean | Issues the scoped grant immediately after the user submits an approval request |

Access approval policies require:

| `mode`           | Meaning                                                          |
| ---------------- | ---------------------------------------------------------------- |
| `admin_approval` | An authorized administrator must approve access                  |
| `self_serve`     | The requester can complete the supported self-service grant flow |

Approval grants are bound to the policy ID and immutable revision. A grant for
an older revision does not authorize a changed policy.

## Nudges

A nudge does not interrupt the operation. Supported gateway and endpoint
adapters insert guidance into the next supported model request. If a source
cannot inject context, Forge retains the hit without modifying the completed
operation.

`nudge` is invalid at `response` because there is no later model step to receive
the guidance.

## Multiple matches

Forge retains all matching hits and chooses the strongest action:

```text theme={"system"}
block
  > require_approval
  > filter
  > redact
  > flag_for_review
  > nudge
  > allow
```

An `allow` policy therefore cannot cancel a block from another policy.
Overlapping redactions use their own strategy precedence, documented under
[Redaction](/secure/redaction#redaction-strategies).

## Defaults

| Family or surface              | No matching policy |
| ------------------------------ | ------------------ |
| Content                        | `allow`            |
| Content on MCP access surfaces | `block`            |
| Access                         | `allow`            |
| Skill Registry ACL             | `block`            |

MCP Registry and Skill Registry access rules are managed from the
[MCPs](/enable/mcp-requests) and [Skills](/enable/skill-requests) pages, then
evaluated through their policy-backed access controls.

## Failures

A native condition that depends on unavailable facts does not match and emits
a `fields_unavailable` diagnostic. A Rego policy that is malformed, times out,
returns undefined, or produces invalid output fails closed with `block`.

Every hit includes the policy ID and immutable revision. Native evaluation can
also report matched exceptions and unavailable fields; Rego can return a stable
reason code and bounded evidence.