[FEATURE] Provide agent identity context to MCP tool calls for sub-agent resource isolation

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28093
2. https://github.com/anthropics/claude-code/issues/26523
3. https://github.com/anthropics/claude-code/issues/28126

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is not a duplicate of the suggested issues.

• #28093: Cross-session MCP routing bug — about calls being routed to the wrong server process across separate Claude Code sessions. My request is about adding agent identity metadata within a single session's agent hierarchy.
• #26523: Resource exhaustion bug — about parallel processes consuming too much memory. My request is about MCP protocol-level metadata, not process lifecycle.
• #28126: Duplicate MCP server spawning bug on Windows — about MCP server process duplication, not about identifying which agent made a tool call.

None of these address the core request: including agent identity context in MCP tool call requests so that MCP servers can distinguish parent vs. sub-agent callers and isolate resources accordingly.

---

Implementation idea: Claude Code already assigns an internal agentId to each sub-agent instance (used for features like resume). This existing identifier could be included in MCP tool call requests as the agent_id — no need to invent a new identifier. The parent-child relationship could also be derived from the existing agent hierarchy tracking (queryTracking.depth, queryTracking.chainId).

This is a real problem and the proposed agent_context is the right shape. A few thoughts from the agent identity side:

The self-identification problem generalizes. It is not just sub-agents that cannot self-identify — any agent interacting with an MCP server has no standard way to prove who it is. The agent_id field in your proposal is an opaque identifier. Who generates it? Who ensures uniqueness? Can it be spoofed by a malicious sub-agent?

Cryptographic identity solves this cleanly. If each agent (parent or sub-agent) has an Ed25519 keypair, the agent_context becomes verifiable:

{
  "agent_context": {
    "did": "did:aip:abc123",
    "parent_did": "did:aip:parent456",
    "signature": "<signed-challenge-from-mcp-server>"
  }
}

The MCP server can verify the signature against the public key, confirm the agent is who it claims to be, and use the DID as a stable resource isolation key. No self-awareness needed — the identity is injected by the runtime, not claimed by the agent.

This is what AIP (Agent Identity Protocol) provides. We have an MCP server that exposes identity operations as MCP tools. The pattern: runtime injects identity via env vars (AIP_DID, AIP_PRIVATE_KEY), agent signs requests, MCP server verifies.

For your PowerShell.MCP case specifically, this would mean:

1. Claude Code spawns sub-agent with a unique DID (derived from parent + task index)
2. Sub-agent includes DID in every MCP tool call
3. PowerShell.MCP maps DID → console session automatically
4. No self-identification parameter needed

The IETF is also working on this — draft-klrc-aiagent-auth-00 proposes agent authentication for HTTP-based protocols. Happy to discuss integration approaches.

This is a real problem that extends beyond Claude Code into any multi-agent system using MCP.

We've been working on a protocol that addresses this at the identity layer: the Agent Passport System. Each agent gets an Ed25519 keypair, and when a parent spawns sub-agents, each one gets its own cryptographic identity via scoped delegation. The delegation chain captures the parent-child relationship:

• Parent creates a delegation to the sub-agent with narrowed scope
• The sub-agent's identity includes its delegatedBy field pointing to the parent
• MCP servers can verify both who the caller is AND who authorized them

This maps directly to your use case: instead of relying on the agent to self-report is_subagent=true, the MCP server verifies the delegation chain cryptographically. The agent_context you're proposing would carry:

{
  "agent_id": "did:aps:<sub-agent-public-key>",
  "parent_agent_id": "did:aps:<parent-public-key>",
  "delegation_signature": "<ed25519-sig-from-parent>"
}

The key insight from your proposal — that this needs to be injected by the MCP client, not self-reported by the agent — is exactly right. Self-identification fails for the same reason self-attestation fails in any security context: the entity being authenticated shouldn't control their own credentials.

