MCP subagents need runtime permission ownership, not token inheritance

At a glance

What this is: This is a practitioner analysis of why MCP subagents must be treated as delegated actors with explicit runtime authorization, not permission clones.

Why it matters: It matters because IAM, PAM and NHI teams need to separate tool reachability from actual authorisation when agents, subagents and human consent all intersect.

👉 Read PermitIO's analysis of MCP subagent permission ownership and runtime authorization

Context

MCP subagent governance fails when teams assume the parent session’s authority automatically extends to every child process. In practice, the security problem is not just tool access, but who owns the decision at runtime when a subagent issues the call.

That distinction matters for NHI governance because delegated execution introduces a second principal with its own task context, risk profile and approval path. Once teams blur the boundary between connectivity and authorisation, least privilege becomes a configuration label instead of a runtime control.

Key questions

Q: How should teams govern MCP subagents that call sensitive tools?

A: Treat each subagent as a delegated identity with its own runtime authorisation decision. Do not rely on parent session credentials or server allowlists alone. The child principal, the tool name, the current consent state and the requested arguments all need to be evaluated before execution, with a logged approval record for audit and incident response.

Q: Why do parent agent permissions not safely extend to subagents?

A: Because parent continuity is not identity continuity. A subagent is a separate execution principal, so inherited permissions can create privilege carryover that was never reviewed for that child task. If the child can act on the parent’s token state without a fresh decision, least privilege has been replaced by implicit trust.

Q: What breaks when MCP security depends only on an allowlist?

A: The allowlist tells you which servers are reachable, but not whether a specific tool call is authorised for this child, this action and this consent state. That gap allows technically reachable but operationally unauthorised actions. Teams need runtime checks for intent, scope and approval freshness at every call boundary.

Q: Who is accountable when a delegated agent performs the wrong tool action?

A: Accountability should rest on the decision chain, not only on the session owner. You need to know who approved the delegated action, which policy version applied, what token was bound to the child principal and what side effect occurred. Without those records, accountability becomes speculative instead of provable.

Technical breakdown

Why parent session context does not equal subagent authority

A parent agent may hold OAuth tokens, user context and an MCP server allowlist, but a subagent is still a distinct execution principal. If child processes inherit the parent’s credentials implicitly, the security model collapses from delegated access into silent privilege carryover. The critical design error is treating workflow continuity as identity continuity. Runtime authorisation has to evaluate the specific child, the specific tool call and the current consent state before execution.

Practical implication: bind permissions to the child execution context, not the parent session.

Runtime authorisation versus MCP server allowlists

An MCP allowlist answers which servers are reachable, not whether a given tool invocation is appropriate now. That is why configuration boundaries and authorisation boundaries must be separated. Runtime authorisation should inspect intent, argument shape, consent freshness and child role before deciding. Without that split, a permitted connection can still produce an operationally unauthorised action.

Practical implication: keep allowlists narrow, but add a permission gate for every MCP call.

Why delegated approvals need explicit audit artefacts

Delegated MCP execution creates a multi-step trust chain that cannot be reconstructed from a single allow or deny event. Teams need decision-time records, execution-time records and token binding metadata to prove who approved what, under which policy, and what side effect actually occurred. That record structure is what turns agent delegation from opaque automation into accountable identity behaviour.

Practical implication: log the approval decision, the bound token and the execution outcome for every child call.

Threat narrative

Attacker objective: The objective is to trigger privileged tool actions through a delegated child process while bypassing the runtime approval boundary that should have constrained the call.

1. Entry occurs when a parent agent already has OAuth token context and spawns a subagent that can reach an MCP server through inherited or loosely brokered permissions.
2. Escalation occurs when the child principal inherits broader tool capability than its task justified, or when allowlist-only controls let an intended read-only flow invoke write actions.
3. Impact occurs when delegated calls execute sensitive side effects without a clear runtime ownership trail, making containment, attribution and revocation harder.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Runtime permission ownership is the control primitive, not session inheritance. Subagent governance fails the moment teams assume a child process can safely operate under the parent’s permission envelope. The article shows why delegated actors need their own runtime decision point, because authority must be re-validated for each tool call, not borrowed from a broader session. The practitioner conclusion is simple: identity governance for agents begins where inheritance ends.

