Per-request token validation means the server checks issuer, audience, expiry, and scope on every tool call, not just at login or session setup. For MCP, this prevents a previously valid token from continuing to access tools after revocation, expiry, or scope change.
What Per-Request Token Validation Actually Changes
Per-request token validation turns a token from a one-time login artefact into a live authorization check. The server re-evaluates issuer, audience, expiry, and scope on every tool call, so access can stop as soon as trust conditions change.
This matters because a token that was valid at session setup may no longer be valid later. In an MCP flow, that distinction determines whether a tool call is still authorized, whether revocation takes effect quickly, and whether a stale credential can keep working past its intended lifetime.
Why It Matters for Access Control
Per-request validation is about MCP authorization behaving like a real resource-server control, not a loose pass-through. The server must treat each call as a fresh decision point instead of assuming the original token grant remains trustworthy.
That model aligns with OAuth-style resource restriction, where the audience and scope define what the token can reach and the server confirms those limits at use time. It is especially important when multiple tools, assistants, or downstream services share a trust boundary and a single token should not become a general-purpose pass.
Per-request checks also matter for revocation and expiry discipline. A short-lived token only reduces exposure if the service actually enforces the expiry at the moment of use, and scope reduction only helps if the server notices the new limits before the next tool invocation.
How It Differs From Session-Only Validation
Session-only validation answers one question: “Was this token acceptable when the session started?” Per-request validation answers a harder one: “Is this token still acceptable for this exact request, right now?”
That difference closes gaps created by token theft, delayed revocation, and scope drift. It also reduces the chance that a tool server keeps honoring a credential after an operator rotates keys, removes permissions, or disables the issuing client.
In practice, the tighter model is most useful where tool access is high impact, long-lived, or delegated across systems. The more authority the token carries, the more important it is that authorization is rechecked at the point of use.
Operational Consequences for MCP and Similar Tooling
For MCP and related tool-calling architectures, per-request validation helps keep each tool call tied to the current policy state. That is why token forgery and replay incidents remain so damaging when servers do not re-evaluate the token on use, as shown in Microsoft Storm-0558 key breach 2023.
The same principle is why stale or exposed credentials become dangerous across SaaS and automation environments. When access remains valid longer than intended, a leaked token can keep opening tools, APIs, or data until the server enforces a new decision at request time.
That is also why audience restriction and token binding are complementary controls, not substitutes. A token that is scoped correctly still needs to be checked on every call, because audience, expiry, and permissions are only useful if the server actually enforces them consistently.
Risk and Threat Considerations
Per-request token validation reduces the window in which a stolen, replayed, or over-broad token can be abused. Without it, revocation latency, stale scope, and token reuse can let an attacker continue making tool calls after the original trust decision should have expired.
Failure mechanism: the service validates the token only once, then continues trusting it across later calls even after revocation, expiry, or scope change.
Impact: attackers or stale integrations can retain unauthorized access to tools, data, or delegated actions far beyond the intended authorization window.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers token lifecycle, revocation, and expiration enforcement for authenticators. |
| AC-3 — Access Enforcement | Per-request checks are the point where access decisions are enforced on each call. | |
| IA-9 — Service Identification and Authentication | Applies when services or workloads present tokens for API or tool access. | |
| Recommendation — Enforce token expiry, revocation, and rotation so each request uses current authenticator state. Apply access enforcement on every tool call instead of trusting a prior session decision. Authenticate service-to-service calls at request time and reject tokens that no longer match policy. | ||
| OWASP ASVS | V8 — Authorization | ASVS requires authorization decisions to be enforced consistently on protected operations. |
| V10 — OAuth and OIDC | Directly addresses bearer tokens, audience, expiry, and token handling in OAuth-based flows. | |
| Recommendation — Verify authorization on each protected action, not just at initial sign-in. Validate audience, expiry, and token use rules for every OAuth-protected request. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Covers non-human token-based access where validation and trust checks can be weak. |
| Recommendation — Revalidate machine or service tokens on use so old credentials stop working immediately. | ||
Practitioner Guidance
Why practitioners should care: per-request validation is the control that turns token expiry and revocation into effective enforcement rather than administrative intent. If the server does not recheck every call, token hygiene improvements can be undermined by a single cached decision.
Common misunderstanding: a valid login session does not mean every later request is still authorized. Treat each tool invocation as an authorization event, especially when the token can reach sensitive resources or act on behalf of another system.
Related resources from NHI Mgmt Group
- What breaks when secrets retrieval relies on a shared SSRF token instead of per-request verification?
- What is the difference between token expiry and trust validation in MCP security?
- Why do OIDC token validation failures create confused deputy risk?
- Why do OAuth and OIDC flows need both callback protection and token validation?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org