Topic starter
25/06/2026 1:18 am
TL;DR: When Claude Code subagents call MCP tools, permission ownership can drift away from the parent session, creating gaps between token context, approval surfaces and runtime authority, according to PermitIO. The key security failure is assuming delegated actors can safely inherit access when access review, consent and tool intent all need to be re-evaluated per call.
Editorial analysis by NHI Mgmt Group, based on content published by PermitIO: “When AI Subagents Call MCP Tools, Who Owns the Permission Decision?”.
Key questions
Q: What breaks when MCP subagents inherit the parent session's permissions?
A: Inheritance breaks the identity boundary because the child can act with authority that was granted to the parent, not to the delegated worker.
Q: Why do delegated MCP flows need runtime authorization instead of allowlists alone?
A: Allowlists only define where a subagent may connect, not whether a specific action is acceptable for that child at that moment.
Q: What should security teams do about delegated access across sub-agents?
A: Security teams should require revalidation at each hop in the delegation chain.
Practitioner guidance
- Define child principal boundaries Model each subagent as a separate identity with its own task envelope, rather than as a continuation of the parent session.
- Separate connectivity from authorization Keep mcpServers allowlists narrow, but do not treat them as proof that a call is allowed.
- Issue child-bound credentials only Replace implicit token inheritance with brokered, time-bounded credentials tied to the delegated approval event and the specific child identity.
Bottom line: MCP subagents expose a governance gap where the child principal can drift away from the authority granted to the parent session.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 10:37 am
Delegated MCP execution is an identity problem, not a prompt problem: the core failure is assuming a child worker can safely inherit the parent's authority model. That assumption is wrong because the subagent is a separate execution principal with its own task envelope and risk boundary. The practical implication is that permission ownership must be evaluated per call, not per session.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: What should organisations do when a subagent request needs consent but no approval arrives?
A: Treat the absence of approval as a terminal state, not as a waiting state. The system should fail closed, return a deterministic denial or escalation outcome, and make that result visible to the parent orchestration layer.
👉 Read our full editorial: MCP subagents need runtime permission ownership, not token inheritance