MCP's Agent Identity Problem: What the Official Roadmap Tells Healthcare Security Teams

MCP Security

Bienvenue à nos lecteurs français et willkommen an unsere deutschen Leser — we're glad you're here. The MCP roadmap published August 22, 2026 is the most candid public statement Anthropic and the MCP Core Maintainers have made about the protocol's current security posture. Priority Area 3 — Agent Identity and Enterprise-Ready Security — opens with this: MCP authorization assumes a person with a browser at consent time. Increasingly the caller is an agent.

That sentence is doing a lot of work. It's an admission that the foundational auth model was designed for human-in-the-loop OAuth flows, and that the protocol is now being deployed in contexts it wasn't designed for. The existing state: pasted API keys and long-lived refresh tokens. That's the production reality the roadmap is working against.

This post breaks down what the roadmap is actually proposing, why it matters for healthcare MCP deployments, and what the gap between "current state" and "roadmap delivery" means for security programs running agentic workloads today.

The Problem the Roadmap Is Solving

Standard OAuth 2.0 — the auth model MCP currently builds on — works well when a human is present to authorize consent. A person clicks "Allow," a short-lived token is issued, the session proceeds. The human is the identity anchor.

Agentic workloads break this model in several ways. The caller may be a cloud workload with its own service identity, not a person. The agent may be acting on behalf of a user who isn't present at execution time. A parent agent may spawn sub-agents that should operate with narrower authority than their parent — but the current model has no standardized way to express or enforce that delegation hierarchy. And when no human is present to re-authorize, "short-lived token" often becomes "long-lived refresh token" in practice, because the alternative is constant re-authentication friction that breaks the workflow.

The result is what the roadmap accurately describes: pasted API keys and long-lived tokens as the de facto standard. Both are high-value targets. Both are difficult to rotate in agentic pipelines without breaking dependent workflows. Both are the opposite of least-privilege.

What the Roadmap Is Proposing

DPoP — Demonstrating Proof of Possession

DPoP (RFC 9449) binds an access token to a specific client keypair. When a client presents a token, it also presents a signed proof that it holds the private key corresponding to the token — meaning a stolen token is useless without the key. The roadmap is targeting finalization of the DPoP specification for MCP and driving widespread adoption.

For healthcare MCP deployments, DPoP is a meaningful step forward. It addresses token theft at the transport/storage layer — one of the most common attack vectors against service-to-service integrations. A long-lived token that's been exfiltrated from a compromised container or secrets store becomes non-functional if DPoP is properly implemented.

The caveat: DPoP is a binding mechanism, not an identity mechanism. It answers "did this client present this token?" — not "should this agent be allowed to do this?" It's necessary but not sufficient for the full agent identity problem.

Workload Identity Federation

SEP-1933 (Workload Identity Federation) is the mechanism for giving agents their own cryptographic identity — separate from user identity, anchored to the workload itself. The model is familiar from cloud-native contexts: a Kubernetes pod, a Lambda function, or a container gets an identity token issued by the platform, which can be exchanged for access to downstream services without any human credential in the chain.

Applied to MCP, this means an agentic workload running in your environment would have its own identity asserted by your identity platform — not a shared API key, not a user's delegated token, but a workload identity that can be independently issued, scoped, audited, and revoked.

This is the architecture that makes least-privilege practical for agentic pipelines. You can scope a workload identity to exactly the MCP servers and tools it needs. You can revoke it without touching any user's credentials. You can audit its access independently of the human operators who built it.

ID-JAG and RFC 8693 Token Exchange

The Identity Assertion JWT Authorization Grant (ID-JAG) and RFC 8693 token exchange address the delegation chain problem — specifically, how an agent acting on behalf of a user carries that user's identity downstream without the user being present.

The practical scenario: a healthcare orchestration agent needs to query a clinical data MCP server on behalf of a specific clinician. The clinician authorized the action, but they're not at a browser. How does the MCP server know the agent is acting with that clinician's authority, and not acting outside its sanctioned scope?

ID-JAG provides a structured JWT assertion that carries the identity of the human principal the agent is acting for. RFC 8693 defines the token exchange protocol — how an agent trades its own workload identity token plus an ID-JAG assertion for a scoped access token appropriate for the downstream resource. The WIMSE (Workload Identity in Multi-System Environments) IETF working group is coordinating this work, which means it's tracking toward open standards rather than MCP-specific proprietary mechanisms.

