Skip to main content
Responses is the workspace for governance decisions created by policies and controlled AI activity. Its four tabs represent different parts of the same response lifecycle:
Registry security reviews use separate workflows. Use the Registry’s MCPs and Skills views for catalog state, then see MCP requests and Skill requests for request and publication status.

​
Decisions

Decisions contains work that needs a business owner or security response. Requests can be created when a policy requires approval or an exception before activity continues, including governed access and tool actions. The Mine view contains requests routed to you. Users with policy-management access can select All to inspect organization-wide governance requests and review records. Each assigned request can include:
  • Request type, requester, assigned owner, source, creation time, and requested scope.
  • The policy or AI system responsible for the request.
  • A description of what happened.
  • Access evidence or a compact session trace.
  • The matched policy and links to the policy, session, or related review.
Forge displays only the actions and scopes encoded by the request’s action model. A submitted request can offer Approve, Deny, or both. Approval scope can be a single invocation, the current session, or a route when the originating workflow supports that scope. Resource approvals use one exact connection, HTTP request, database command, or Redis command retry rather than a session or broad Resource grant. Some requests also include policy-provided remediation options. Selecting an option authorizes that cleanup along with the approval; approving the request alone does not select cleanup.

​
Verify an approve-once decision

  1. Send a narrow gateway request that is expected to match the approval policy. For LLM Gateway traffic, include a stable client-generated X-Forge-Session-Id value.
  2. Confirm the gateway returns 403, X-Forge-Policy-Outcome: approval_required, and an approval_request_id in the error body.
  3. Open Responses > Decisions, select the matching submitted request, and choose Allow retry once. Add a decision note when your audit policy requires one.
  4. Confirm the request is Approved and its grant appears as Active.
  5. Retry the identical gateway request with the same client-generated session value. Confirm it succeeds with X-Forge-Policy-Outcome: allowed.
  6. Confirm the grant becomes Used. A later matching invocation should require a new decision.
The LLM Gateway response also returns a server-issued X-Forge-Session-Id for observability. Do not send that server-issued value as the client hint on the retry; reuse the exact value supplied on the original request. See LLM Gateway session continuity.

​
Verify a Resource approval

Resource approvals use an exact retry instead of holding a client connection or database transaction:
  1. Send a connection, HTTP request, PostgreSQL or MySQL command, or Redis command that matches a Resource approval policy. Confirm it is not forwarded and the client shows the policy explanation and approval reference.
  2. Open Responses → Decisions, open that reference, and approve or deny it.
  3. Approval creates a ten-minute, one-use grant for the exact identity, Resource, protocol operation, and matching policy revisions.
  4. Retry the identical operation. A valid grant is consumed before forwarding.
  5. Confirm the decision and grant in Responses and the approval-required attempt plus successful retry in Live → Resources.
Changing the request, command, caller, Resource, or policy revision requires a new approval. The client receives a protocol-appropriate policy error and retries the connection or command after approval.

​
Requests

Requests is history, not another reviewer queue. It combines requests visible from the requester or subject perspective:
  • MCP server or MCP tool access requests.
  • Governance approval and exception requests created for controlled activity.
The list shows the request, type, subject, normalized status, and last update. Mine includes requests submitted by you, requests that include you as an MCP subject, and governance requests created for your activity. Authorized reviewers can use All for organization-wide history. Opening a request shows the fields available for its source. MCP requests can include the business case, requested tools, users and agent apps, urgency, expiration, scanner results, reviewer, and decision. Governance requests can include the policy, action, scope, source, requester context, decision, and resulting grant. MCP requests can expose Request extension or Request again after an approval, expiration, denial, or failed request. The new request is prefilled from the earlier request.

​
Grants

An approved governance request can create a grant. A grant is the stored authorization that a later policy evaluation can match; it is not a change to the underlying policy. A grant records:
  • Its originating request, kind, and status.
  • Approved scope and match key.
  • Policy, user, session, event, or route context when present.
  • Resource and exact-operation context when the request came from Resource traffic; the private operation digest is not displayed.
  • Source integration and justification.
  • Creation and expiration times.
Grant lifecycle states include Active, Used, Expired, and Revoked. Policy managers can revoke an active grant. An expired, consumed, or revoked grant no longer represents active authorization.

​
Session controls

Session controls contains interventions associated with agent sessions. The page separates active and cleared controls and shows the session, user, source integration, control mode, reason, status, and last update. Opening a control shows its session and source context, mode, status, and stop reason. Users with organization-management access can clear an active intervention. Clearing records the control as cleared; it does not erase its history. Responses and Violations are related but not interchangeable:
  • A Violation records a policy or governance outcome that was configured to create a violation.
  • A decision records work requiring a response.
  • A grant records authorization created by approval.
  • A session control records an intervention applied to a session.
One governed event can produce more than one of these records, depending on the policy action and workflow.