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

At a glance

What this is: This is an analysis of the delegation spectrum inside AI gateways, showing why tools, skills, and sub-agents require different governance models.

Why it matters: It matters because IAM, PAM, and NHI teams increasingly have to govern AI systems that delegate differently at runtime, and misclassifying the delegate turns access controls into blind spots.

By the numbers:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read TruFoundry's analysis of the delegation spectrum for AI gateways

Context

AI delegation becomes a governance problem when different runtime behaviours are treated as the same kind of access. In this article, the primary issue is not whether an agent can call a tool, but whether the system is handling a tool, a packaged skill, or a sub-agent that reasons as its own principal.

That distinction matters for AI gateway design, because tools, skills, and sub-agents demand different control surfaces. The article is strongest when read as an identity governance argument: the more autonomous the delegate becomes, the less useful call-level assumptions become.

For teams trying to map this to current practice, the right question is not whether AI systems should be allowed to delegate. It is whether the programme can still explain identity, scope, and accountability once delegation moves from actions to reasoning and from reusable artifacts to separate principals.

Key questions

Q: How should teams govern AI agent skills in production?

A: Treat skills as controlled runtime assets, not informal text. Assign ownership, version them, restrict when they can load, and require evaluation before release. The right question is whether a skill improves a specific model-harness pair under real task conditions, because that is where hidden regressions and overbroad instructions show up.

Q: When does a sub-agent become a governance risk instead of a convenience?

A: A sub-agent becomes a governance risk when it reasons independently, uses tools on its own, and returns an opaque result that the parent cannot fully inspect. At that point, per-call controls no longer describe the real behaviour, and the organisation needs principal-level oversight.

Q: What do security teams get wrong about delegation in AI agent workflows?

A: They often assume a delegation chain is just a workflow detail. In practice, each hop can widen blast radius, obscure accountability, and make revocation harder. If the chain is not explicit, an agent can inherit more authority than the human intended, especially when sub-agents and tools are chained together.

Q: How do you know if an AI gateway is governing delegation correctly?

A: You know it is working when the governance object matches the runtime behaviour. If a function call is logged, a procedure is versioned, and a delegate is traced as its own principal, the control model is aligned. If not, the system is probably misclassifying risk.

Technical breakdown

Why tools, skills, and sub-agents are not interchangeable

A tool is a discrete action invoked through a structured call, such as an API request or database query. A skill is a reusable procedure or knowledge bundle that shapes how an agent works, but does not execute anything itself. A sub-agent is a separate delegate with its own model call, context, and reasoning loop. The operational difference is the governance boundary: call-level checks work for tools, artifact governance fits skills, and principal-level controls are needed for sub-agents.

Practical implication: classify every delegated capability by execution model before assigning authz, logging, or review controls.

Why sub-agents create a principal-level governance problem

The article’s central warning is that a sub-agent is not a larger tool. Once a delegate can reason independently, inherit tools, and return opaque results, the parent no longer sees every intermediate step. That makes per-call authorization insufficient because the real behaviour is distributed across an autonomous work loop. Governance has to follow the delegate as an identity-bearing actor, not just the request it eventually returns.

Practical implication: assign identity, scope, traceability, and resource limits to each sub-agent as if it were a separate workload.

How context budgeting becomes part of governance

The spectrum is also a context-engineering model. Tools carry description overhead and return results into the parent window, skills load only when needed, and sub-agents offload an entire subtask into their own context. That means the governance choice and the cost choice are linked. A design that ignores context pressure often ends up overloading the parent agent, which can conceal risky delegation patterns inside a bloated working window.

Practical implication: review delegation choices for both security boundary and context cost before standardising an AI workflow.

NHI Mgmt Group analysis

Delegation spectrum governance is an identity problem, not a taxonomy problem. The article correctly shows that tools, skills, and sub-agents represent different kinds of runtime delegation, not just different labels. Once that is true, the governance question changes from "what feature is this?" to "what identity surface does this create?" That is the right model for AI gateways and NHI governance alike, because control strength should match the delegate’s decision authority.

