Why do MCP workloads need per-request identity instead of virtual keys?

Why per-request identity changes the security model for MCP

Per-request identity matters because an MCP tool call is not just a transport event, it is an access decision. If every invocation resolves to a specific subject at the moment of use, the platform can enforce policy against that subject, not against a shared credential. That is the difference between accountable authorisation and a convenient routing token.

Shared virtual keys can be useful for session setup, tenant routing, or basic metering, but they flatten the real actor behind the request. In practice, that makes it harder to prove who asked for the action, what authority they had, and whether the request should have been allowed in that context.

Per-request identity also fits better with short-lived, scope-bound access. When a tool invocation carries a resolved subject, the server can apply the narrowest policy needed for that exact action, instead of letting a caller reuse one broad key across many tools, sessions, or contexts. That reduces the chance that one leaked or overbroad credential becomes a standing path into multiple operations.

What virtual keys can and cannot prove

Virtual keys are best treated as abstraction and convenience, not as proof of authorisation. They can help a platform hide upstream secrets from the caller, simplify integration, and separate users from backend credentials. They do not, by themselves, tell the receiving system which user or agent was actually authorised to invoke a tool at that moment.

That distinction matters whenever the action has business, security, or compliance consequences. If the only visible artefact is a shared virtual key, audit records may show that “someone with the key” called the tool, but not which subject authorised the action or whether the caller should have had access to that specific capability.

For MCP environments, that limitation is especially important when multiple users, agents, or workflows share the same brokered path. The stronger design is to keep the caller’s identity intact through the request, then exchange it for a downstream token or assertion only for the exact resource and action being requested.

How per-request identity improves policy, audit, and containment

Per-request identity lets policy engines make decisions on the current request context, not on an assumed trust relationship from an earlier login or provisioning event. That supports least privilege, contextual authorisation, and better separation between the identity of the human requester, the agent, and the backend service actually performing work. It also gives the MCP authorization specification a concrete security role: keep access decisions tied to the requested resource and audience, rather than to a reusable shared secret.

Audit quality improves for the same reason. A per-request model can record who initiated the call, which tool or resource was invoked, and what policy decision was made at that moment. That is materially stronger than an environment where the only evidence is a shared key being presented somewhere in the path.

Containment is better as well. If a downstream credential is exposed, a per-request design can keep the blast radius narrow because the exposed material does not need to be the same thing that proves the caller’s identity upstream. That helps preserve upstream secrecy, while still letting the server make a specific allow or deny decision for each action.

Risk and Threat Considerations

Shared virtual keys create a confusion boundary that attackers and careless integrations can exploit. If the platform treats the key as enough evidence of intent, a stolen, replayed, or overused key can become a generic pass that masks who really initiated the tool call and makes abuse harder to detect.

Failure mechanism: A caller presents the same virtual key across many requests, so the platform loses the ability to distinguish a legitimate subject from a reused secret, a delegated action, or a compromised integration. That weakens attribution, allows privilege creep, and can hide whether upstream credentials were ever meant to reach the tool layer.

Impact: Policy enforcement becomes coarse, audit trails become less trustworthy, and incident response has less evidence to reconstruct who authorised what. In a multi-agent or multi-user environment, that can turn one access path into a broad abuse path.

Practitioner Guidance

What to verify: Check whether each MCP request carries a verifiable subject and audience, not just a session or routing key. If the receiving service cannot answer “who authorised this call?” from the request record, the design is still too dependent on shared abstraction.

Decision rule: Use virtual keys for routing or tenant isolation only when the actual authorisation decision is still made on per-request identity and scope. If a single shared key is doing both jobs, treat that as an architectural weakness, not a convenience.

What practitioners underestimate: Auditability degrades long before a secret is visibly stolen. The bigger issue is often that a shared key prevents you from proving intent, so the system cannot reliably separate legitimate delegated use from misuse or replay.

Practitioner takeaway: In MCP, the safest design is to make the request itself carry the proof of who is acting, while treating virtual keys as a transport convenience that must never become the authority boundary.

Related resources from NHI Mgmt Group

• What is the difference between workload identity and API keys for AI agents?
• How should security teams implement workload identity for AI and Kubernetes workloads instead of using long-lived cloud keys?
• What are MCP Authorization Extensions and how do they help organizations?
• Why do AI agents make non-human identity governance harder?