Actions

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	Resource	Result when the policy matches
`allow`	Yes	Yes	Yes	Permits the operation and records the hit; never overrides a stronger matching action
`nudge`	Yes	No	No	Permits the operation and returns advisory context through a capable inline adapter
`flag_for_review`	Yes	Yes	Yes	Permits the operation and records it for subsequent review
`redact`	Yes	No	Yes	Replaces the whole value or selected structured paths before the next processing step
`filter`	Yes	No	Yes	Removes matching elements from a supported structured collection
`require_approval`	Yes	Yes	Yes	Denies the first attempt and permits one exact retry after the required grant exists
`block`	Yes	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.

Resource compatibility

Resource Policies use the same outcome aggregation, precedence, policy messages, exception handling, revision binding, and activity evidence as other families. The actions exposed for a Resource are capability-gated:

Resource boundary	Supported actions
Connection	`allow`, `flag_for_review`, `require_approval`, `block`
HTTP request	`allow`, `flag_for_review`, `require_approval`, `block`
HTTP request body	`redact`
HTTP response body	`redact`, `filter`
PostgreSQL command	`allow`, `flag_for_review`, `require_approval`, `block`
PostgreSQL result	`redact`, `filter`
MySQL result	`redact`, `filter`

Resource redact and filter require a compatible dataTarget. Resource approval requires an approval mode and cannot depend on response or result data. Invalid combinations are rejected for native conditions and Rego-backed policies. For one operation, Forge resolves block or approval before mutation. Otherwise filters compose before redactions. Overlapping redactions use the strategy precedence below. Monitor-mode transformations and approvals are recorded but never enter the applied action plan.

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

Resource approval uses the same two modes. Its grant expires after ten minutes, can be used once, and permits only an identical retry of the connection, request, or command that created it. Forge does not hold an HTTP stream, database connection, or transaction while approval is pending. 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:

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.

Defaults

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

MCP Registry and Skill Registry access rules are managed from the Registry’s MCPs and Skills views, then evaluated through their policy-backed access controls. See MCP requests and Skill requests for the related review workflows.

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.

Get started

Observe

Secure

Enable

Integrations

Resources

Action reference

Resource compatibility

Content compatibility

Approvals

Nudges

Multiple matches

Defaults

Failures

​Action reference

​Resource compatibility

​Content compatibility

​Approvals

​Nudges

​Multiple matches

​Defaults

​Failures

Action reference

Resource compatibility

Content compatibility

Approvals

Nudges

Multiple matches

Defaults

Failures