Sub-agents should be governed as principals, not as calls. A sub-agent reasons, can use tools, and may operate across several steps before returning a result. That means call-level guardrails alone are structurally incomplete. The governance surface shifts from request inspection to principal lifecycle, scope, traceability, and bounded execution, which is exactly where IAM and PAM thinking becomes relevant to agentic systems.

Lowest-rung design is the correct control philosophy for AI delegation. The article’s advice to choose the lowest rung that does the job is more than an engineering preference. It is a control principle that reduces blast radius by preventing unnecessary escalation from action to procedure to principal. Teams that skip rungs by default will create more identity surface than their governance model can explain.

Context-window pressure is an overlooked source of governance failure. A delegate can be risky not only because it is autonomous, but because the parent loses visibility as context grows and subtasks are pushed out of view. That is why delegation design, auditability, and context management now belong in the same conversation. Practitioners should treat hidden context as part of the attack surface and the governance surface.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials, according to AI Agents: The New Attack Surface report.
• A separate finding shows that only 52% of companies can track and audit the data their AI agents access, which leaves 48% with no reliable compliance or investigation view.
• That is why the next control question is not just access policy but delegation visibility, as explored in OWASP NHI Top 10.

What this signals

Delegation will become a governance boundary in the same way identity lifecycle already is. Teams that still treat all agent activity as a single policy domain will struggle to explain who acted, under what authority, and with what trace. The practical shift is toward separate control models for action, procedure, and delegated principal, which should be reflected in gateway design and audit architecture.

Identity teams should expect sub-agents to drive new review and recertification demands. As delegates become more independent, the organisation will need to know not only what they can do, but which agents use them, which versions are mounted, and whether their traces are complete. That pushes gateway governance closer to NIST Cybersecurity Framework 2.0 style accountability and to lifecycle thinking for non-human identities.

For practitioners

• Classify delegation before you govern it Inventory every AI capability as a tool, skill, or sub-agent, then map each class to the correct control surface. Tools need per-call authn/authz and guardrails, skills need versioned artifact governance, and sub-agents need identity, scope, and traceability.
• Assign principal-level controls to sub-agents Give each sub-agent its own identity, bounded permissions, resource budget, and trace. Do not let a reasoning delegate inherit the parent’s grants wholesale, because that turns an opaque work loop into unaudited privilege.
• Version and review skills as governed artifacts Store reusable procedures in a registry with provenance, change control, and role-based access. Treat the skill as executable organizational knowledge, because silent edits to a shared procedure change behaviour across every agent that mounts it.
• Measure delegation by completed-task risk, not call count Evaluate whether a sub-agent reduces or enlarges the parent agent’s exposure once context size, reasoning depth, and reviewability are included. A lower call count is not safer if the work becomes less visible and less attributable.

Key takeaways

• The article’s core lesson is that AI delegation is not one problem but three, and each rung needs a different governance model.
• Sub-agents are the highest-risk rung because they operate as delegated principals, which makes call-level controls incomplete on their own.
• Teams that standardise on the lowest rung that does the job will reduce blast radius, preserve auditability, and keep AI governance explainable.

Key terms

• Tool: A tool is an MCP-exposed action that the model can choose to call at runtime. It is the equivalent of an executable privilege boundary, because its name, description, and schema influence what the agent believes it may do and what backend actions it can trigger.
• Skill: A skill is a modular instruction package that teaches an agent how to perform a task at runtime. It can include a markdown instruction file, metadata, scripts, and supporting documents. In agentic environments, a skill is not passive documentation. It is an active control input that can shape behaviour, tool use, and execution.
• 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.
• 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.

What's in the full article

TruFoundry's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step governance mapping for tools, skills, and sub-agents across the gateway, registry, and harness layers.
• Implementation examples for per-call guardrails, versioned skill artifacts, and isolated sub-agent traces.
• The delegated-workflow patterns that show how context windows, scope, and reviewability change as you move up the spectrum.
• Practical product-oriented explanation of how the MCP Gateway, Skills Registry, and Agent Harness separate control surfaces.

👉 TruFoundry's full post shows how tools, skills, and sub-agents are separated across gateway, registry, and harness controls.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in the 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.