We have this working as an MCP server with 61 tools (https://www.npmjs.com/package/agent-passport-system-mcp). The delegation + identity verification tools handle the sub-agent case. Published academic paper with the formal properties: https://doi.org/10.5281/zenodo.18749779

Agree this should eventually live in the MCP spec itself. Happy to collaborate on what that spec extension would look like.

@The-Nexus-Guard @aeoess Thank you for the thoughtful comments. Cryptographic identity is an important approach for scenarios where agents cross trust boundaries. However, for the problem this issue addresses, I believe both proposals face a fundamental challenge: they require the agent to actively participate in identity negotiation (calling identity tools, including credentials in parameters). Agents don't necessarily follow such protocols, especially sub-agents that have no awareness of their own position in the hierarchy.

In fact, I've already implemented an approach similar to this at the MCP protocol layer in my MCP server, PowerShell.MCP — the start_powershell_console tool returns a session ID, and subsequent tool calls use it to route to the correct session. This implementation shares the same challenge as both of your proposals: there is no guarantee that the agent will correctly use that session ID. The core issue isn't the strength of the ID — it's who assigns the ID and who includes it in the request.

What's needed, I think, is injection at the MCP client's transport layer. The client (Claude Code) would automatically attach agent_context to every outgoing MCP request, completely transparent to the agent. The agent never sees it, never needs to act on it, and can't forget to include it. This is analogous to how an HTTP proxy adds X-Forwarded-For headers without the application's involvement.

You're raising an important distinction — let me clarify where we agree and where our intended models align.

You're right that if identity requires the agent to actively call identity tools, a non-cooperating agent bypasses the system entirely. We agree this is broken for your use case.

Our intended deployment pattern relies on the infrastructure layer, not the agent:

1. The runtime generates or assigns the Ed25519 keypair
2. The MCP client layer attaches identity metadata to outbound tool calls
3. The MCP server verifies the credential before processing the request

The agent never handles or opts into its identity — it's injected by the infrastructure. The gap right now isn't in the protocol design. It's in the MCP spec itself: there's currently no standard field in the tool call schema for client-injected identity metadata.

Your agent_context proposal solves exactly this spec gap. The dependency chain is:

1. MCP spec adds agent_context — the transport layer
2. Client implementations inject identity into agent_context — the runtime layer
3. Protocols like APS define what goes in that field and how to verify it — the trust layer

We're not competing — your proposal is necessary infrastructure for protocols like ours to work without agent cooperation.

For resource isolation within a single session, an opaque runtime-injected ID is likely sufficient. The cryptographic layer matters when crossing trust boundaries — different MCP servers, different organizations, agents from different vendors verifying each other.

Your work enables ours. I strongly support focusing on the minimal runtime-injection mechanism first.

The sub-agent resource isolation problem has a concrete solution: scoped delegation with enforcement context.

When Claude Code spawns a sub-agent for a task, the sub-agent currently has the same capabilities as the parent. APS solves this with delegation chains:

Monotonic narrowing — the parent creates a delegation for the sub-agent with restricted scope. scope: ['code_review'] means the sub-agent can use code review tools but not file write tools. The delegation is Ed25519 signed by the parent — the sub-agent can't widen it.

AgentContext enforcement — wrap the sub-agent in createAgentContext(). Every tools/call the sub-agent makes is checked against its delegation scope. Out-of-scope calls are blocked with a signed denial record. The parent can audit exactly what the sub-agent attempted, not just what it succeeded at.

Cascade revocation — if the parent revokes the sub-agent's delegation, all sub-sub-delegations are automatically revoked. Clean teardown of the entire delegation tree when a task completes.

Spend tracking — if the sub-agent calls paid APIs, the delegation includes a spend limit. Running balance tracked per delegation, checked atomically on each call. The sub-agent can't exceed its budget.

This works without MCP protocol changes — it runs as middleware between the MCP client and server. The AgentContext intercepts tools/call, evaluates the delegation, and either forwards (with a signed receipt) or blocks (with a signed denial).

npm install agent-passport-system — 125 MCP tools, zero protocol changes needed.

@aeoess Your first comment was on point — we aligned on the principle that self-attestation doesn't work and that identity must be injected by the infrastructure, not the agent.

This follow-up contradicts that. We already discussed why this doesn't work. Disappointing after such a strong first reply.

@yotsuda — fair point. Let me clarify, because the model is consistent even if the framing wasn't.

The delegation and enforcement context in that post are infrastructure-injected, not agent-initiated. The parent doesn't "create a delegation" voluntarily — the infrastructure creates the delegation when it spawns the sub-agent, and the sub-agent can't modify or widen it. The AgentContext wrapper is set by the infrastructure, not by the agent. The agent can't see it, can't remove it, can't bypass it.

Same principle as your comment 1: identity and scope injected by infrastructure, not self-attested by the agent. My framing was sloppy — described the mechanism from the infrastructure's perspective but used language that sounded agent-driven. The enforcement model hasn't changed.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.