Skip to main content
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.

​
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

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

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 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 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 and Policy 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.

​
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, Examples, and the exact Terraform resource.