Delegation spectrum in AI gateways: tools, skills, sub-agents

At a glance

What this is: This analysis separates tools, skills, and sub-agents in AI gateways and shows that each rung requires a different governance model because delegation changes who acts, what is auditable, and how risk scales.

Why it matters: IAM, PAM, and AI platform teams need to distinguish these rungs so they do not apply call-level controls to reasoning delegates, where identity, scope, and traceability have to be managed per principal.

Context

AI gateway governance breaks when teams treat every delegated action as if it were the same kind of identity event. A tool is a single executed action, a skill is a packaged procedure, and a sub-agent is another reasoning principal with its own context and tool use.

The practical problem for identity programmes is that each rung needs a different control surface. Call-level authn/authz can govern tools, but skills need versioned provenance and registry control, while sub-agents need scoped identity, bounded permissions, and traces that show what happened inside the delegation chain.

Key questions

Q: How should teams classify delegated work in AI gateways?

A: Classify delegated work by the governance unit it actually creates. Use call-level controls for tools, artifact governance for skills, and principal-level controls for sub-agents. If a delegate reasons independently or carries its own budget and trace, it is no longer a simple function call and should be governed as a separate actor.

Q: Why do sub-agents create more accountability risk than tools or skills?

A: Sub-agents create more accountability risk because they are separate reasoning principals, not just packaged instructions or callable actions. Once a delegate can choose steps inside its own context, a single opaque handoff can hide multiple decisions, tool calls, and scope changes. That makes attribution, review, and incident reconstruction much harder than with a simple function call.

Q: What are the signs that a skill registry is being misused?

A: Look for copied procedures, version drift, and inconsistent behaviour across agents using what appears to be the same skill. If you cannot say which version is mounted where, the registry is not governing behaviour. Skills that live in paste buffers instead of a reviewed registry become invisible policy changes.

Q: What should security teams do when a delegate inherits the parent’s permissions?

A: They should treat inherited permissions as a design smell and re-scope the delegate explicitly. If a sub-agent can write, reach sensitive data, or act in production because the parent could, the control model is too coarse. Separate identity, narrow tool access, and an auditable trace are the minimum conditions for safe delegation.

Technical breakdown

What changes when a delegate becomes a principal?

A tool executes one bounded action and returns a result. A skill packages reusable procedure and changes how an agent reasons, but it still does not act independently. A sub-agent is different in kind: it reasons through a subtask with its own model call budget, tool access, and context window. That shift matters because the governance object changes from call, to artifact, to principal. If a system can make intermediate decisions on its own, the parent can no longer treat it as a simple function invocation. The identity boundary moves inward, and the audit question becomes whether the delegate had its own scope, trace, and accountability.

Practical implication: Map each delegated capability to the correct governance unit before approval, review, or logging.

Why skills need registry governance, not call governance

Skills are not executable endpoints. They are versioned procedural artifacts that shape how an agent behaves when it mounts them into context on demand. That means the risk is not the call itself but silent behavior drift when the skill text changes, forks, or goes stale across agents. The right control problem is provenance, version pinning, review status, and change visibility across every agent using the skill. In identity terms, the skill registry becomes the place where behavioural authority is controlled, because the agent is borrowing structured know-how rather than invoking a service.

Practical implication: Treat skills as governed artifacts with version control, review status, and RBAC on the registry.

How sub-agent identity changes blast radius

A sub-agent is not a tool with a fancier prompt. It is a delegate with its own reasoning loop, and that means it can create side effects that are not visible in the parent's immediate step log. It may also inherit too much if the harness does not scope permissions explicitly. Once that happens, the parent no longer knows whether a result came from a bounded helper or a hidden second principal. The problem is not only privilege excess. It is the loss of principal-level traceability, where the system can no longer explain who did what, under which scope, and with which budget.

Practical implication: Give sub-agents their own identity, isolated permissions, and step-level traces.

Threat narrative

Attacker objective: The practical objective in this failure pattern is uncontrolled execution under the wrong governance regime, allowing a delegate to act with more authority and less visibility than intended.

