Skip to main content
Every served Resource connection or operation produces Resource Activity. Open Live → Resources to search the current page and filter by Resource, protocol, outcome, or policy. Search can also match the visible identity and operation text. Expand a row to see the policy decision and safe protocol details.

​
Activity details

Forge records the information needed to explain an enforcement result without turning the control plane into a copy of protected data. Each row can also show Resource, authenticated user or service account, device and proven process when available, outcome, responsible policy, and policy-check duration. Forge does not expose credentials, authorization values, cookies, query parameters, raw SQL, comments, bind values, HTTP bodies, or database result values in Resource Activity. Resource Activity follows the organization’s security-record retention period. Approval requests, decisions, grants, Resource and gateway changes, credential rotation, policy revisions, and retention changes also emit organization audit events. Preservation holds pause eligible cleanup. See Privacy and retention and Audit Log.

​
Approval lifecycle

Resource Policies support Administrator approval and Requester confirmation. Forge does not keep a connection or transaction open while a person responds.
  1. The first connection, HTTP request, or database command is not forwarded.
  2. The client receives the policy identifier, configured message, and approval reference. Forge creates or reuses one pending request in Responses.
  3. The requester and approver see the Resource, protocol, and bounded operation. HTTP shows the method and path. PostgreSQL and MySQL show a literal-free query pattern such as UPDATE orders SET status = ? WHERE id = ?.
  4. Approval creates a ten-minute, one-use grant bound to the identity, Resource, operation, matching policy revisions, and device and process when available.
  5. The client retries the same operation. The Gateway consumes the grant before forwarding it.
A changed operation, identity, Resource, or policy revision needs a new decision. HTTP receives a retryable policy response. PostgreSQL and MySQL receive a recoverable policy error and must retry the command or connection. Redis returns an explicit command error and the client retries the command.

​
Backtest before enforcement

From a Resource Policy, run Backtest against retained Resource Activity and narrow it by Resource or protocol. A backtest shows which historical operations would match and the intended outcome. It cannot reconstruct HTTP bodies, database rows, or transformed values because Forge does not retain them. For a gradual rollout:
  1. Save the policy in Monitor.
  2. Review matches under Live → Resources.
  3. Add a narrow, explained exception if required.
  4. Backtest the revised policy.
  5. Change it to Enforce and repeat a customer-style client test.
See Resource Policies for authoring and Responses for the shared decision workspace.