Poisoned Skills are AI skills or extensions that appear useful but contain hidden malicious instructions or unsafe actions. They exploit trust in the skill package, prompt text, or tool configuration to trigger data theft, unauthorised access, or code execution when the skill runs.
What poisoned skills are and why they matter
Poisoned skills are a supply chain style risk in agentic systems, where the package itself is the attack surface. The danger is that the skill can look legitimate while quietly embedding instructions that alter behaviour, exfiltrate data, or trigger unsafe tool use once it is loaded.
This makes trust decisions at install time and at runtime equally important. A skill can be small, reusable, and apparently narrow, yet still act as a delivery mechanism for hidden prompts, scripts, or configuration changes that the host agent executes with delegated authority.
How poisoned skills work
The common pattern is deception through packaging. The skill advertises a helpful capability, but its text, metadata, scripts, or tool declarations contain instructions that are not obvious to the person approving it. When the agent interprets those instructions, the malicious behaviour becomes part of the intended workflow.
Poisoning can happen through direct prompt text, frontmatter or manifest fields, helper scripts, or external references that the agent trusts as part of the skill bundle. The exact delivery mechanism varies, but the security issue is the same: the skill inherits execution credibility from the platform and from the user’s willingness to install it.
Because skills are designed to be modular and composable, they can be reused across tasks and environments. That convenience creates a broader blast radius than a one-off prompt attack, especially when the skill can reach files, internal tools, connected services, or cached context.
Security implications of poisoned skills
Poisoned skills can lead to data theft, unauthorised access, or code execution because the agent treats the skill as a trusted capability rather than an untrusted artifact. The risk increases when the skill can call tools, read sensitive context, or chain actions across multiple systems.
The issue is not just malicious intent in the skill itself, but the trust boundary it crosses. Once a skill is accepted into the workflow, the host may inherit the skill’s assumptions about what data to read, what commands to run, and what external services to contact.
For readers comparing this to broader agent security, the same failure mode appears in OWASP Agentic Skills Top 10 (AST10), which treats skill-layer trust, permission inheritance, and malicious skill content as first-class risks.
Why poisoned skills are difficult to spot
Poisoned skills often survive review because they blend useful functionality with hidden behaviour. Reviewers may focus on the apparent purpose of the skill and miss the small but consequential details in prompt text, helper code, dependency references, or tool permissions.
They are especially difficult to spot when the skill looks routine, when multiple people reuse the same skill without deep inspection, or when the platform encourages rapid adoption from a registry or marketplace. The result is a trust problem disguised as productivity tooling.
That is why skill vetting, scope review, and controlled execution matter. The most useful guidance for this term is to examine the skill as an executable trust object, not as passive documentation, and to compare its declared purpose with its actual instructions and side effects.
Risk and Threat Considerations
Poisoned skills create a hidden trust-chain risk because the malicious content is delivered inside something the platform and user are expected to rely on. The attacker’s objective is usually to turn legitimate skill execution into a channel for theft, privilege abuse, or unsafe action.
Failure mechanism: The skill is accepted because it appears useful, then its embedded instructions or scripts influence the agent to disclose data, invoke tools, or execute commands that were never intended by the reviewer.
Impact: A compromised skill can expose secrets, internal content, customer data, or automation paths, and it can also become a persistence point if the same skill is reused across teams or environments.
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 Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Poisoned skills are malicious agentic supply-chain artifacts. |
| ASI02 — Tool Misuse | Poisoned skills can steer agents into unsafe tool actions. | |
| ASI03 — Identity & Privilege Abuse | Poisoned skills may exploit delegated access to steal data or act beyond intent. | |
| Recommendation — Inspect skill packages for hidden instructions and untrusted code before allowing execution. Constrain tool invocation paths so skills cannot trigger unapproved actions. Limit delegated privileges so a skill cannot exercise more authority than needed. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party skill packages can introduce malicious or compromised behavior. |
| Recommendation — Vet third-party skill sources and trust them only after review and provenance checks. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Skills should be inventoried so unreviewed packages are visible and removable. |
| Recommendation — Maintain an inventory of installed skills and remove unknown or unapproved ones. | ||
Practitioner Guidance
Why practitioners should care: Treat skill intake as a security decision, not just a content decision. A skill package may be small, but if it can shape prompts, tool calls, or execution settings, it can move from convenience to compromise very quickly.
Common misunderstanding: Many teams assume a skill is safe because it is documented well or because its visible instructions look harmless. The real test is whether the package contains hidden actions, unexpected tool reach, or any behaviour that changes how the agent handles sensitive material.
Practitioner takeaway: Review skills for declared purpose, hidden instructions, and execution scope together, and reject any package whose behaviour cannot be explained cleanly before installation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org