They assume Git solves the full problem, when it really only handles source control. Skills also need discovery, installation, runtime visibility, and revocation across different AI clients. Without that broader control layer, repository discipline can coexist with uncontrolled distribution and hidden version drift.
Why This Matters for Security Teams
Git is often treated as the control plane for skills, but that view is too narrow. A repository can store code, yet it does not guarantee that a skill is discovered, installed, invoked, versioned, or removed in the client where an AI agent actually uses it. That gap turns a tidy development practice into an operational risk: stale skills remain active, shadow copies spread across endpoints, and owners lose sight of what is executing in production. The NIST Cybersecurity Framework 2.0 is useful here because it reminds teams that asset and control visibility matter as much as code management.
Security teams also underestimate how quickly skills become a governance issue. Once a skill can trigger tools, call APIs, or influence other systems, it behaves like privileged automation, not just documentation. That means approval, provenance, and revocation all matter. If Git is the only place where change is tracked, the organisation may still have uncontrolled execution paths in multiple AI clients, internal sandboxes, or agent runtimes. In practice, many security teams encounter skill sprawl only after a leaked or outdated skill has already been invoked in production rather than through intentional lifecycle management.
How It Works in Practice
Managing skills properly requires a lifecycle view that extends beyond the repository. Git remains valuable for source control, peer review, and change history, but it should be paired with controls that manage discovery, installation, runtime permission, and retirement. The practical question is not only “what changed in Git?” but also “where is this skill installed, who can invoke it, and what version is currently active?”
A strong operating model usually includes:
- central registration of approved skills and their owners;
- signed or otherwise integrity-checked skill packages to reduce tampering risk;
- version pinning so AI clients do not silently drift to a different implementation;
- runtime inventory across all clients that can load or execute skills;
- revocation procedures that remove access, not just archive the repository.
This is where identity and privilege governance start to matter. If a skill can access secrets, call internal APIs, or trigger workflows, it needs the same scrutiny as any privileged automation. Good practice is to treat skill distribution like software release management combined with access governance, rather than as a simple content sync from Git. Current guidance suggests teams should maintain a clear chain from authored code to deployed skill to active runtime, with ownership attached at each stage.
For implementation detail, security leaders can borrow from controls thinking in the NIST Cybersecurity Framework 2.0, especially around asset management, access control, and recovery. The important operational test is whether the organisation can answer three questions quickly: what skills exist, where are they running, and how are they removed when no longer approved. These controls tend to break down when multiple AI clients cache skills locally because version drift and delayed revocation make the repository state no longer match the runtime state.
Common Variations and Edge Cases
Tighter skill governance often increases operational overhead, requiring organisations to balance developer speed against execution control. That tradeoff becomes more visible in environments where teams want rapid experimentation, but the same skill can be deployed to many clients with different update behaviour. There is no universal standard for this yet, so the right approach depends on whether the organisation prioritises release velocity, auditability, or strict runtime control.
Edge cases appear when skills are generated dynamically, pulled from external marketplaces, or bundled inside agent frameworks that abstract away installation details. In those cases, a Git repository may record the definition but not the actual runtime artefact. The result is a split between source truth and execution truth, which makes review evidence incomplete. Organisations should be especially cautious when skills can call secrets managers, SaaS APIs, or internal tooling, because a revoked repository commit does not automatically revoke those permissions.
For teams using experimental agents, best practice is evolving toward explicit runtime attestation and centralized approval before distribution. Where those capabilities are missing, the safer assumption is that any uncontrolled client cache can outlive the intended lifecycle. The practical lesson is that Git is necessary for traceability, but insufficient for enforcement. Without installation and revocation controls, the same skill can remain active long after the repository looks clean.
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 OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM | Skills need inventory and ownership visibility beyond source control. |
| OWASP Agentic AI Top 10 | Agentic systems can execute skills with tool access and privilege. | |
| OWASP Non-Human Identity Top 10 | Skill execution often relies on non-human identities and credentials. | |
| NIST AI RMF | Governance is needed across the full AI lifecycle, not only source control. |
Bind each skill to owned machine identities and rotate or revoke its credentials on decommission.
