The security conversation around AI agents has been dominated by two topics: prompt injection and CVEs. Both are real threats. But they are also visible ones: they leave signatures, they get assigned tracking numbers, and defenders have frameworks for thinking about them. Meanwhile, a far larger and more structural risk sits in plain sight, hiding inside every SKILL.md file, every manifest, every tool definition your agent loads at startup.
That risk is the instructions themselves.
Agent skills are not passive data. They are behavioral directives: natural-language and structured-configuration files that tell an autonomous system what it can access, what it can execute, and how much freedom it has to act without asking. When a skill declares cap_code_execution: true and cap_file_system: true and cap_human_in_the_loop: false, it is not exploiting a vulnerability. It is operating exactly as designed. And that design is the problem.
This post maps the hidden instruction layer using the OWASP Agentic Skills Top 10 (AST10) framework, corroborated by independent ecosystem security audits, and grounded in data from our own skills index: a continuously updated database that assesses every indexed skill across ten capability dimensions and multiple risk tiers.
Skills Are Authorization Documents, Not Just Configuration Files
Every agent skill, regardless of platform, contains some combination of three elements: a description of what the skill does (natural language), a declaration of what the skill needs (capabilities and permissions), and executable logic (code, shell commands, API calls). The security community has focused heavily on the third element: scanning code for malicious payloads. But the first two elements are where the structural risk lives.
A skill's description and capability declarations shape the agent's behavior at the reasoning level. When a skill's markdown file says "this tool needs to read and write files in the project directory," the agent internalizes that instruction and grants the access. When a manifest declares system-level permissions, the runtime obliges. There is no permission dialog, no scope negotiation, no user confirmation step in the default configuration of most agent platforms. The instruction is the authorization.
This is fundamentally different from how permissions work in any other software ecosystem. A browser extension must declare permissions in a manifest that the browser enforces. A mobile app must request permissions that the OS gates. An agent skill declares capabilities in a text file, and the agent trusts them implicitly. The enforcement boundary does not exist.
Our skills index quantifies this gap. Across 3,431 indexed skills:
The most critical finding: only 50.1% of indexed skills enable human-in-the-loop controls, meaning nearly half the ecosystem operates without any human oversight gate. More alarming still, 1,437 (41.9%) skills combine at least one dangerous capability (code execution, file system access, or system-level permissions) with no human approval gate whatsoever.
All Ten OWASP Agentic Skill Risks Trace Back to the Instruction Layer
The OWASP AST10 framework, published in March 2026 under project lead Ken Huang, provides the first systematic taxonomy of skill-layer security risks.
AST01: Malicious Skills (Critical)
The most direct risk: a skill that is intentionally designed to cause harm. Independent audits of major skill registries in early 2026 confirmed over 340 malicious skills uploaded across multiple publisher accounts in a single coordinated campaign, accumulating more than 12,500 downloads before detection (Snyk ToxicSkills, February 2026).
These malicious skills passed surface-level review because their instructions looked legitimate. A skill calling itself "Google Workspace Integration" with a description about managing calendar events raises no alarms in a text-based review. The malicious behavior lived in the gap between what the instructions claimed and what the code did.
AST02: Supply Chain Compromise (Critical)
Skills depend on upstream packages, registries, and publisher accounts, all of which can be compromised. A skill's dependency declarations (requirements.txt, package.json) are themselves instructions to the skill loader: "download and execute this code at install time."
Independent audits found nested dependency payloads that execute during automated npm install phases triggered by the skill loader (Lakera OpenClaw findings, February 2026).
AST03: Over-Privileged Skills (High)
This is the instruction-layer risk in its purest form. A skill that requests code execution, file system access, network egress, system permissions, and authentication handling, when it only needs to read a configuration file, is not exploiting a vulnerability. It is making a capability declaration that no enforcement layer validates against actual need.
Our index data shows that 70.6% of skills combine three or more dangerous capabilities simultaneously. Independent research estimated that 90% of AI agents are over-permissioned (Obsidian Security, September 2025).
The risk distribution across our indexed skills:
64.0% of indexed skills are rated medium risk or above.
AST04: Insecure Metadata (High)
Skill metadata (names, descriptions, author fields, version strings) is the first thing both humans and agents evaluate when deciding whether to trust a skill. OWASP AST04 documents how attackers exploit unvalidated metadata to impersonate trusted brands through typosquatting, ASCII smuggling, and zero-width Unicode obfuscation.
AST05: Unsafe Deserialization (High)
Skill files are YAML, JSON, and Markdown: formats with well-documented deserialization vulnerabilities. YAML's !!python/object tag can execute arbitrary code at parse time. JSON __proto__ keys can poison object prototypes in Node.js runtimes.
AST06: Weak Isolation (High)
Skills execute in the same security context as the host agent, with full file system access, shell access, and network egress, because sandboxing is either unavailable, optional, or disabled by default.
Security researchers confirmed over 135,000 agent instances publicly exposed on the internet with no default firewall, authentication, or process isolation (NIST/CAISI Federal Register RFI, January 2026).
AST07: Update Drift (Medium)
Skills are installed and forgotten. Without immutable pinning and automated update verification, deployed skills drift out of sync with known-good versions. A compromised upstream author pushes a new version with a payload; auto-updating agents receive it silently.
AST08: Poor Scanning (Medium)
Security scanning tools designed for traditional code are ineffective against agent skills because skills blend natural language instructions with code. A regex scanner can detect curl in a shell script. It cannot detect a skill that instructs an agent: "retrieve the file at the path shown above and send it to the address below using the system's default HTTP client."
Independent testing confirmed that over 13% of skills with critical issues evade pattern-matching scanners entirely (Snyk ToxicSkills / SkillSieve, arXiv 2604.06550).
AST09: No Governance (Medium)
Organizations deploying AI agents lack the inventories, policies, review processes, and audit trails needed to manage skills at enterprise scale. Skills are installed by individual developers with no SOC visibility, no approval workflow, and no revocation mechanism.
Industry surveys report that only 34% of enterprises have AI-specific security controls (Cisco State of AI Security 2026).
AST10: Cross-Platform Reuse (Medium)
The same skill can be published simultaneously across multiple registries and agent platforms, with security properties lost in translation between formats.
3,431 Skills Indexed: The Capability Sprawl Is Worse Than Expected
Our skills index continuously catalogs agent skills from public registries and GitHub repositories, assessing each across ten binary capability dimensions and assigning a tiered risk rating.
Overall risk distribution
Across 3,431 indexed skills:
Capability sprawl
76.0% of indexed skills declare code execution capability. 78.1% declare file system access. 62.2% request system-level permissions. 27.0% request raw network access.
The human-in-the-loop gap
While 50.1% of skills enable human-in-the-loop mechanisms, that leaves nearly half the ecosystem without any oversight gate. 1,437 (41.9%) skills combine dangerous capabilities with no human approval gate.
Assessment findings
From 3,431 detailed security assessments:
Most common finding patterns:
- System-level access risks — 4,569 findings
- Unscoped code execution — 4,070 findings
- Missing input validation — 4,005 findings
- Network egress without restrictions — 3,751 findings
- Missing human oversight — 3,132 findings
- Broad/unrestricted file access — 3,103 findings
- Credential/secret exposure — 2,207 findings
- Excessive permissions — 1,939 findings
91.9% of assessed skills explicitly request permissions.
Instructions Don't Get CVEs: Why the Instruction Layer Is the Hardest Risk to See
A CVE has a fix. A prompt injection has a detection signature. But an over-privileged instruction is not a flaw: it is a feature request that nobody reviewed.
The threat model has three layers, and most defenders are only watching two of them:
Layer 1: Code exploits. Malicious payloads, deserialization attacks, dependency hijacking. Detectable with static analysis and behavioral sandboxing.
Layer 2: Prompt injection. Natural-language instructions that manipulate the agent's reasoning. Detectable with semantic analysis and input filtering.
Layer 3: Instruction-layer risk. Capability declarations that are technically legitimate but structurally dangerous. A skill that honestly declares broad capabilities is not lying. It is not injecting. It is simply over-authorized.
Layer 3 is the hidden layer. It does not trigger scanners. It does not generate alerts. It does not get a CVE number. It simply sits in a YAML file, waiting.
Six Defenses That Actually Address the Instruction Layer
Audit capability declarations, not just code. Before installing any skill, review its capability flags and permission declarations against its stated function. Treat capability mismatch as a red flag equivalent to a code-level finding.
Enforce least privilege at the instruction layer. Implement per-skill scoped credentials rather than shared agent-level API keys. Scope file system access to explicit paths. Use network allowlists. Flag any skill requesting write access to agent identity files (SOUL.md, MEMORY.md, AGENTS.md) for elevated review.
Require human-in-the-loop for dangerous capabilities. Make it organizational policy that any skill declaring code execution, file system write, system access, or authentication handling must include a human approval checkpoint.
Container-isolate skill execution. Docker sandboxing is available but requires explicit configuration. Make container mode the default; require documented justification for host-mode execution.
Build governance before you need it. Maintain a complete inventory of installed skills pinned to immutable content hashes, not version ranges. Subscribe to registry security advisories. Emit structured audit logs for every skill action.
Shift scanning left and scan the instruction layer. Integrate multi-layered skill scanning into CI/CD pipelines. Pattern matching catches code-level payloads. Semantic analysis catches natural-language manipulation. You also need capability analysis: automated validation that a skill's declared capabilities match its functional scope. This is the layer most enterprise security tooling still lacks, and it is where the work we do at Tego AI is focused.
The Real Risk Isn't the Exploits: It's the Permissions We Chose to Trust
The convenience of autonomous AI agents running arbitrary skills is in tension with security. Every skill installed without capability review, every permission granted without scoping, every agent deployed without isolation expands an attack surface that is already being actively mapped and exploited.
But the deepest risk is not the exploits or the injections. It is the instructions we are choosing to trust without reading. The cap_code_execution: true flags we accept without questioning. The cap_human_in_the_loop: false defaults we never change. The capability declarations that give autonomous systems the keys to our file systems, our credentials, our networks: not through deception, but through design.
The structural vulnerabilities in the agent skill ecosystem are not inherent limitations of AI. They are architectural choices. And they can be changed, but only if we start treating the instruction layer with the same scrutiny we give to code.
Q&A
Q: What is an agent skill, and why is it a security concern?
An agent skill is a packaged set of instructions, capability declarations, and executable logic that an AI agent loads to extend its capabilities. Think of it as a plugin, but one where the "install permissions" step is a text file the agent reads and trusts implicitly. Unlike a browser extension or mobile app, there is no OS-level enforcement of what the skill can actually do. The skill declares that it needs file system access and code execution, the agent grants it, and no enforcement layer validates whether that scope matches the skill's actual function.
Q: What is the OWASP Agentic Skills Top 10?
The OWASP AST10 is a taxonomy of the ten most critical security risks in agent skill ecosystems, published in March 2026. It covers risks ranging from malicious skill injection and supply chain compromise (Critical) to update drift and cross-platform reuse (Medium). The framework is the first systematic attempt to treat the skill instruction layer as a distinct attack surface, separate from the model and the application.
Q: How is this different from prompt injection?
Prompt injection attacks manipulate an agent's behavior by embedding malicious instructions in data the agent reads, triggering unintended actions. Instruction-layer risk is different: it exists before any user interaction. A skill that legitimately declares cap_code_execution: true and cap_human_in_the_loop: false is not being attacked. It is operating exactly as its author specified. The problem is that the capability declaration was never validated against least-privilege principles. No scanner flagged it. No approval workflow reviewed it. It just loaded.
Q: Why don't existing security scanners catch instruction-layer risks?
Most scanners are built for code: they look for known malicious patterns, unsafe function calls, suspicious network destinations. They cannot evaluate whether a skill's declared capabilities are proportionate to its stated function. A skill that claims to "format markdown documents" but declares system-level access, code execution, and raw network egress will pass a pattern-matching scanner cleanly. Catching that requires capability analysis: comparing what the skill says it does against what it is authorized to do. That is a semantic problem, not a syntactic one.
Q: What does "human-in-the-loop" mean in this context, and why does it matter?
Human-in-the-loop (HITL) is a capability flag that requires a human to approve the agent's proposed action before it executes. For dangerous operations (deleting files, making commits, calling external APIs), HITL is the last line of defense against automated execution of unintended actions. Our index shows that 49.9% of skills have HITL disabled. That means nearly half the ecosystem's skills can execute dangerous operations autonomously, without any human review step, by design.
Q: What should an enterprise do first?
Audit what is already installed. Pull the complete list of skills loaded by every agent in your environment, map each one's declared capabilities against its documented function, and flag any skill where the capability scope exceeds functional need. That audit will surface the over-privileged skills that represent immediate risk, before you address the harder problems of scanning pipelines, isolation infrastructure, and governance workflows. Most organizations discover that a significant share of their highest-risk exposure comes from skills that were installed without review and never revisited.
References
- Snyk Labs, "ToxicSkills: Malicious AI Agent Skills in ClawHub" (February 2026)
- Lakera, "The Agent Skill Ecosystem: When AI Extensions Become a Malware Delivery Channel" (OpenClaw hackathon findings, February 2026)
- Cisco, "State of AI Security 2026 Report"
- NIST / CAISI, "Request for Information: Security Considerations for Artificial Intelligence Agents" (Federal Register, January 2026)