They should govern skills like untrusted software artifacts with identity implications. That means tracking source, version, update path, and runtime authority together, because the agent inherits whatever the skill can instruct it to do. Supply chain controls and identity controls need to meet at installation time.
How to govern agent skills as supply chain artifacts
Govern agent skills as software supply chain components, not as harmless prompt snippets or documentation. A skill can change what the agent is allowed to do, what it can call, and what data it can expose. That makes provenance, versioning, update control, approval state, and runtime authority part of the same governance object.
The practical test is whether the skill can widen the agent’s effective capability set. If it can, treat installation as an access decision, not just a content deployment step. The supply chain question is therefore inseparable from identity and authorisation, because the agent inherits the skill’s instructions and any trusted paths they open.
Teams should maintain an inventory that ties each skill to a source, version, owner, dependency set, and permitted runtime context. That inventory needs to be strong enough to answer who published it, how it changes, what it can invoke, and where it is allowed to run. Without that linkage, review becomes cosmetic and rollback becomes guesswork.
What “good governance” looks like at installation time
Installation time is the control point where supply chain security and identity controls meet. A skill should not be installed until its source is known, its update path is controlled, and its runtime authority is explicitly bounded. If a skill can instruct the agent to use tools, call APIs, or access shared resources, the allowed actions need to be approved alongside the artifact itself.
Good governance also separates trusted skill content from ambient environment privilege. A skill should not inherit broad standing access simply because the agent already has a session or token. The safer pattern is to grant only the minimum authority required for the skill’s declared function, then revalidate that authority when the skill changes.
Version drift matters. A skill that was acceptable at one version can become materially different after an upstream update, so change control should treat new releases as re-review events, not as automatic refreshes. That is especially important when the skill’s behaviour depends on external packages, remote prompts, or chained tools.
Why this creates supply chain and privilege risk
The main risk is capability escalation through trusted instructions. If a compromised or poorly reviewed skill can direct the agent to execute more powerful actions than intended, the issue is not just malicious content, it is delegated authority abuse. In practice, the danger looks like overbroad tool access, hidden data exfiltration paths, or a skill update that quietly changes the agent’s behaviour.
Supply chain weakness also appears when teams trust the skill source but do not control the delivery path. A tampered package, a swapped dependency, or an unmanaged update channel can turn a legitimate skill into a control bypass. This is why provenance, integrity, and runtime permissioning have to be evaluated together rather than in separate silos.
AI Supply Chain Security and AI-BOM Guide is useful here because it frames models, data, packages, tools, and credential containment as one supply chain problem. For agent skills, the same logic applies: if the artifact can influence execution, it belongs in the chain of trust.
AI Agent Authorisation Guide is the companion control view, because skills only become dangerous when their permissions are broader than the task demands. The key failure mode is not merely that a skill exists, but that it can exercise more authority than the installation review assumed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Skills are supply-chain artifacts that need provenance and controlled updates. |
| IA-5 — Authenticator Management | Skills may embed or depend on credentials, tokens, or keys that need lifecycle control. | |
| AC-6 — Least Privilege | Skill authority should be bounded to the minimum actions needed at runtime. | |
| Recommendation — Verify skill provenance and restrict updates before allowing installation. Track and rotate any secrets a skill can reach or invoke. Limit each skill to the smallest viable action set and revoke excess access. | ||
| CIS Controls v8 | CIS-15 — Service Provider Management | Third-party skill sources need intake, monitoring, and governance like suppliers. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Installed skills change software behavior and require controlled configuration. | |
| Recommendation — Review external skill providers before trusting their updates or dependencies. Baseline approved skills and remove unapproved runtime configurations. | ||
Practitioner Guidance
What to prioritise: Create a single approval record for each skill that links source, version, owner, allowed actions, update channel, and rollback plan. If any one of those fields is missing, the skill is not really governable yet.
What to verify: Confirm that the skill’s declared purpose matches its effective permissions. A skill that can read secrets, call external tools, or modify records should be reviewed as a high-impact artifact even if its code or prompt looks simple.
Decision rule: If a skill update changes the tool set, data access, or external calls it can trigger, treat that as a new authorisation event rather than routine maintenance. Reapprove before rollout.
What practitioners underestimate: The install step is often where trust is silently expanded. Teams commonly audit the model or the agent and overlook the skill layer that actually instructs the agent what to do.
Practitioner takeaway: The safest operating model is to govern skills as executable trust extensions, with the same discipline you would apply to privileged software inputs and delegated access.
Related resources from NHI Mgmt Group
- Should security teams treat agent runtime controls and software supply chain controls as separate programmes?
- How should security teams govern non-human identities at scale?
- How should security teams govern non-human identities for compliance?
- How should security teams govern non-human identities in Salesforce?