How should security teams govern MCP requests without relying on session state?

Why This Matters for Security Teams

MCP governance fails quickly when teams assume a session is the security boundary. Model Context Protocol requests can be routed through changing clients, servers, and tool chains, so a one-time approval does not tell you what the next call is allowed to do. Current guidance suggests treating each request as a fresh identity and authorization event, with the decision anchored to token claims, scope, and the actor’s current context, not the chat or connection history. That is especially important when agents can chain tools or retry actions autonomously.

The risk is not theoretical. NHIMG’s Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs emphasises that non-human access must be governed by lifecycle, not assumption, and the same principle applies to MCP-driven workloads. Industry research also shows the gap is already operational: the State of MCP Server Security 2025 reports that only 18% of deployments implement access scoping for tool permissions.

In practice, many security teams discover overbroad MCP access only after an agent has already used a tool outside its intended scope, rather than through intentional governance design.

How It Works in Practice

The cleanest pattern is to make every MCP request independently verifiable. That means the server or policy layer should inspect the credential presented on each call, evaluate the token scope, validate actor claims, and check whether the requested tool or data source is permitted right now. This is closer to OWASP Agentic AI Top 10 style runtime control than traditional session-centric access control.

Security teams should prefer short-lived, purpose-bound tokens over static credentials. If the agent needs a narrow task, issue a JIT token with the least scope required, then revoke it automatically when the task completes. Where possible, bind the request to workload identity rather than a human login state, so the system can prove what the agent is and what it is allowed to do. That usually means integrating policy-as-code at the request boundary and evaluating rules at runtime instead of caching access decisions in the connection layer.

• Verify identity on every MCP request, not only at session start.
• Use narrow scopes for each tool, data source, and action class.
• Prefer ephemeral tokens and automatic revocation over long-lived secrets.
• Log the token, tool call, policy decision, and request context for auditability.
• Reassess authorization whenever the server, connector, or agent context changes.

For practitioners building the control plane, NHIMG’s AI Agents: The New Attack Surface report is a useful reminder that agent behaviour is often broader than its original intent, and the NIST Cybersecurity Framework 2.0 still provides a solid governance anchor for mapping authentication, access control, and logging to repeatable operations. These controls tend to break down when MCP servers share static secrets across multiple tools because one compromised credential then inherits every connected capability.

Common Variations and Edge Cases

Tighter per-request controls often increase latency and implementation overhead, requiring organisations to balance stronger containment against operational simplicity. That tradeoff becomes more visible in high-volume agent workflows where requests fan out across multiple tools or where the client library was built around persistent sessions.

Current guidance suggests a few edge cases need special treatment. Cached responses can hide the fact that a later request would now fail policy, so teams should not confuse transport reuse with authorisation reuse. Multi-agent pipelines are even trickier: one agent may be permitted to read data while another is permitted to act on it, so the policy must follow the specific actor and task, not the whole conversation chain. For broader identity design, NHIMG’s Top 10 NHI Issues highlights the recurring failure mode of credential reuse across systems, which maps directly to MCP deployments with shared service accounts.

There is no universal standard for this yet, but the emerging best practice is to combine workload identity, per-request policy evaluation, and short-lived credentials. That approach aligns well with NIST SP 800-53 Rev 5 Security and Privacy Controls for access enforcement and audit, while still accommodating autonomous systems that change state rapidly. The model becomes less reliable when vendors cannot expose request-level claims or when MCP tooling hides tool invocation details from the policy engine.

Related resources from NHI Mgmt Group

• How should security teams govern machine identity credentials in agentic AI environments?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How should security teams use AI in secret scanning without creating new blind spots?