Treat agent skill files as executable content, not documentation. Review them with the same controls you apply to source code, including version control, peer review, and allowlisted package checks. Any npx, bunx, pnpm dlx, or yarn dlx command should be validated before merge, because AI agents can execute instructions literally and install hallucinated or untrusted packages.
Why This Matters for Security Teams
agent skill files are a supply chain control point, not a harmless prompt adjunct. When a workflow can trigger npx, bunx, pnpm dlx, or yarn dlx, the file is effectively authorising code execution and package retrieval inside CI or a developer workstation. That puts package provenance, dependency trust, and approval workflow design into the same risk category as build scripts and deployment automation. The OWASP OWASP Agentic AI Top 10 is a useful starting point because it treats agentic execution paths as security-relevant, especially where tool use can cross trust boundaries.
The main mistake is reviewing the prose of the skill file while missing the operational effect of the commands it contains. A package install in a CI runner can introduce transitive dependencies, postinstall hooks, or typosquatted modules even when the file itself looks innocent. Security teams should treat these files as part of the change control surface, with the same scrutiny used for pipeline definitions and dependency manifests. In practice, many security teams encounter the abuse of agent skill files only after an unexpected package execution path has already been merged into an otherwise trusted workflow.
How It Works in Practice
Effective review starts by classifying the skill file as executable workflow content. That means checking who can author it, who can approve it, and what execution context it inherits. A reviewer should be able to answer three questions: what packages may be fetched, what commands may run, and what filesystem or network access the agent has at that moment. Guidance from the NIST AI Risk Management Framework is relevant here because it emphasises governance, mapping, and monitoring for AI-enabled systems, not just model behaviour.
- Require pull request review for any skill file that can trigger installation or shell execution.
- Allowlist package names, registries, and versions where possible.
- Block unsigned, unpinned, or dynamically resolved installs from agent paths.
- Run the workflow in a constrained environment with minimal token scope.
- Inspect for hidden execution such as install-time scripts, remote fetches, or chained commands.
Reviewers should also look for package manager specific risks. npx and dlx-style commands can resolve and execute packages on demand, which is convenient but dangerous when the package name comes from an agent-authored file. If the workflow uses a registry mirror or internal proxy, that proxy becomes part of the trust boundary and needs logging and integrity checks. The same reasoning applies when a skill file references a repository URL, a tarball, or any other non-fixed artifact. Current guidance suggests the safest pattern is to separate agent instruction files from execution manifests, then require an explicit human approval step before any install-capable command is allowed to run. These controls tend to break down when developers optimise for fast local iteration because the approval step is bypassed in the name of convenience.
Common Variations and Edge Cases
Tighter package controls often increase friction for developers, requiring organisations to balance delivery speed against supply chain assurance. That tradeoff is especially visible in monorepos, ephemeral CI jobs, and agent workflows that generate commands at runtime. There is no universal standard for this yet, but best practice is evolving toward explicit trust tiers: read-only agent actions, controlled tool invocation, and separately approved install permissions. The MITRE ATLAS adversarial AI threat matrix and the CSA MAESTRO agentic AI threat modeling framework are both useful for thinking about where malicious or manipulated instructions can drive unintended tool use.
Edge cases include locally trusted developer environments where package installs appear harmless, but the same skill file later lands in CI with broader credentials. Another common gap is internal package namespaces that are assumed safe without artifact signing or provenance checks. Teams should also review rollback behavior: if an agent installs a bad package, can the pipeline revert cleanly, or does the workflow leave behind altered caches and tokens? For broader control mapping, NIST SP 800-53 Rev. 5 helps translate this into concrete change control, configuration management, and system integrity requirements.
Where AI agents can author or edit the skill file themselves, the review standard should be stricter than for static documentation. That intersection between agentic AI and software supply chain control is exactly where latent risk becomes operational.
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 AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | Agent Tool Misuse | Agent-triggered installs are a tool-use risk in agentic workflows. |
| NIST AI RMF | GOVERN | Governance and accountability are needed for AI-driven workflow execution. |
| MITRE ATLAS | Tactic: Influence Operations | Adversarial inputs can steer agents into unsafe package execution paths. |
| NIST CSF 2.0 | PR.IP-1 | Controlled change management is central to reviewing executable skill files. |
| NIST SP 800-53 Rev 5 | CM-3 | Configuration changes must be approved before execution-capable files are merged. |
Assign ownership, approval, and monitoring for agent actions that can change software supply chains.
Related resources from NHI Mgmt Group
- How should security teams reduce secret sprawl in CI/CD and agent workflows?
- How can security teams reduce the risk from agent-driven package installs?
- How should security teams handle package installs that can trigger identity flows?
- What do security teams get wrong about Markdown files in developer workflows?