1. Entry occurred when a delegate was misfiled as a tool and treated as a simple function call rather than as a reasoning principal.
2. Credential and permission scope expanded because the sub-agent inherited the parent's grants wholesale instead of receiving an explicitly bounded scope.
3. Impact followed when the hidden delegate executed up to fifteen reasoning steps under opaque trace conditions, creating a blast-radius surprise that security review could not see in time.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

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

Delegation is now an identity boundary, not just an engineering pattern: AI gateways do not simply route work, they decide which actor is allowed to act and under what governance model. Once a system can reason, the control question changes from call legitimacy to principal legitimacy. That is why tool, skill, and sub-agent must be treated as separate identity surfaces, not interchangeable implementation styles. The practitioner conclusion is simple: govern the delegation rung, not the label.

Sub-agents collapse call-level assumptions: Per-call controls were designed for bounded actions with observable inputs and outputs. That assumption fails when the actor reasons across multiple steps, selects intermediate actions, and returns only a summary, because the meaningful security event is no longer the call but the delegated decision sequence. The implication is that audit and authorisation models built for tools cannot be reused unchanged for reasoning delegates.

Skills create governance debt when they are treated like code snippets: A skill is not just reusable text, it is behavioural authority distributed through an organisation. When versioning, provenance, and registry RBAC are missing, the same procedure can drift silently across many agents. The governance lesson is that behavioural reuse needs artefact governance, not just prompt review.

Identity must follow the agent's autonomy, not the team's vocabulary: The most dangerous mistake in this spectrum is naming a sub-agent as a tool because it feels operationally convenient. Vocabulary does not change the fact that a reasoning delegate can carry its own budget, its own trace, and its own failure modes. The practitioner implication is to align approval, scoping, and tracing to what the delegate actually is, not what the developer called it.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Delegation spectrum governance: AI programmes need a policy boundary that distinguishes a call, a procedure, and a reasoning principal before those concepts are embedded into production routing. If the governance model is flat, the identity model will be flat too, and that is where hidden blast radius appears.

Tools, skills, and sub-agents should be mapped to separate audit and authorisation paths because the evidence each one produces is structurally different. A good AI gateway does not just control access, it preserves the meaning of the delegation path for later review.

For practitioners

• Classify delegated work by governance unit Separate one-off actions, packaged procedures, and reasoning delegates in your AI gateway design so each rung maps to the correct control model.
• Require per-principal scoping for sub-agents Assign explicit identity, scoped permissions, and bounded context to any delegate that reasons independently, even when it sits inside a larger parent workflow.
• Version and review skills as governed artefacts Store reusable procedures in a registry with version pinning, review status, and RBAC so behaviour changes are visible before they spread.
• Audit tool descriptions for misuse risk Treat vague or overlapping tool descriptions as a governance defect because unclear descriptions can cause the model to choose the wrong action with fully valid authorisation.
• Trace delegation chains end to end Log which principal handed off which subtask, what scope was granted, and what happened inside the delegate so review can reconstruct the full path.

Key takeaways

• AI gateways expose a governance problem, not just a routing problem, because delegation changes the actor being controlled.
• The strongest failure pattern is misclassifying a reasoning delegate as a tool, which hides principal-level risk behind call-level controls.
• Teams should align identity, scope, versioning, and tracing to the delegation rung actually in use.

Key terms

• Delegation spectrum: The delegation spectrum is the progression from tool to skill to sub-agent, where each rung adds more capability and more governance complexity. It is useful because it forces teams to match identity controls to runtime behaviour instead of assuming one policy model fits all.
• Subagent: A subagent is a secondary AI worker that performs a narrower task inside its own context and authority boundary. It helps keep the main model clean, reduces confusion from bulk data, and supports more auditable task separation.
• Skills Registry: A catalog of reusable multi-tool workflows that an agent can invoke to complete a task. It extends governance from single tool access to packaged action sequences, which means evaluation, approval, and revocation need to follow the skill itself, not just the underlying tools.
• Per-Principal Governance: Per-principal governance is the practice of controlling a reasoning actor as its own entity rather than as a function call. In autonomous or semi-autonomous delegation chains, it means identity, scope, budget, and traceability must attach to the delegate itself.

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.