They often collapse all three into a single delegation category, which hides the different governance needs behind each one. Tools need per-call authorization, skills need provenance and versioning, and sub-agents need identity, isolation and traceability. If those controls are not separated, policy gaps appear exactly where the system can act on its own.
Why Tools, Skills, and Sub-Agents Need Different Governance
Security teams get into trouble when they treat tools, skills, and sub-agents as if they all represent the same kind of delegated action. They do not. A tool is usually a bounded capability invoked for one call, a skill is a packaged capability with its own provenance and update path, and a sub-agent is an autonomous actor with identity, isolation, and traceability requirements. The control model has to match the thing being delegated.
That distinction matters because the failure mode changes with the object. A tool can be safe in one request and unsafe in the next if authorization is too coarse. A skill can be trustworthy at install time and unsafe after silent replacement or version drift. A sub-agent can be well-intentioned but still create uncontrolled side effects if it can chain actions, retain context, or operate without clear ownership.
This is why teams should avoid one umbrella policy for all three. If the governance model is too generic, it leaves gaps in the exact place where the system can act without a human in the loop. A tool policy that never asks who can invoke it is weak. A skills policy that does not track provenance is weak. A sub-agent policy that does not define identity boundaries is weak.
How the Control Model Changes by Capability Type
Tools are best governed as per-call decisions. The main question is whether the specific request should be allowed right now, with this principal, for this target, under this context. That means authorization, scope, and effect boundaries matter more than long-lived trust. The right mental model is controlled delegation, not general permission to behave like the caller.
Skills are different because they behave more like supply chain objects. Teams should care about where the skill came from, who signed or published it, what version is installed, and whether the contents changed since review. A skill can be technically harmless in isolation and still become risky when its prompt, dependencies, or permission assumptions change without review. NHIMG’s Agentic AI Security Policy Template is useful here because it frames registration, monitoring, and retirement as lifecycle controls rather than ad hoc approvals.
Sub-agents require a stronger model again because they can accumulate authority through delegation chains, not just single actions. If a sub-agent can call tools, hand work to another agent, or retain state across tasks, then identity, isolation, and auditability become first-class controls. NHIMG’s Agentic AI Identity Guide is directly relevant because it treats registration, authentication, delegation, and retirement as separate lifecycle stages. That separation is what prevents “agent” from becoming a vague label for uncontrolled automation.
Where Security Reviews Go Wrong in Practice
The most common mistake is reviewing all three through the same lens of “can it do the job?” instead of asking what kind of authority it exercises. For tools, the important question is whether access is granted per action. For skills, the important question is whether the artifact is trustworthy, current, and versioned. For sub-agents, the important question is whether the autonomous entity can be observed, segmented, and attributed when it acts.
Security teams also overestimate the value of static approvals. A skill that looked safe during onboarding can later pull in a new dependency or encode a different behavior. A sub-agent that started as a narrow helper can expand into a routing layer for many downstream actions. A tool that was intended for read-only lookup can become dangerous if the same interface can eventually trigger write operations. NHIMG’s AI Agent Authorisation Guide addresses the per-action decision point that too many teams skip when they rely on broad role assignment or one-time approval.
The other recurring failure is poor traceability. If the team cannot tell which capability was used, by whom, and under what policy, then incident review becomes guesswork. That is especially painful for sub-agents, because their actions may be indirect and their blast radius larger than the initiating request suggests. NHIMG’s AI Agent Observability, Audit and Incident Response Guide helps anchor this problem in practical logging, attribution, and response decisions.
Risk and Threat Considerations
When teams flatten tools, skills, and sub-agents into one category, they create policy gaps that attackers or defective automation can exploit. The main exposure is not just over-permission, it is mismatched control design: coarse authorization for tools, weak provenance for skills, and poor containment for sub-agents. That combination makes it easier for a benign-looking action to turn into unauthorized access, hidden persistence, or unsafe side effects.
Failure mechanism: A tool is invoked with broad standing privilege, a skill is updated or swapped without integrity checks, or a sub-agent inherits more authority than the task requires. In each case, the system gains a path to act outside the intended boundary while still appearing to operate normally.
Impact: The result can be credential exposure, unauthorized tool use, cross-task contamination, or hard-to-attribute actions that complicate containment and recovery. The larger the delegation chain, the more important it becomes to separate authorization, provenance, and identity controls.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Tools, skills, and sub-agents fail when authority is overbroad or inherited unsafely. |
| ASI04 — Agentic Supply Chain Vulnerabilities | Skills need provenance, versioning, and integrity because they are supply-chain objects. | |
| ASI10 — Rogue Agents | Sub-agents need identity, isolation, and traceability to prevent uncontrolled autonomous action. | |
| Recommendation — Separate per-action authorization from identity and containment controls for autonomous actors. Track skill source, version, and integrity before allowing execution. Constrain sub-agents with explicit identity, isolation, and audit trails. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Delegated capabilities rely on credential lifecycle and controlled secret handling. |
| AC-6 — Least Privilege | Per-call authorization and bounded access are central to safe tool use. | |
| AU-2 — Event Logging | Sub-agent traceability depends on complete action logging and attribution. | |
| Recommendation — Manage credentials and secrets with strict lifecycle controls and rotation. Limit each delegated action to the minimum access needed. Log delegated actions with enough detail to attribute who or what acted. | ||
Practitioner Guidance
What to prioritise: Start by classifying every delegated capability as a tool, skill, or sub-agent before you write policy. That classification should drive the control model, not the other way around.
Decision rule: If the capability can make an external call or change state, treat it as a per-action authorization problem. If it can be replaced, updated, or imported, treat it as a provenance and versioning problem. If it can persist, delegate, or chain actions, treat it as an identity and traceability problem.
What good looks like: Tools are approved per request, skills are tied to reviewed versions, and sub-agents have explicit ownership, isolation boundaries, and auditable action trails.
Practitioner takeaway: The control failure usually starts when “delegation” is treated as one concept, but the real security question is whether the thing acting needs authorization, supply-chain trust, or an identity boundary.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org