Topic starter
25/06/2026 1:18 am
TL;DR: Permission ownership can drift from the parent session to Claude Code subagents, PermitIO reports, when delegated tools reuse approval state and token scope. Runtime authority then needs a fresh decision for each call, or inherited access can outrun the child worker's actual authorization.
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: 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.
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.
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.
Glossary terms: Token Inheritance, Runtime Authorisation, Delegated Principal, Permission Ownership
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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