Human-Presence Attestation

Listed as under discussion rather than committed for this roadmap period, human-presence attestation is the mechanism for distinguishing interactive clients — a human at a keyboard — from headless agents. This matters for audit trails, break-glass access controls, and any workflow where regulations or internal policy require human authorization for sensitive operations.

In healthcare, the analog is already familiar: systems that require a clinician to be actively authenticated before executing certain orders. Human-presence attestation would bring that capability to MCP-connected agentic workflows — not just "was this action authorized by a human at some point" but "was a human present and active when this specific action was taken."

What This Means for Healthcare MCP Deployments

The Gap Between Roadmap and Reality

None of the above is shipping this week. The roadmap is explicit: the Agent Identity Working Group is still forming during this roadmap period. DPoP finalization and adoption is a target, not a completed deliverable. Workload Identity Federation is a SEP under development.

Healthcare organizations running MCP-connected agentic workloads today are operating under the auth model the roadmap is trying to replace: OAuth with human consent flows, pasted API keys, long-lived tokens. That's the current production baseline. The roadmap doesn't change that baseline — it describes where the protocol is going.

The security implication: the gap between current state and roadmap delivery is your threat window. If you're deploying MCP servers into production healthcare environments now, your security controls need to account for the limitations of the current auth model, not the capabilities of the planned one.

What You Should Be Doing Now

The roadmap's direction is clear enough to inform architecture decisions today, even before the specifications finalize.

On secrets management: the transition away from pasted API keys toward workload identity is coming. Building your MCP integrations on a secrets management platform — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault — rather than hardcoded or environment-variable-stored credentials positions you to rotate and eventually replace those credentials as the identity model matures. Any MCP deployment that requires manual credential rotation is technical debt against the roadmap.

On token scoping: long-lived refresh tokens are the current workaround for the absent-human problem. If you're issuing them, scope them as narrowly as possible — specific MCP servers, specific tool categories, specific data resources. Audit their use. Build revocation into your incident response runbooks. Don't treat a long-lived token as equivalent to a service account that you can set and forget.

On network segmentation: DPoP and workload identity harden the credential layer. They don't replace network controls. MCP servers in healthcare environments should be on dedicated network segments with explicit allow-lists for which agents can reach which servers. The identity controls coming in the roadmap should layer on top of network segmentation, not substitute for it.

On audit logging: the roadmap's human-presence attestation work signals that regulatory and compliance frameworks will eventually expect logs that distinguish human-authorized actions from autonomous agent actions. Build that distinction into your MCP server logging now, even if the attestation mechanism isn't standardized yet. Log the caller type, the authorization method, and whether a human was present in the session. When the standards land, you'll have the data.

The Healthcare-Specific Risk

Healthcare MCP deployments face regulatory constraints that make the current auth gap more acute than in other sectors. An agentic workflow that accesses clinical data without proper identity controls isn't just a security problem — it's a potential HIPAA minimum necessary violation, a potential audit failure, and a potential liability in any incident where the agent accessed data outside its sanctioned scope.

The "pasted API key" pattern is particularly dangerous in healthcare because it typically means one credential with broad access is shared across multiple agentic workflows. If that key is compromised, the blast radius covers everything it touches. Workload identity — when it's available — solves this by giving each workflow its own identity and its own scope.

Until workload identity is available, the operational equivalent is credential isolation: one credential per agentic workflow, scoped to that workflow's minimum necessary access, with independent rotation and revocation capability. It's more operational overhead than a shared key. It's also the only defensible architecture given what the current auth model looks like.

Reading the Roadmap as a Security Signal

The MCP roadmap is worth reading as a transparency document, not just a feature preview. The Core Maintainers are publicly acknowledging that the current authorization model has structural gaps for agentic workloads. They're naming the specific gaps — absent-human consent flows, service-to-service identity, delegation chains — and committing to specific mechanisms to address them.

That's the kind of vendor transparency that lets security teams make informed architecture decisions. The gaps are known, the direction is specified, and the timeline is six to twelve months for the next specification update.

For healthcare security programs, that timeline is the planning horizon. The question isn't whether to deploy MCP — agentic workloads are coming regardless. The question is whether your current MCP deployments are hardened against the auth limitations the roadmap acknowledges, and whether your architecture is positioned to adopt the identity controls when they arrive.

The roadmap tells you where the protocol is going. Your security controls need to cover the distance between here and there.