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

# Resource policies

> Control Resource connections, operations, and supported data transformations.

Resource Policies protect authenticated HTTP, PostgreSQL, MySQL, and Redis
traffic. Direct gateway access and automatic routing share the same rules;
originating-product conditions apply only when a managed endpoint supplies that
proof.

Resource is a separate policy family on Forge's shared policy engine. It uses
the same condition groups and operators, exceptions, ownership, revisions,
backtests, monitor mode, Rego runtime, and approval workspace as Access and
Content. Only its scope, fields, and protocol-safe actions differ.

| Policy family | Purpose |
| - | - |
| Access | AI products, applications, processes, domains, and routes |
| Content | Prompts, model responses, agent tools, MCP calls, and tool results |
| Resource | Resource connections, HTTP requests, database commands, and supported data |

## Author a policy

1. Open **Policies**, choose **New policy**, then select **Resource**.
2. Scope it to Resources and, when needed, users, groups, service accounts,
   devices, or proven processes.
3. Build conditions from the fields supported by the selected protocols.
4. Choose an action and add a useful customer message for a block or approval.
5. Use **Monitor** to observe matches or **Enforce** to apply the action.
6. Add a narrow exception if needed, run a backtest, then save and enable it.

The editor shows only fields and actions supported by every selected Resource.
An empty scope applies across the organization.

## Resource fields

| Activity | Fields |
| - | - |
| Connection | Resource, protocol, authenticated user, groups, service account, device, destination hostname, proven process, and originating products |
| HTTP request | Method, path without query parameters, and normalized content type |
| PostgreSQL command | Database, requested database user, command, schemas, tables, and literal-free query pattern |
| MySQL command | Database, destination user, command, tables, and literal-free query pattern |
| Redis command | Logical database, destination ACL user, and uppercase top-level command |

Evaluation timing is inferred from the fields. Connection fields run before a
connection opens. HTTP fields run for each request. Database and Redis fields
run before each command. There is no separate evaluation-stage setting.

### Product

For automatically routed traffic, the device walks a bounded process ancestry
and matches each process against Forge's product catalog. `product.id` contains
every unambiguous recognized product in that chain. If Claude Code starts from
Codex, for example, a policy selecting either product matches. Forge discards
ambiguous matches rather than choosing one arbitrarily.

Direct Resource gateway clients do not provide trusted endpoint process
context, so `product.id` is unavailable. A policy that requires an originating
product does not match that traffic; policies scoped by Resource, identity,
protocol, or operation continue to evaluate normally.

HTTP bodies and database result values may be transient transformation inputs,
but they are not condition fields or retained activity. Query parameters,
authorization values, cookies, raw SQL, comments, bind values, Redis arguments,
and credentials are also excluded.

## Actions

| Target | 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 results | Redact, filter |
| MySQL command | Allow, flag for review, require approval, block |
| MySQL results | Redact, filter |
| Redis command | Allow, flag for review, require approval, block |

Redaction and filtering require exactly one supported data target. Forge
rejects a target or action that all selected Resources cannot execute. See the
individual [protocol guides](/resources/protocols/overview) for transformation
limits and fail-closed behavior.

**Allow** records a match without overriding a stronger result. **Flag for
review** permits the operation and highlights it. **Block** stops the operation
before it reaches the destination. Action precedence follows the shared
[Actions](/secure/actions) contract.

## Conditions, exceptions, and history

Resource rules use the shared nested **All**, **Any**, and **Not** groups and
type-checked operators. A named exception has its own reason and optional
expiration and suppresses only its containing policy. See
[Conditions](/secure/conditions) and [Policy lifecycle](/secure/lifecycle).

Policies can also evaluate bounded prior activity from the same authenticated
Resource connection, including sequences, event counts, and distinct-value
counts. This supports rules such as repeated writes or a read followed by a
write within one database connection. It is not an organization-wide rate
limit.

## Approval and retry

Forge does not keep a connection or transaction open while a person responds.
The first matching operation is not forwarded and creates a request in
**Responses**. An approval creates a ten-minute, one-use grant bound to the
identity, Resource, exact operation, matching policy revisions, and device,
process, and originating-product set when available. The client retries the
same operation to consume it.

A changed identity, Resource, operation, or policy revision needs a new
decision. Approvers see the Resource, protocol, and a bounded operation: method
and path for HTTP, literal-free query pattern for PostgreSQL and MySQL, or the
top-level Redis command. See [Activity and approvals](/resources/activity-and-approvals).

## Backtests and policy as code

Backtests replay retained Resource Activity and can be narrowed by Resource or
protocol. They can prove matching and intended outcomes, but cannot reconstruct
unretained bodies, rows, or transformed values.

Resource Policies support the same Rego entry point and decision contract as
other policy families. Use built-in conditions for ordinary rules and Rego for
logic the visual builder cannot express. See [Policy as code](/secure/rego),
[Examples](/secure/examples), and the exact
[Terraform resource](/developer/terraform/forge-resource-policy).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.