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.
Why This Matters for Security Teams
MCP subagents are not just another integration detail. Once a child agent can call sensitive tools, it becomes a delegated principal with its own blast radius, and parent session credentials are no longer a safe proxy for intent. That shift matters because tool access can turn a benign workflow into data export, privilege escalation, or destructive action if the subagent is over-scoped or misled.
Current guidance suggests treating tool invocation as a runtime security decision, not a static platform allowlist. NHI Management Group’s research on the State of MCP Server Security 2025 found that only 18% of mcp server deployments implement any form of access scoping for tool permissions, which helps explain why failures often show up as governance gaps rather than obvious exploits. The risk is magnified in agentic environments, where behaviour is goal-driven and the next action is often not predictable in advance, as reflected in the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework.
In practice, many security teams encounter improper tool use only after a subagent has already executed an unsafe call, rather than through intentional approval design.
How It Works in Practice
Effective governance starts by separating the parent session from the child principal. The subagent should present its own workload identity, and the platform should evaluate each sensitive tool request at runtime using the child identity, requested action, current consent state, and arguments. That is closer to intent-based authorisation than classic RBAC. Static roles can say who is allowed in general, but they cannot reliably answer whether this agent should perform this specific tool call right now.
For sensitive operations, current best practice is evolving toward short-lived, task-bound credentials and explicit approval records. A subagent that needs to read customer records, approve a payment, or write to production should receive only the minimum token or capability needed for that single task, with automatic revocation after completion. This is consistent with the direction of the CSA MAESTRO agentic AI threat modeling framework and the NIST AI Risk Management Framework, both of which emphasise context, monitoring, and accountability.
NHI Management Group’s AI LLM hijack breach coverage shows why this matters operationally: once an agent can chain tools, a single over-permissioned step can become lateral movement or silent data exposure. Teams should log the child principal, decision inputs, policy outcome, and tool response so incident response can reconstruct intent as well as execution.
- Use workload identity for the subagent, not just a shared parent token.
- Evaluate tool access at request time with policy-as-code and current context.
- Issue JIT credentials for sensitive tools and revoke them when the task ends.
- Record consent, arguments, and approval outcome for audit and abuse investigation.
These controls tend to break down when MCP servers rely on shared service accounts or broad server-side allowlists because the platform can no longer distinguish one subagent’s intent from another’s.
Common Variations and Edge Cases
Tighter tool governance often increases latency and operator overhead, requiring organisations to balance safety against workflow friction. That tradeoff is real, especially when subagents are used for high-volume support, software delivery, or research tasks where frequent approvals can become a bottleneck.
There is no universal standard for this yet, but several patterns are emerging. Low-risk tools, such as read-only lookup functions, may be governed with coarse-grained policy, while high-risk tools need per-call approval. Some teams cache trust for a short session window, but that should be treated as a risk decision, not a default entitlement. For multi-agent pipelines, each downstream agent should inherit only the minimum context needed, because prompt injection or tool output poisoning can cause a child agent to misuse an otherwise legitimate capability. This aligns with the threat patterns discussed in the OWASP NHI Top 10 and the Top 10 NHI Issues.
One practical edge case is delegated admin workflows, where a human approves a subagent to act on their behalf. That approval should be time-boxed, scope-limited, and revocable, because human consent does not equal blanket trust for every later tool call. Another is regulated data access, where auditability is as important as prevention. In those environments, approval logs and policy decisions are often more valuable than raw allowlists, because they show why the agent was permitted to act.
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 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 | Covers tool misuse and agentic overreach in autonomous subagents. |
| CSA MAESTRO | GOV-2 | Addresses governance and authorization for agentic workflows. |
| NIST AI RMF | Supports contextual, accountable risk decisions for AI actions. |
Define delegated-agent approvals, logging, and revocation before tool execution.
