You lose provenance, version consistency, and rollback clarity. A folder can be copied, edited, or installed from an old snapshot without changing any central record, which means security cannot reliably tell which behavior is active. Governed artifacts solve that by making the installable unit visible, reviewable, and enforceable before runtime.
Why folders break the security model for agent skills
Folders are a distribution convenience, not a governance boundary. If a skill lives as a folder, anyone who can copy, edit, or repackage it can change what is effectively shipped, while the original install path still looks familiar. That makes the active behavior hard to prove, especially when the same content can exist in multiple places with different edits and no authoritative source of truth.
That is the core security problem: the unit being moved around is no longer the unit being governed. A governed artifact gives you a stable object to inspect, approve, sign, inventory, and revoke. A folder gives you a mutable container that can drift silently from what reviewers thought they accepted.
In practice, this means provenance is weak. If the skill is assembled from files in a directory, you may know where the files came from at some point, but not which exact version is installed, whether a local tweak was introduced, or whether an older snapshot was restored after review. Governed artifacts preserve the chain from review to deployment so the installable unit is the same thing you validated.
What governance controls you lose when the installable unit is just a folder
Governed artifacts make versioning and change control explicit. That matters because security teams need to answer simple questions quickly: what is running, who approved it, what changed since approval, and can we roll back to a known-good version without guessing. With folders, those answers often depend on filesystem state rather than policy, which is fragile and easy to desync.
This is also where rollback clarity disappears. A rollback should return you to a specific reviewed artifact, not merely a previous directory layout. If the folder was edited in place, restored from backup, or partially copied across environments, the rollback target may be ambiguous or incomplete, and the result can look successful while still carrying unreviewed behavior.
For agentic systems, that ambiguity is especially costly because skills often sit close to tool access, prompting logic, and execution paths. When the governable object is unclear, approval, enforcement, and incident response all inherit the same uncertainty. For a broader view of how agent identity and control decisions change as autonomy increases, see the AI Agents vs Agentic AI guide.
How to think about skills as governed artifacts, not loose content
The operational goal is to make the skill package the thing you review, attest, and allow, not the directory tree that happens to contain it. That usually means an immutable or at least versioned artifact with a unique identifier, a clear owner, recorded provenance, and a deployment path that can enforce policy before runtime. The security value is not packaging style alone, it is the ability to prove what was installed and prevent silent substitution.
That model also improves enforcement at the edge of execution. If policy is tied to the artifact version, then runtime systems can block unapproved changes, detect drift, and distinguish sanctioned updates from ad hoc edits. This is the same basic control logic behind managed release processes in other software supply-chain contexts, where the released object must be identifiable and verifiable before it is trusted. When build and release integrity matter, use the SLSA approach to keep provenance attached to the thing you deploy, not the folder that carries it.
A useful way to design the control is to separate content authoring from runtime installation. Authors can create or update skill definitions, but the platform should only execute signed, approved, and inventoryable versions. That avoids the common trap where convenience in development turns into uncontrolled change in production.
Risk and Threat Considerations
When skills are folder-based, the main risk is unauthorized or untracked behavior change. An attacker, insider, or careless operator can swap files, add a malicious helper, or restore an old version with known weaknesses while leaving little evidence that the governed unit changed.
Failure mechanism: The platform cannot reliably distinguish the approved skill from a copied, edited, or stale version because governance is attached to mutable storage rather than to an immutable artifact identity.
Impact: Security teams lose trustworthy provenance, rollback becomes uncertain, and review controls can be bypassed even when the folder path still looks legitimate. That creates room for hidden capability drift, unsafe tool use, and delayed incident containment.
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 Agentic Skills Top 10 address the attack and risk surface, while SLSA sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity | Skills need an immutable, verifiable release object with clear provenance. |
| Recommendation — Bind each skill release to a verifiable artifact and block unapproved substitutions. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Folder drift can change what an agent is authorized to do at runtime. |
| ASI04 — Agentic Supply Chain Vulnerabilities | Mutable folders undermine review, provenance and trusted deployment of skills. | |
| Recommendation — Enforce per-action authorization on the governed skill version before execution. Require signed, reviewable skill artifacts and reject untracked content changes. | ||
| OWASP Agentic Skills Top 10 | Agentic skill layer security | The question is specifically about skill packaging and governance as the control point. |
| Recommendation — Publish skills as governed artifacts with versioned release and installation controls. | ||
Practitioner Guidance
What to verify: Confirm that every deployable skill has a unique version identifier, an owner, an approval record, and a mechanism that prevents in-place mutation after release. If any of those live only in documentation or convention, the control is not strong enough.
Decision rule: If you cannot answer “which exact artifact is active right now?” without inspecting a live folder, move the skill to governed packaging before treating it as production-ready. If you can answer that question only by inference, you do not yet have rollback clarity.
Practitioner takeaway: Treat the folder as a storage detail and the artifact as the control boundary, because governance only works when the thing you approve is the same thing you can later prove is running.
Related resources from NHI Mgmt Group
- What breaks when AI skills are shared informally instead of governed centrally?
- What breaks when third-party agent skills are not governed like privileged inputs?
- What breaks when internal apps are shared informally instead of through a governed publishing process?
- What breaks when app access depends on shared admin passwords instead of a governed service account?