A developer adds a skill to their agent. It is a folder with some instructions and a script, maybe a manifest file. The install takes about as long as adding a linter. Nothing in the interface asks for a security review, and nothing in most companies' change management process knows it happened.
That folder can read files. It can call APIs. It runs with whatever permissions the agent already holds, which is usually generous, because the agent was given wide access so it would stop asking for approval on every step.
In February 2026, Snyk published an audit of 3,984 agent skills pulled from ClawHub and skills.sh. Of those, 1,467 (36.82%) contained at least one security flaw. Another 534 were rated critical. Seventy-six carried confirmed malicious payloads: reverse shells, credential theft, data exfiltration. Eight of those were still downloadable when the report went out. Five of the seven most-downloaded skills in the corpus turned out to be malware.
That is a 37 percent failure rate across a corpus of skills that were installed on developer machines inside companies with security teams, endpoint agents, and a written policy about third-party software. Snyk's human reviewers confirmed the payloads by hand. Reverse shells do not need to be clever when the install button is one click away.
The real problem is a category error
Most organisations already know how to handle a risky dependency. There is a process: a package gets proposed, someone checks the licence, a scanner looks at the CVE list, the version gets pinned, and the whole thing shows up in a software bill of materials that an auditor can ask for.
None of that fires for an agent skill. It does not look like a dependency. It looks like a setting. It arrives through a marketplace button or a copy-paste from a blog post, it lives in a dot-folder, and it does not appear in package.json or composer.json or any lockfile anyone reviews. The teams that would never merge an unreviewed library into production will happily hand an agent twelve unreviewed tools, because tools feel like configuration.
They are not configuration. They are code that runs inside an autonomous loop with your credentials.
Timing does most of the damage. A compromised npm package waits for a human to trigger the vulnerable code path, and the human usually does that during business hours with a request in flight. A compromised skill inside an agent gets invoked by the agent itself, in a loop, at whatever hour the queue drains. The window between compromise and exploitation is however long it takes the model to decide the skill is relevant. Nobody is watching at that moment, because nobody watches a tool call.
The trust boundary has also collapsed. In a normal application, code and data occupy different places and get treated differently. Inside an agent's context window, a retrieved document, a tool's output, and a system instruction all arrive as text in the same buffer. An attacker does not need to trick a person into running something. They need the agent to read something, then call a tool.
Then there is visibility. Nothing watches a skill execute. There is no strace output a normal ops team reads, no obviously named process in the container list. The action happens, the agent reports success, and the log line says a tool was called.
Four ways agent components fail
Deliberate malice makes the headlines. It is not the only failure mode, and on a long enough timeline it may not even be the most common one in your own estate.
Typosquatting and tampered updates
Someone publishes a package with a name one character off a popular one, or buys a legitimate skill after it has built a download base and pushes an update that adds a payload. The ClawHavoc campaign in early 2026 poisoned 1,184 skills on ClawHub and pushed the AMOS credential stealer onto developer machines. Users had installed those skills weeks earlier, when they were clean.
Vulnerable components that passed no review
These are duller and just as damaging. A skill that shells out to a helper binary without quoting its arguments, a plugin that logs its full request body at debug level, a framework component with a known deserialisation bug. Each would surface in a code review or a component scan. None of them surface when the component was installed with a click.
Secrets shipped inside the package
This is the easiest failure to find and the easiest to ignore. Snyk's corpus had hardcoded API keys in 10.9% of ClawHub skills. Someone pasted a token into a config file to make the example work and never took it out. The skill is then a credential leak sitting in a public registry, indexed and searchable.
Runtime fetches that change after review
Roughly 2.9% of the audited skills pulled instructions or code from a URL at runtime. The copy a reviewer inspects is clean, because the malicious logic lives on attacker-controlled infrastructure and can be swapped in later. The published artifact never changes. Its behaviour does.
Why January 2026 matters
In January 2026, a crafted skill package achieved remote code execution inside an agent's skill runtime. It received CVE-2026-25253, the first CVE identifier assigned specifically to an agentic AI system rather than to an application or a library.
The identifier is the interesting part. It means the disclosure machinery that handles library bugs now covers agent runtimes, which means skill runtimes get held to the same standard as any other environment where untrusted code executes. Before that CVE, an agent runtime was a novel thing with unclear obligations. After it, the question "did you patch it" has a normal answer.
OWASP published a dedicated Agentic Skills Top 10 in April 2026, and the Agentic AI Top 10 already names supply chain compromise and unexpected code execution as separate risk categories. Neither list is abstract. They map onto concrete controls a team can implement this quarter.
Start with the inventory question
Every hardening programme here begins with a question most organisations cannot answer: what can this agent actually do, and to which systems.
Answering it means listing every skill, plugin, MCP server, tool definition and framework component each production agent can reach, plus where each came from and what credentials it runs under. This is a software bill of materials for agent components. The format matters less than the existence of the list, because the list is what turns an incident into a bounded problem instead of a hunt.
Generate the list from the runtime, not from a wiki. Config directories, container mounts, and the agent's own tool registry are the sources of truth; Confluence is not. And include the transitive layer. An MCP server that wraps three internal APIs means the agent can reach three internal APIs, and the person who installed the server was thinking about one.
Then scope what a compromise would reach
With the inventory in hand, the useful exercise is to assume each component is hostile and ask what it gets.
An agent that can read the whole filesystem and reach the open internet is a data exfiltration path waiting for a reason. An agent that holds a long-lived database credential is a persistence mechanism. The controls that help are unglamorous and mostly about narrowing the box:
- Mount the working directory read-only wherever the task allows it.
- Block outbound traffic by default and allowlist the specific hosts the agent legitimately needs. Exfiltration requires an egress path, and most agent workloads touch three or four domains.
- Give each agent its own identity with short-lived tokens instead of sharing a service account, so a leaked credential has a blast radius measured in minutes.
- Require human confirmation for anything destructive or externally visible: deploys, deletions, outbound email, payment actions.
- Run agent workloads in a sandbox with no default network access, so generated or injected code has nowhere to go.
None of that is exotic. It is the same discipline applied to a service account in 2015, which is roughly the maturity level most agent deployments are operating at.
Assume detection will be late
Prevention fails sometimes, so the logging has to answer a specific question after the fact: which agent called which tool, with what arguments, on whose behalf, and what came back.
Tool-call level audit logs are the minimum. Prompt-level logs are not enough, because the prompt can be benign while the tool call is the attack. Store the arguments and the response metadata, ship them somewhere the agent cannot write to, and keep them long enough to cover your detection lag.
For scanning, Snyk's mcp-scan and the agent-scan CLI shipped around RSAC 2026 and cover MCP servers and skills across a set of risk categories including hardcoded secrets, remote instruction fetching, and malicious download behaviour. Reported recall on confirmed malicious skills was 90 to 100 percent with no false positives on a top-100 legitimate corpus. Treat that as a useful first filter and not as a substitute for reading the skill. A scanner that catches known patterns will miss a targeted package written for your stack.
A sequence that fits in a quarter
Week one: produce the inventory from runtime config across every agent in production, and get a name attached to each component. Most teams find something in this step they did not know was installed.
Week two: for each component, record the source, the version, whether it auto-updates, and the credentials it can reach. Disable auto-update on anything touching production. An update channel is a remote code execution path with a friendly interface.
Week three: narrow the sandbox. Read-only mounts, egress allowlist, per-agent identity, human approval on destructive actions. Do the egress allowlist first if you can only do one, since it converts most exfiltration attempts into connection errors you can alert on.
Week four: turn on tool-call auditing and point it at something with retention and an alert rule. Pick one detection to build first, such as an agent process making an outbound connection to a domain that is not on the allowlist, and get it working end to end before adding more.
After that, the control becomes a gate rather than a project. Nothing new goes into a production agent without an entry in the inventory, a pinned version, and a review. Re-test when components change, which in practice means quarterly for most teams and immediately after any new skill or MCP server lands.
What this means for smaller teams
A twenty-person company running three agents does not need a platform. It needs a spreadsheet, an egress allowlist, and a rule that nobody installs an agent skill without telling someone. The failure mode is rarely a sophisticated attacker defeating layered defences. It is one unreviewed install on a laptop that happens to hold production credentials, discovered six weeks later when someone finally reads the egress logs.
The uncomfortable part is that the same property that makes agents useful is what makes them hard to govern. They are useful because they can act. Acting requires permissions, and permissions are what an attacker inherits the moment a component turns hostile.
That trade is worth making, but it has to be made on purpose. The component layer needs the same treatment as code, because the agent cannot tell the difference between a skill and a setting. Neither can the attacker.
Tech Hub Services builds and hardens production software, including AI agent deployments, for teams that need the security work done rather than described. If you have agents running against internal systems and no inventory of what they can reach, start with a scoping conversation.
