MCP skills are now a mature attack surface, not an edge case

At a glance

What this is: This analysis says MCP agent skills are a mature attack surface, with flawed and malicious skills already spreading through registries and inheriting broad agent permissions.

Why it matters: It matters because IAM, PAM, and AI governance teams now have to treat agent skills as governed dependencies, not harmless extensions, or risk credential exposure, persistence, and uncontrolled tool use.

By the numbers:

• Snyk’s ToxicSkills audit scanned 3,984 skills and found 1,467 containing at least one security flaw.
• The ClawHavoc campaign weaponized 900 of ClawHub’s 4,500 skills, roughly one in five, according to the article.
• Snyk’s research confirmed 76 malicious skills with active payloads, showing that registry abuse had already moved beyond theory.

👉 Read Obot’s analysis of MCP skill poisoning and ClawHavoc

Context

MCP security fails when organisations treat agent skills as documentation rather than executable trust boundaries. In practice, a skill can inherit the agent’s permissions, interact with cloud credentials, and persist through memory stores, which means the risk is not just malware but delegated authority abuse across AI workflows.

The primary governance gap is that registries, policy controls, and runtime monitoring have not kept pace with the speed of skill publication and reuse. For teams responsible for IAM, PAM, and NHI governance, this is the same control problem seen in other identity-heavy environments: uncontrolled privilege, weak provenance, and poor lifecycle oversight, but now expressed through autonomous tool use.

Key questions

Q: What breaks when third-party agent skills are not governed like privileged inputs?

A: When agent skills are treated as harmless content, organisations miss the fact that those instructions can steer tools, secrets, and execution paths. The result is hidden privilege expansion, unsafe automation, and poor traceability. A skill should be governed like any other high-risk input that can change system behaviour, because that is effectively what it is.

Q: Why do malicious skills create a bigger risk than ordinary code dependencies?

A: Malicious skills can influence what an agent does after load time, including tool selection, command execution, and data handling. Ordinary dependencies usually expose code paths, but skills can alter behaviour through instructions that look normal to a human reviewer. That makes them harder to spot and easier to operationalise at scale.

Q: How do security teams know whether a Skill is operating outside its intended boundary?

A: Look for unexpected tool calls, commands that were not part of the approved workflow, unusual access to secrets or files, and divergence between the user request and the agent’s executed steps. If the workflow can trigger actions the owner did not explicitly authorise, the Skill boundary is not well controlled.

Q: Who is accountable when a malicious skill persists after removal?

A: The accountable party is the team that owns the skill lifecycle and the agent runtime, because remediation must cover durable state as well as the removed artifact. If memory, policy stores, or approvals were not checked, the incident response was incomplete.

Technical breakdown

Why agent skills behave like privileged software dependencies

Agent skills are not passive content. They are executable extensions that can influence tool selection, command execution, memory stores, and outbound communication inside the agent runtime. Because the agent often runs with access to environment variables, file systems, and connected services, a malicious skill can inherit far more authority than a typical package in a traditional software supply chain. That makes the registry itself part of the trust boundary. In security terms, the issue is not only code execution but delegated decision-making under trusted context.

Practical implication: Treat every skill registry as a governed software supply chain and require provenance, review, and privilege scoping before installation.

How prompt injection and malware reinforce each other in MCP attacks

The strongest attacks combine two layers of abuse. Traditional malware patterns hide credential theft, archive downloads, or exfiltration commands, while prompt injection manipulates the agent into following those instructions as if they were legitimate task guidance. That combination defeats separate detection stacks because static scanners look for code patterns and AI safety filters look for harmful instructions, but neither reliably handles both at once. When the payload is embedded in documentation, templates, or examples, the malicious logic can survive ordinary content review and execute through normal agent behaviour.

Practical implication: Build controls that inspect both code and instruction content, then validate agent actions at runtime rather than trusting skill text alone.

Why memory poisoning changes incident response for autonomous tools

Memory poisoning turns a transient compromise into persistence. If a malicious skill rewrites an agent’s persistent instruction store, the harmful behaviour can survive after the skill is removed, because the agent now treats the injected directive as part of its normal state. That means deletion is not equivalent to remediation. The control failure is lifecycle blind spot: teams remove the visible artifact but do not inspect the durable state the artifact altered. In an agentic environment, memory is effectively a policy layer, and policy drift can outlast the original compromise.

Practical implication: Add memory integrity checks, behavioural drift detection, and post-removal verification to every agent incident response runbook.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent skill into a durable execution path for credential theft, persistence, and downstream system abuse.

1. Entry occurs when attackers publish poisoned agent skills into public registries and manipulate selection through natural-language metadata and deceptive descriptions.
2. Escalation happens when the chosen skill runs inside the agent’s trusted context, inheriting file access, cloud credentials, and outbound channels, then uses prompt injection or memory rewriting to persist control.
3. Impact is credential exfiltration, behavioural persistence, and cross-system abuse that can survive skill removal and compromise wider enterprise workflows.

NHI Mgmt Group analysis

