Request-scoped state is information carried inside the request itself rather than stored in a long-lived server session. For MCP, this makes workflow continuity visible to the model and easier to route, but it also requires tighter validation because state can be replayed, reused, or mishandled if controls are weak.
Expanded Definition
Request-scoped state is a design pattern in which workflow context is carried inside the request payload or headers for the life of a single interaction, rather than being stored in a durable server session. In MCP-driven systems, that can make agent decisions, tool routing, and auditability more explicit, but it also means the request becomes a security boundary that must be validated every time.
Definitions vary across vendors on how much context belongs in the request versus in server-side coordination, and no single standard governs this yet. In practice, the safest interpretation is that request-scoped state should be treated as untrusted input, even when it originated from a trusted agent or upstream service. That aligns with the least-privilege logic reflected in the OWASP Non-Human Identity Top 10 and with Zero Trust ideas that require continuous verification, not inherited trust.
The most common misapplication is assuming request-scoped context is safe just because it was created earlier in the same workflow, which occurs when teams fail to revalidate state after redirects, retries, or tool handoffs.
Examples and Use Cases
Implementing request-scoped state rigorously often introduces payload complexity and replay-risk controls, requiring organisations to weigh simpler routing against tighter validation and shorter trust windows.
- An MCP agent passes a transaction ID, tenant ID, and tool policy in each request so downstream tools can enforce context without a long-lived session.
- A support automation workflow includes an approval token in the request, but the token is checked for freshness and origin before any privileged action executes.
- A federated service call carries short-lived correlation data so observability teams can trace the action without persisting user or agent context across systems.
- An agent handoff embeds scope constraints for a single tool invocation, reducing hidden state while making privilege checks more explicit.
These patterns are especially relevant when teams are trying to avoid the kinds of hidden trust paths described in Ultimate Guide to NHIs — Key Challenges and Risks, where overexposed service context often becomes a control failure. They also help explain incidents such as the Replit AI Tool Database Deletion, where agentic execution paths can become unsafe if request context is allowed to drive actions without sufficient guardrails.
- Short-lived workflow state for agentic approvals that expires after one use.
- Per-request policy assertions that determine which tools an AI agent may call.
- Cross-service tracing data used for audit, not for authorisation.
Why It Matters in NHI Security
Request-scoped state matters because it reduces dependency on long-lived server sessions, but it can also hide privilege escalation if the request itself is treated as authoritative. For NHI security, the central question is whether a service account, agent, or tool is reusing state that should have expired at the end of the last interaction. That is why request validation, nonce checks, expiry enforcement, and explicit scope binding are essential design controls.
NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Those conditions make request-scoped controls more important, not less, because a compromised request path can become a fast route to replay, impersonation, or unintended tool execution. The same governance logic appears in Microsoft SAS Key Breach, where weak handling of access context can expand blast radius quickly.
Organisations typically encounter the operational impact only after a replayed request, duplicated action, or unauthorized tool call has already caused damage, at which point request-scoped state becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Request-scoped state affects how NHI requests carry and validate context. |
| OWASP Agentic AI Top 10 | AI-03 | Agentic workflows often pass context per request into tools and actions. |
| NIST CSF 2.0 | PR.AC-1 | Access control requires verifying identities and context for each request. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero Trust requires continuous verification instead of inherited session trust. |
| NIST AI RMF | MAP 1.1 | AI risk management considers how context is represented, validated, and reused. |
Treat per-request agent context as untrusted and recheck tool permissions every time.
