For decades, software supply chain security operated on a legible threat model. A dependency was malicious or it was not. A package was typosquatted or it was genuine. Reviewers and scanners looked for a specific bad line of code, sitting in a specific file, somewhere in the chain.
That assumption no longer holds when the reviewer is an autonomous coding agent, because the exploit no longer needs to live in any single file a human or a scanner would check.
Mozilla's 0DIN research team recently demonstrated the mechanism. An agentic coding tool clones what looks like an ordinary repository, complete with unremarkable setup instructions such as pip3 install -r requirements.txt followed by python3 -m axiom init. A deliberately planted Python package refuses to run until initialized, and it fails with a normal-looking error. That error is the payload. It prompts the agent's routine error-recovery behavior to auto-run the suggested follow-up command, which executes a shell script. The script reads a value from a DNS TXT record and runs it as a command.
No malicious code sits anywhere in the repository, and no single step trips review, because the reverse shell sits three layers of indirection away from anything the agent actually evaluated: a trusted-looking error message, a fetching script, and a DNS record no one is inspecting. The result is an interactive shell running with the developer's own privileges, with access to environment variables, API keys, and local configuration. This is not a poisoned package. It is a poisoned sequence, and the sequence is the part nobody was checking.
Every step in that chain is individually reasonable. Installing a stated dependency is reasonable. Retrying after an error is reasonable. Following a project's own documented setup flow is reasonable. The danger is not in any one decision. It is in the composition of decisions, none of which an agent, or a rushed engineer, has any particular reason to distrust.
Consider five engineers, each pointing an agent at the same "starter" repository, shared through a job posting, a tutorial link, or a direct message. None of them reads the raw text of the setup script line by line. All five execute it with full developer privilege. 0DIN's own writeup flags exactly this distribution model: threat actors do not need to compromise a popular package. They only need a plausible reason for a developer to run an agent against a repository once.
Locally valid engineering behavior scales into a systemic exposure the moment it is repeated across a team.
The same blind spot shows up one layer up the stack, in the marketplaces that distribute agent plugins rather than the agents themselves. A security researcher recently scanned Anthropic's official claude-plugins-community marketplace listing for entries pointing at GitHub owner and repository paths whose accounts had since been renamed or deleted. Finding one such dangling namespace, the researcher claimed it, recreated a plugin repository seeded with a clone of the legitimate project, and showed that the installer's "Open Homepage" action sent a user straight to the attacker-controlled repository with no warning at all.
The mitigating control here is real and worth naming directly. Marketplace entries pin each plugin source to an immutable commit hash, so a recreated repository cannot reproduce that hash, and the integrity check on the actual code-install path fails as designed. But the researcher also flagged a second-order risk: the automated process that keeps those commit-hash pins current runs through bot-driven pull requests, and that process could plausibly ingest a hash from a malicious commit if it is not validated carefully. The convenience link that a setup-mode user is most likely to click sits entirely outside the hash guarantee in the first place.
Anthropic classified the report as out of scope, treating dependency hijacking as excluded and the residual risk as social engineering. That classification may be correct on the narrow technical merits. It is worth CTOs treating with some skepticism regardless, since the exploited surface is still a click inside an engineer's ordinary daily workflow.
Commit-hash pinning is a genuinely effective control, and it worked here. The problem is not that the control failed. The problem is that the surrounding conventions, homepage links, error-recovery behavior, dependency install scripts, sit outside the boundary any single vendor's threat model currently covers.
Sandboxing every agent session is not free. Organizations running agentic coding tools at scale need to weigh the friction of containerized, network-restricted setup environments against delivery speed, and that tradeoff will look different for a five-person team than for a five-hundred-person engineering organization.
Much of the detail here arrives through security newsletter aggregation rather than original vendor disclosure. Treat the specifics as directional rather than independently audited, and verify current mitigations directly with the tool vendor before writing them into a policy document.
One implication of this shift is that it changes not only how attacks work, but also what security controls need to validate.
Traditional software supply chain controls validate objects: packages, files, dependencies, domains, or individual commands. Agentic development introduces a different problem. None of the individual decisions may be malicious on their own, yet together they can create a harmful execution flow.
As coding agents become more autonomous, security controls will increasingly need to evaluate the sequence of actions rather than isolated technical artifacts. That means considering execution context, permissions, timing, approvals, network activity, and how individually legitimate actions combine into a potentially malicious outcome. The question is no longer simply "Is this package safe?" but "Is this execution path one we intended to allow?"
This also has implications for the trust model itself. Rather than assuming repositories, plugins, packages, or domains are trustworthy until proven otherwise, organizations should explicitly define trusted sources and approved execution paths. Anything outside those boundaries should require additional validation, human approval, or sandboxed execution.
The emerging plugin ecosystem illustrates this well. Installing a plugin remains a developer decision: selecting the source, granting permissions, and accepting the associated risk. As these ecosystems continue to expand, engineering leaders should ask a simple question before adopting any new component: do we explicitly trust this source, or are we simply trusting the convenience of the installation flow?
The industry built its supply chain defenses to catch a bad line of code sitting in a specific place. Agentic coding tools introduced a different failure mode, one where every individual step is legitimate and the danger exists only in how the steps compose. Governing that composition, rather than scanning for malicious code that was never there, is now the job.
Guardrails of this kind are not a configuration setting an engineering team turns on once. They require sandboxed execution environments, explicit network egress policy, provenance checks on every plugin and dependency source, and a review process that treats an agent's full execution chain, not just its final command, as the unit of approval. Forte Group works with engineering leaders to design and operationalize exactly that kind of governance around agentic development, from sandboxing and dependency provenance to the audit and approval workflows that keep autonomous coding agents inside a defined trust boundary. Organizations do not need to slow down agentic adoption in order to secure it. They need the guardrails built into the workflow from the start.
Let's talk about where you are today and where you want to go - our experts are ready to help you move forward.