Registry governance is now an identity control, not a developer convenience. The article shows that agent skills inherit the permissions of the host agent, which makes publication, approval, and revocation part of access governance. That is the same lifecycle problem IAM teams already manage for service accounts and tokens, except the unit of control is now a skill package rather than a static account. Practitioners should treat skill registries as governed identity infrastructure.

Prompt injection plus privileged execution creates a new control gap: delegated reasoning abuse. The important insight is not simply that malicious skills exist, but that they can influence what the agent decides to do after the skill is selected. That collapses the boundary between content review and authorization review, which is why conventional malware scanning alone is insufficient. The practitioner conclusion is to validate both the artifact and the action it triggers.

Memory poisoning is the named failure mode this incident pattern exposes. Persistent agent memory becomes a hidden persistence layer when malicious instructions survive the skill’s removal. This is where agentic AI intersects with NHI governance: the system’s durable state must be revocable, reviewable, and attributable in the same way that privileged credentials must be. Teams should therefore inspect post-incident state, not just the initial malicious object.

Least privilege at the skill level should become a baseline design requirement. Skills that inherit full agent permissions are over-privileged by default, which makes every selection event a potential blast-radius expansion. The governance answer is not more trust in the registry but explicit permission declaration, validation, and periodic re-certification. Practitioners should align this with OWASP NHI Top 10 and agentic application guidance.

OWASP’s formalisation of agentic skills risk confirms the category has moved from experimentation to control framework territory. Once a risk class gets its own taxonomy, organisations can no longer treat it as an isolated vendor problem. It now belongs in enterprise risk registers, access reviews, and AI governance committees. The practical conclusion is to map skills to existing assurance workflows before scale makes the gap harder to close.

What this signals

Agent skill governance is likely to converge with IAM and PAM operating models, because the practical problem is no longer just code safety but authority management across dynamic tool use. Organisations that already manage service accounts, secrets, and privileged workflows have the right instincts, but they will need to extend review, revocation, and auditability into AI runtimes and registries.

Delegated reasoning abuse: this is the control gap that will define the next phase of agentic AI security. When a skill can influence what an agent decides to do after selection, the issue becomes much closer to authorisation than to traditional malware analysis. Teams should expect policy enforcement, provenance tracking, and runtime monitoring to become mandatory design inputs rather than optional overlays.

For practitioners

• Classify every agent skill as a governed dependency Require ownership, provenance, and approval for each skill before it reaches production agents. The control should cover who published it, what it can access, and when it must be revoked or re-certified.
• Validate instruction content and executable content separately Run scanning for malware patterns, prompt-injection cues, and disguised examples in documentation, templates, and manifests. Static code review alone will miss the hybrid payloads described in the article.
• Scope agent permissions to the minimum skill use case Remove inherited broad access to file systems, cloud credentials, and outbound channels where the task does not require them. Use explicit permission manifests and reject any skill that asks for more than it needs.
• Check persistent memory after any malicious skill removal Verify whether the agent rewrote durable state such as memory files, policy caches, or instruction stores. Deleting the skill is incomplete if the agent still carries attacker-provided directives.
• Add registry provenance to access governance reviews Bring skill registries into the same review cycle as privileged identities, service accounts, and secrets. If you cannot trace the skill lifecycle end to end, you do not have defensible governance.

Key takeaways

• Agent skills have crossed from experimental helpers into a mature attack surface that can inherit broad runtime authority.
• The evidence shows hybrid payloads, registry poisoning, and persistence through agent memory, which means cleanup must include durable state, not just the malicious skill.
• Security teams should govern skills like privileged dependencies, with provenance, least privilege, and runtime verification built into the control model.

Key terms

• Agent Skill: A reusable package of task-specific knowledge and procedures that an autonomous agent can load when needed. In practice, it separates general awareness from operational detail, which makes enterprise context easier to govern than a single oversized prompt.
• Memory Poisoning (ASI06): An attack where malicious content is injected into an AI agent's memory or context, causing it to alter its behaviour in subsequent tasks — potentially exfiltrating secrets, escalating privileges, or acting against its intended purpose.
• Delegated Reasoning Abuse: Delegated reasoning abuse occurs when an attacker manipulates an AI agent’s decision process through prompts, metadata, or documentation so the agent performs actions it would otherwise reject. It is a governance problem as much as a technical one because the abuse targets the trust placed in the agent’s judgment.
• Registry Governance: Registry governance is the set of controls used to manage who can publish, approve, revoke, and audit skills in an agent ecosystem. It matters because the registry is part of the trust boundary, and weak provenance or review makes malicious supply chain activity far easier to scale.

What's in the full article

Obot's full analysis covers the operational detail this post intentionally leaves for the source:

• Registry-level remediation guidance for poisoned skills, including how to verify provenance and revoke unsafe publications
• Detailed breakdowns of the ClawHavoc attack chain, including memory poisoning and credential exfiltration mechanics
• The specific control patterns used to detect prompt injection embedded in skill documentation and templates
• Operational guidance for centralising agent skill approval, audit, and lifecycle management

👉 The full Obot article covers the skill attack chain, persistence mechanisms, and control patterns in more depth.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and secrets management. It gives practitioners a practical baseline for controlling delegated access across modern identity programmes.