They should restrict which skills can be installed, require approval for policy-bearing content, and monitor where those skills are active. The key is to prevent unmanaged replication and ensure updates propagate from one trusted release path. That keeps the skill layer aligned with the organisation’s current controls.
Why This Matters for Security Teams
Shared skills can turn an AI assistant into a fast-moving distribution channel for logic, prompts, tool calls, and policy decisions. That creates a governance problem as much as a technical one: a skill is not just code, it can also carry operational behaviour. If one assistant installs an unsafe or stale skill, the same weakness can spread across environments with very different risk tolerance. The result is often inconsistent enforcement, hidden privilege expansion, and gaps in auditability.
Security teams also need to think about whether a skill changes what the assistant is allowed to do, not just what it says. A skill that invokes tools, reads internal data, or changes workflow state can function like an identity-bearing extension of the agent. Current guidance suggests treating those skills as controlled software artefacts with explicit owners, release channels, and review gates, aligned to NIST Cybersecurity Framework 2.0. In practice, many security teams encounter skill sprawl only after an assistant has already inherited a risky capability from an unreviewed package.
How It Works in Practice
The safest pattern is to manage shared skills as governed assets, not ad hoc add-ons. That means defining which skills are approved, who may publish them, how updates are signed or otherwise authenticated, and where they are permitted to run. If a skill can be installed by multiple assistants, teams should assume that every copy needs the same control baseline, logging, and rollback path.
A practical control model usually includes the following steps:
- Limit installation to a curated allowlist of skills that have been reviewed for data access, tool use, and policy impact.
- Require approval for skills that alter guardrails, routing, retrieval scope, or any action that can affect users or systems.
- Track skill provenance, version, and deployment scope so the team can answer where each skill is active.
- Test updates in a controlled environment before promoting them across production assistants.
- Log skill execution and tool invocation so incident response can reconstruct what the assistant actually did.
This approach fits well with control families in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around configuration management, access enforcement, and auditability. It also helps teams keep skill behaviour aligned with the assistant’s intended trust boundary, rather than allowing each deployment to improvise its own security posture. For environments that use a central skill registry, the registry should become a policy checkpoint, not just a catalogue. These controls tend to break down when assistants can sideload skills from external repositories because provenance, version control, and approval boundaries become difficult to enforce consistently.
Common Variations and Edge Cases
Tighter skill control often increases deployment overhead, requiring organisations to balance agility against review depth. That tradeoff is especially visible when product teams want rapid experimentation but security teams need stable enforcement. There is no universal standard for skill governance yet, so current guidance suggests matching control strength to the skill’s blast radius, data sensitivity, and tool privileges.
Some environments will need stricter handling than others. A skill that only formats responses may justify lightweight review, while a skill that can trigger workflows, access internal documents, or call external APIs should be treated more like privileged software. Where assistants are embedded in regulated workflows, teams should also consider whether skill updates need change management approval, model risk review, or records retention. The same is true when skills are shared across tenants, business units, or partners, because one weak release process can undermine many downstream controls. For governance programs, the key question is not whether the skill is useful, but whether its current version is still authorised for the places it is installed.
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 and MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 | Shared skills change the organisation's operating context and control scope. |
| NIST AI RMF | GOVERN | Skill approval and provenance are governance issues for AI-enabled systems. |
| OWASP Agentic AI Top 10 | Installed skills can expand agent actions and create prompt or tool abuse paths. | |
| NIST SP 800-53 Rev 5 | CM-3 | Skill installation and changes should follow formal configuration change control. |
| MITRE ATLAS | AML.TA0001 | Untrusted skill content can be used to influence model or agent behaviour. |
Set policy, approval, and accountability rules before skills can alter assistant behaviour.
Related resources from NHI Mgmt Group
- How should security teams reduce risk when AI assistants can drive browser sessions?
- How should teams reduce the risk of exposed AI credentials being abused?
- How should security teams reduce risk from AI agents and developer tools that use secrets locally?
- How should security teams reduce the risk of AI tool poisoning?
