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

# Responses

> Resolve governed activity and track requests, grants, and session controls.

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:

```text theme={"system"}
Governed activity → Decision → Grant or session control
                         ↘ Request history
```

Registry security reviews use separate workflows. See the [MCPs](/enable/mcp-requests)
and [Skills](/enable/skill-requests) pages 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.

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.

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

## Related records

Responses and Violations are related but not interchangeable:

* A [Violation](/secure/violations) 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.