Permission ownership at runtime is a trust-boundary problem, not a policy syntax problem. The central issue is not whether an allowlist exists, but whether the system can distinguish reachability from authorisation in the moment. That distinction is now a core NHI governance concern because MCP turns tool access into an execution channel, not just a configuration setting. Practitioners should treat every delegated tool invocation as a discrete decision record.

Delegated MCP work exposes an identity lifecycle gap for child principals. Subagents are spawned, used and discarded quickly, but many governance models still assume access belongs to a stable identity with a longer review window. That assumption breaks when the child principal is task-bound and ephemeral. The implication is that review, revocation and audit logic must follow the delegated actor, not just the parent account.

Child-agent access without brokered binding creates identity blast radius. If a subagent can reuse parent credentials or operate behind a weak consent boundary, one task can inherit too much authority across tools, servers and actions. This is a named governance failure mode, not a generic automation risk. Practitioners should think in terms of contained delegation domains, because blast radius is now shaped by tool-bound identity, not only by the user who started the session.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• That same research found 24,008 unique secrets were exposed in MCP configuration files in 2025 alone.
• For a broader credential-governance lens, read Guide to the Secret Sprawl Challenge for how exposure patterns and remediation choices compound across environments.

What this signals

Runtime permission ownership: delegated AI work changes the governance unit from session to call. That means teams need approval artefacts that follow the child principal, not just the parent workflow, and they need policy decisions that can be inspected after the fact.

MCP also sharpens the secrets-management problem. With 53% of MCP servers exposing credentials through hard-coded values in configuration files, per The State of MCP Server Security 2025, the practical issue is not only exposure but whether those credentials are ever bound to the right principal at runtime.

The next control layer is brokered delegation, not broader trust. Teams that already manage workload identity and secrets should now extend those controls into child-agent approval flows, because the operational boundary has shifted from who can connect to who can act.

For practitioners

• Separate tool reachability from runtime authorisation Treat the MCP server allowlist as connectivity only. Add a permission gate that evaluates child identity, requested scope, consent freshness, arguments and policy version before every tool call.
• Bind credentials to the delegated child principal Disable silent token inheritance by default and issue child-bound credentials with short effective TTLs whenever a subagent is approved for a specific action window.
• Log delegated approval and execution as two records Store the approval decision, approver, token binding, policy version and outcome separately from the execution metadata so incident response can prove legitimacy and impact.
• Use fail-closed escalation for missing consent Return a deterministic deny or escalation-required result when the child requests a sensitive tool and the user cannot confirm the action. Do not let the subagent stall silently.

Key takeaways

• MCP subagents are delegated actors, so permission ownership must be re-evaluated at runtime for each tool call.
• Allowlists reduce reachability, but only runtime authorisation can decide whether a child principal should execute a sensitive action.
• Without child-bound credentials and auditable approval records, delegated AI work creates privilege carryover and weak incident accountability.

Key terms

• Delegated actor: A delegated actor is a child identity that performs work on behalf of a parent session but does not automatically inherit the parent’s full authority. In agent systems, the child must be governed as a separate execution principal with its own consent state, scope and audit trail.
• Runtime authorisation: Runtime authorisation is the decision made at the moment a tool call is attempted, using current policy, identity context and consent state. It differs from static configuration because it decides whether this specific action is allowed now, not whether the system could ever reach the tool.
• Token brokering: Token brokering is the process of minting a new credential for a delegated child principal instead of passing the parent’s token downward. It reduces privilege carryover by binding the credential to the approved task, the child identity and a short-lived execution window.
• Identity blast radius: Identity blast radius is the amount of access, systems and actions that can be affected when one identity is over-scoped or misused. For delegated agents, the term describes how quickly a single child process can expand impact when authority is inherited instead of re-evaluated.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.

This post draws on content published by PermitIO: When AI Subagents Call MCP Tools, Who Owns the Permission Decision? Read the original.