What should teams do when an agent can spawn subagents or add tools at runtime?

Why This Matters for Security Teams

When an agent can spawn subagents or add tools at runtime, the security question is no longer just who signed the deployment. It is what the system can become after launch. That makes runtime composition a control issue, because each added tool, connector, or delegated subagent changes the agent’s reachable data, actions, and escalation paths. Guidance from the OWASP Agentic AI Top 10 and NHIMG’s OWASP NHI Top 10 both point to the same operational reality: composition expands attack surface faster than static reviews can track.

Teams often miss that runtime additions can bypass the assumptions embedded in approved architecture diagrams. A subagent may inherit context, reuse credentials, or chain tools in ways that were never reviewed during design. The result is a moving trust boundary, not a fixed one. NHI Management Group research shows that 97% of NHIs already carry excessive privileges, which means many environments are primed for overreach when agents gain new capabilities without fresh controls. In practice, many security teams encounter privilege expansion only after a new tool has already been attached, rather than through intentional approval of the change.

How It Works in Practice

The safest pattern is to treat every runtime composition event as a governed identity and authorization change. That means the platform should maintain a live inventory of the parent agent, its subagents, its active tools, and the secrets or workload identities each component can use. Static RBAC alone is too blunt for this problem because the agent’s behaviour is goal-driven and may change from task to task. Current guidance suggests combining policy-as-code with request-time evaluation so approvals are based on the exact tool, data scope, and objective involved.

For many teams, that translates into three controls:

• Require approval for any new tool class, external connector, or subagent that expands data access or execution authority.
• Issue JIT credentials and short-lived workload identity tokens for the specific task, then revoke them automatically when the task ends.
• Log the full composition chain so responders can see which component introduced a new permission, token, or downstream call path.

That approach aligns with the NIST AI Risk Management Framework and the CSA MAESTRO agentic AI threat modeling framework, both of which emphasize lifecycle governance and context-aware risk decisions. For implementation detail, cryptographic workload identity patterns such as SPIFFE or OIDC help prove what the agent is at runtime, while policy engines evaluate whether a new subagent or tool is allowed in that context. NHIMG’s Ultimate Guide to NHIs is explicit that visibility and rotation are foundational; runtime composition simply makes those basics non-optional. These controls tend to break down when agents can self-assemble across multiple vendors because component provenance and authorization boundaries become difficult to enforce consistently.

Common Variations and Edge Cases

Tighter runtime control often increases operational friction, requiring organisations to balance rapid agent adaptation against approval overhead. That tradeoff is real, especially for engineering copilots, research agents, and multi-agent workflows that legitimately need to discover tools on demand. There is no universal standard for this yet, but current guidance suggests classifying runtime additions by risk: read-only tools may be auto-approved under narrow conditions, while write-capable tools, identity-bearing subagents, and anything touching production systems should require explicit review.

Edge cases usually appear when the environment already has weak secret hygiene or broad delegated access. If an agent can add a subagent that inherits the parent’s token, then one approval can effectively unlock an entire chain of actions. That is why runtime composition should be paired with least-privilege scoping, per-tool allowlists, and automatic expiry on all ephemeral credentials. The AI LLM hijack breach and Anthropic report on AI-orchestrated cyber espionage both illustrate how fast an apparently contained agent workflow can be redirected once tool access expands. Best practice is evolving, but the practical rule is simple: if the agent can create a new capability at runtime, that creation step itself needs a control, not just the capability after the fact.

Related resources from NHI Mgmt Group

• How should teams think about AI agent privileges?
• How should security teams handle AI agent visibility?
• How should security teams monitor AI agent activity without disrupting developers?
• What do IAM teams get wrong about service accounts and AI agent permissions?