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.
At a glance
What this is: This analysis argues that MCP subagents must be governed as delegated actors with runtime permission ownership, not as automatic permission clones of the parent session.
Why it matters: IAM, PAM and NHI teams need to separate tool connectivity from per-call authorization, or delegated subagents can inherit more authority than their task actually justifies.
Context
MCP subagents create a governance problem because the executing principal is no longer the same as the parent session that initiated the work. In practice, that means the access decision must be made at the moment of each tool call, not assumed from the parent's prior consent or token state.
For identity teams, this is an NHI and delegated-authority issue, not just an application design quirk. Once a child worker can act inside a separate execution envelope, the programme has to distinguish connectivity, authorization and approval as different control layers.
The security question is simple: who owns the permission decision when a delegated worker calls the tool? When that answer is unclear, inheritance becomes a trust shortcut rather than a governed identity model.
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. That can turn a narrow task into broader tool access, especially when approval state and token scope are reused without a new runtime decision.
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. Runtime authorization is needed to check tool intent, child role, consent freshness and argument risk before execution.
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. Every downstream agent should carry the current identity, current context, and the original intent so inherited access does not turn into a blanket pass.
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.
Technical breakdown
Why token inheritance breaks delegated MCP authority
In a parent-child agent pattern, the parent session may carry user context and an OAuth token, but a subagent is still a separate execution principal. If the child can reuse the same token material automatically, the system collapses two identities into one authority boundary. That creates privilege carryover, where a tool call is authorised by historical context rather than present intent. The safer model is runtime authorization, which evaluates the child identity, requested tool, argument shape, consent state and risk before each call. This is not a token management detail. It is the control point that determines whether delegation remains bounded or becomes implicit inheritance.
Practical implication: Treat every subagent as a distinct principal and require a fresh decision for each MCP tool call.
Allowlist configuration is not the same as runtime authorization
An mcpServers allowlist defines where a client may connect, but it does not answer whether a specific child may invoke a specific action right now. That distinction matters because connectivity, tool scope and execution authority are separate control layers. A subagent can be pointed at a permitted MCP server yet still be inappropriate for a write operation, a sensitive workflow or a task outside its prompt. Runtime authorization closes that gap by evaluating the call in context, not just the server in configuration. Without that second gate, teams end up with authorised infrastructure and unauthorised intent.
Practical implication: Use allowlists for reachability, then enforce per-call authorization for tool use and action scope.
Why delegated flows need explicit decision artifacts
Delegated MCP execution only becomes auditable when the system records who asked, what was approved, what scope was bound and what action actually executed. That decision artifact is what separates a legitimate delegated call from a silent privilege reuse. It also gives incident responders a way to prove whether the child inherited authority, received a child-bound token, or triggered an escalated approval path. In identity terms, this is the difference between a policy intention and a defensible control event. If the decision was never materialised, the organisation cannot later reconstruct whether the subagent acted within its granted scope.
Practical implication: Log the decision, the bound scope and the executed action for every delegated tool call.
Threat narrative
Attacker objective: Obtain tool-level action rights through delegated execution that exceed the scope of the child agent's intended task.
- Entry occurs when a subagent is spawned inside a parent session that already holds valid user context and tool access.
- Credential abuse follows if the child can reuse inherited token material or approval state without a new runtime decision.
- Escalation happens when the subagent is allowed to invoke higher-risk MCP tools than its task actually requires.
- Impact emerges when delegated execution produces side effects that were never explicitly authorised for that child principal.
Breaches seen in the wild
- Sentry MCP Agentjacking 2026: Researchers showed a fake Sentry error, posted with a public DSN, could make AI coding agents run attacker code with developers' credentials.
- Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Runtime authorization is the control that preserves delegation boundaries: static allowlists only describe possible connectivity, not acceptable action at the moment of use. Once tool intent and user consent diverge from the parent context, the governance model has to re-decide the call. Teams should treat brokered authorization as the normal case for delegated MCP workflows.
Explicit decision artifacts are now part of identity evidence: without a recorded approval, a child-bound scope and a matched execution record, the organisation cannot prove whether the delegated action was legitimate. This is where auditability and operational safety meet. Practitioners need a control model that can explain who approved the child, what was bound, and what actually happened.
Runtime permission ownership defines the new trust boundary for MCP ecosystems: the important question is no longer whether an agent can reach a server, but whether that specific delegated actor can exercise a tool right now. That shifts governance from session trust to call trust. Security teams should design for child-specific authority, short-lived scope and deterministic denial paths.
Permission inheritance is a trust shortcut that expands blast radius: when a parent token silently follows the child, the organisation is no longer governing a delegation chain but a hidden privilege clone. That creates a runtime trust gap between intent and execution. The correct conclusion is not more inheritance logic, but a stricter definition of who actually owns authority at the point of action.
From our research library:
- 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.
- Read next: MCP Security Guide
What this signals
Delegated MCP workflows are now exposing a familiar identity pattern in a new form: authority can drift away from the principal that actually performs the action. That makes runtime permission ownership, not session continuity, the control question that matters for subagents, and it pushes teams toward child-specific authorization rather than inherited trust.
Runtime permission ownership: the useful concept here is the separation between connectivity and action authority. In MCP environments, a server being reachable says nothing about whether a child worker should be allowed to execute a particular call, so governance must move from static membership to per-call decisioning.
Teams should expect audit pressure to rise as delegated agents become more common, because every subagent action now needs a defensible chain of approval, scope and outcome. That means IAM, PAM and NHI programmes will need evidence models that can explain delegated access without relying on the parent session as a proxy for legitimacy.
For practitioners
- 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. Document which tools, scopes and consent states apply to that child and when they expire.
- Separate connectivity from authorization Keep mcpServers allowlists narrow, but do not treat them as proof that a call is allowed. Add a runtime permission gate that evaluates the requested tool, arguments, user consent and child role on every execution.
- 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. Revoke them automatically when the parent session or approval state changes.
- Record delegated approval evidence Capture who approved the call, what scope was approved, which tool ran and what outcome occurred. Keep the decision-time record and the execution-time record together so audit and incident review can reconstruct the full chain.
- Fail closed on missing consent If the child cannot obtain an explicit approval decision, return a deterministic denial rather than leaving the request to hang silently. Surface that outcome to the parent so operators can distinguish denial from stalled orchestration.
Key takeaways
- MCP subagents expose a governance gap where the child principal can drift away from the authority granted to the parent session.
- The central control issue is not reachability but runtime ownership, because allowlists and inherited tokens do not prove the child was authorised for that specific action.
- The strongest containment model uses child-bound credentials, per-call authorization and audit records that tie approval to execution.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on delegated agent authority and privilege carried into child execution. |
| Recommendation — Enforce child-specific authorization so delegated agents cannot reuse parent authority by default. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Implicit token inheritance weakens the authentication boundary between parent and subagent. |
| NHI-05 — Overprivileged NHI | The article shows how delegated workers can inherit more access than their task needs. | |
| Recommendation — Bind credentials to the child principal and reject inherited tokens as proof of authority. Reduce child scopes to the minimum approved action and revoke any excess access immediately. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Child-bound tokens, short TTLs and revocation handling are central to the permission model here. |
| Recommendation — Use IA-5 to manage delegated authenticator scope, lifetime and revocation. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Delegated MCP authority is an identity and access management problem in a cloud control plane. |
| Recommendation — Separate tool connectivity from authorization and log each delegated decision under IAM controls. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | A child agent invoking a tool it can reach but should not execute mirrors broken function-level authorization. |
| Recommendation — Validate each tool call against function-level authorization before execution. | ||
Key terms
- Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
- Delegated Principal: A delegated principal is a child actor that performs work on behalf of a parent but must still be governed as its own identity. In MCP workflows, that distinction matters because shared context does not equal shared authority, and the child may need narrower permissions than the parent.
- Token Inheritance: Token inheritance is the reuse of an existing credential by a downstream actor without a fresh permission decision. In delegated agent flows, it is risky because it can transfer authority across principal boundaries and make a child look authorised when it has not been separately approved.
- Permission Ownership: Permission ownership is the clear assignment of who is responsible for an access decision at the point of use. For subagents, it means the system must know whether the parent, the child or a policy gate owns the final call, and it must record that ownership for auditability.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org