The review model breaks because the agent consumes skill instructions as operational input, not as explanatory text. That means a benign-looking skill can steer actions, tools, and data access once loaded. Security teams need to govern the raw skill artifact and its execution context, not just the model that reads it.
When Skill Content Becomes Execution Policy
AI agent skills are not passive documentation once the runtime loads them. They can change what the agent is allowed to do, which tools it can call, and what data it can reach. That is why review has to focus on the skill artifact itself, the trust boundary around it, and the permissions it brings with it.
A skill file that looks like guidance may still behave like a policy input. If teams review it only for wording quality or documentation hygiene, they miss the operational effect: the agent can execute the instructions as authority-bearing input. The right question is whether the skill can expand agency, not whether it reads well.
What Breaks in the Review Model
The main failure is misplaced trust in the wrong layer. Security reviewers often expect the model to interpret documentation safely, but an agent system may ingest the skill as live control material. Once that happens, a benign-looking instruction can redirect workflow, select tools, alter task scope, or expose data beyond what the reviewer assumed was possible.
That breaks separation between content review and runtime authorization. It also breaks the assumption that the model itself is the only thing needing control. In practice, the skill artifact, its loader, and the execution context become part of the effective policy surface.
For teams building agentic systems, the comparison is close to how a tool or permission file matters more than its prose suggests. A skill is only “documentation” if it has no execution effect. If the platform interprets it at runtime, it belongs in the same governance model as any other policy-bearing input, including task scope, tool allowlists, and delegated access.
How to Treat Skills as Runtime Controls
The practical fix is to review skills like active configuration, not narrative content. That means checking where the skill is sourced from, who can modify it, how it is versioned, whether it can inherit permissions, and what the agent can do after loading it. A safe-looking skill with broad tool reach can be more dangerous than an obviously sensitive prompt because it may be trusted by default.
Good governance also requires tracing the execution path. If the skill can invoke tools, touch external systems, or influence downstream actions, then the real control point is the policy decision around execution, not the text review alone. This is especially important where the skill can be updated independently of the model or reused across multiple agents.
Teams should also treat provenance as part of trust. If the artifact is unsigned, unversioned, or easy to swap, then the runtime has no stable basis for deciding whether the instruction source is legitimate. That makes the skill supply chain a security issue, not just a content-management problem.
Risk and Threat Considerations
When skills are treated as documentation, attackers can exploit the gap between how the file looks and how the runtime uses it. The result is policy smuggling: content that appears harmless to reviewers but still expands tool use, data access, or delegated action once loaded.
Failure mechanism: The system trusts the skill artifact as explanatory text, while the agent runtime interprets it as operational instruction. That lets malicious or altered skill content influence execution without passing the same scrutiny applied to code or policy.
Impact: The agent may take unauthorized actions, access more data than intended, or follow a manipulated workflow at scale. If the skill is shared across agents, the blast radius can extend beyond a single task or user session.
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 NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Skills can expand an agent's authority and tool reach at runtime. |
| ASI02 — Tool Misuse | Skills may steer tool selection and action execution in agent workflows. | |
| ASI04 — Agentic Supply Chain Vulnerabilities | Skill artifacts are supply-chain inputs that can be altered before runtime. | |
| Recommendation — Enforce explicit runtime authorization before a skill can change agent privileges or actions. Restrict tool invocation to approved actions and validate each skill-driven request. Protect skill provenance and integrity before any agent loads the artifact. | ||
| OWASP Agentic Skills Top 10 | Agentic Skills Top 10 | The question is specifically about the skill layer behaving as runtime policy. |
| Recommendation — Review agent skills as executable control inputs, not as passive documentation. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | Skills can change what the agent is permitted to do at execution time. |
| CM-5 — Access Restrictions for Change | Skill updates can introduce unauthorized runtime behaviour if unmanaged. | |
| SA-10 — Developer Configuration Management | Skills function like managed configuration that needs controlled versioning. | |
| Recommendation — Bind skill execution to enforced access decisions and deny undeclared actions. Limit who can modify skills and require approval for policy-bearing changes. Version and protect skill artifacts as controlled configuration items. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Runtime skill effects should be authorized per request, not trusted by default. |
| Recommendation — Apply continuous verification before each skill-driven action is allowed. | ||
| OWASP ASVS | V13 — Configuration | Skill content behaves like configuration when it changes runtime behaviour. |
| Recommendation — Treat skill files as controlled configuration with explicit security review. | ||
Practitioner Guidance
What to verify: Confirm whether the platform treats skills as declarative guidance, executable policy, or both. If the runtime can alter tool access or action scope from the skill, review it with the same rigor you would apply to authorization logic or privileged configuration.
Common mistake: Teams often audit the text for safety language and stop there. That misses the more important question: what changes in the agent’s behaviour after the skill is loaded, and who can change that behaviour later?
What good looks like: The skill artifact is source-controlled, versioned, signed or otherwise integrity-protected, and bound to explicit runtime limits. The agent cannot silently gain new authority just because the skill content changed.
Practitioner takeaway: If a skill can influence actions, tools, or data access, it is not documentation in the security sense, it is policy input and should be governed at runtime.
Related resources from NHI Mgmt Group
- What breaks when AI artefacts are treated like documentation instead of controls?
- What breaks when agent skills are reviewed like documentation instead of executable software?
- What are Agent Skills and how do they enhance AI performance?
- What breaks when AI agent context is treated like passive metadata?