Agent skills are executable dependencies; govern them like software
The Agent Skills format makes reusable instructions and resources portable across AI tools. That convenience creates a supply-chain boundary: organisations need provenance, review, version pinning and revocation before a skill can act.

What happened
The open Agent Skills specification packages instructions, scripts and resources into portable folders that compatible agents can discover and load; Anthropic documents their use in Claude.
Why it matters
A skill can change what an agent reads, generates or executes. Treating it as mere documentation leaves provenance, malicious updates, excessive permissions and rollback outside normal software controls.
The Agent Skills specification defines an open folder format for reusable instructions, scripts and resources that compatible agents can discover and load. Anthropic's documentation presents skills as capability packages for Claude. This can make specialised procedures portable across tools and teams, but portability also moves a familiar software supply-chain problem into the agent layer.
A skill is not merely a page of guidance. It can tell an agent when to load supporting material, which script to execute, how to shape an output and how to combine a task with external tools. The exact authority depends on the host product and deployment configuration, yet the governance question remains: who authored this dependency, what version was reviewed, what can it do, and how can it be disabled when conditions change?
Build an approved dependency boundary
An enterprise registry should record the skill's source, maintainer, licence, review owner, version, checksum and declared capabilities. Imported community skills should not become trusted merely because their folder structure is valid. Review needs to cover instructions, bundled code, referenced URLs, expected inputs and outputs, data handling and any tools the host may expose. The registry should pin an approved version rather than silently follow the latest upstream state.
The host also needs least-privilege enforcement. A writing skill should not inherit unrestricted file or network access simply because the agent has those capabilities elsewhere. Permissions should be granted per skill and environment, with explicit separation between read-only research, draft generation and state-changing actions. Secrets should never be embedded in the package. If credentials are needed, the host should broker narrowly scoped access and preserve an audit trail.
CISA's Secure by Design guidance is not specific to Agent Skills, but its general principle is relevant: responsibility for safe defaults should sit with the product and deployment design, not with each user remembering every hazard. A catalogue badge or popularity count is weak evidence. Stronger evidence includes a reproducible review, signed release, dependency inventory, sandbox test and a known revocation path.
Test updates and failure modes
Teams should test prompt injection inside skill resources, unsafe shell arguments, unexpected network destinations, oversized context loading, conflicting instructions and degraded behaviour when a referenced file is missing. They should also test composition: two individually acceptable skills may create a dangerous sequence when one gathers sensitive data and another can transmit or act on it.
Telemetry should identify which skill and version influenced an action. That does not require logging every confidential prompt, but it does require enough metadata to reconstruct the control path. Incident response must be able to quarantine one version, roll back to a known state and find affected executions. These controls also support quality: teams can compare error and override rates before promoting an update.
Ownership also needs a lifecycle. A business expert may own the procedure, but a technical maintainer should own packaging and tests, while security approves permissions and incident handling. Promotion from personal use to a shared catalogue should require a defined reviewer and expiry or revalidation date. If the original maintainer leaves, the skill should not remain indefinitely trusted. This division avoids a false choice between domain accuracy and technical assurance: both are needed before a package can influence production work.
The open format can reduce duplicated instruction engineering and make expertise easier to distribute. It does not remove the need to govern executable dependencies. Procurement should require exportable inventories and incident evidence rather than a catalogue that exists only inside one vendor product. The Skills Atlas can describe the human capabilities needed to author, review and operate skills; an approved registry must connect those capabilities to technical controls and accountable owners.