On March 29, 2024, a Microsoft engineer named Andres Freund noticed SSH logins on a Debian system were taking 500 milliseconds longer than normal. That anomaly led him to CVE-2024-3094, a backdoor planted in the xz-utils compression library through a two-year social-engineering campaign against its human maintainer. The attack worked because it targeted a person: patience, trust-building, and community pressure. Autonomous coding agents remove that bottleneck. An agent doesn't get worn down over two years, but it also doesn't recognize when it's being worn down over two minutes. It reads a GitHub issue, a package README, or a tool's output and treats embedded instructions as trustworthy context. Standard AppSec practice — SAST, dependency scanning, code review checklists — was built for humans who write code deliberately and slowly. Agents that read, decide, and act inside the same context window need a threat model built around autonomy, not just vulnerability classes.
What makes an agent's attack surface different from a human developer's?
The difference is that an agent's attack surface includes everything it reads, not just everything it writes. A human developer might skim a suspicious comment and move on; an agent parses every byte of every file, issue, PR description, and tool response as potential instruction. Security researcher Simon Willison named this pattern the "lethal trifecta" in mid-2025: an agent becomes exploitable when it simultaneously has (1) access to private data, (2) exposure to untrusted content, and (3) a way to communicate externally. A code agent with repo access, the ability to read open issues, and the ability to open a pull request or hit a webhook satisfies all three by design. In March 2025, Pillar Security disclosed the "Rules File Backdoor" technique, showing that hidden Unicode characters and misleading context in configuration files used by GitHub Copilot and Cursor could silently redirect an agent into generating malicious code while appearing to produce clean output to the human reviewer. That's not a bug in the model. It's a gap in the threat model.
Why did Model Context Protocol servers become a new attack surface in 2025?
Because MCP gives agents a standardized way to call tools, and standardization means every server is now a shared trust boundary. Anthropic published MCP in November 2024 to let agents call external tools — databases, ticketing systems, browsers — through a common interface. By April 2025, Invariant Labs had documented "tool poisoning attacks," where a malicious or compromised MCP server embeds hidden instructions in its tool descriptions that the agent reads and obeys, even though a human operator never sees them in the UI. Researchers also demonstrated "rug pull" attacks, where an MCP server behaves safely during review and changes its tool definitions after installation. For a coding agent wired into ten or fifteen MCP servers — filesystem access, a Git host, a package registry, a cloud console — each server is effectively an unaudited dependency with the ability to steer the agent's behavior at runtime. Traditional software composition analysis catalogs what code you import. Nothing in that pipeline catalogs what an agent has been told to do by a tool it trusts while it's running.
Can an agent be manipulated into shipping a malicious dependency?
Yes, and 2025's npm worm campaigns show how fast that can spread once an agent or a compromised CI credential is in the loop. In September 2025, the "Shai-Hulud" worm compromised over 500 npm packages by using stolen maintainer tokens to publish malicious versions that harvested further credentials and self-propagated to any package the compromised maintainer could reach. Now put an autonomous agent in that pipeline: agents are routinely granted permission to run npm install, resolve dependency conflicts, and even auto-merge lockfile updates to keep builds green. An agent optimizing for "make the build pass" has no inherent reason to flag that a transitive dependency bumped three major versions overnight or that a maintainer account started publishing from a new region at 3 a.m. local time. Humans doing dependency review at least occasionally notice a suspicious diff; an agent evaluates success against the task it was given, which is usually "fix the failing test," not "notice the supply chain anomaly."
What happens when agents get their own CI/CD credentials?
They inherit the blast radius of whatever token they're handed, and most teams hand over more than they realize. A human developer's laptop compromise is bounded by what that person can reach. An agent's compromise is bounded by what its service account, API keys, and CI secrets can reach — and because agents are often given broad scopes to reduce friction ("just give it write access to the repo and the registry so it doesn't keep asking"), that blast radius tends to be larger, not smaller. Guidance on agentic workflows published through 2025 increasingly recommended short-lived, task-scoped tokens specifically because long-lived agent credentials had already shown up in incident postmortems as the pivot point attackers used to move from a single hijacked prompt to a full pipeline compromise. A coding agent that can read secrets from environment variables, install packages, and push to a registry is not a developer with a laptop. It's unattended infrastructure with write access, and it should be threat-modeled the way you'd model a CI runner, not a contractor's onboarding checklist.
Why can't existing AppSec tooling just be pointed at agent output?
Because most AppSec tooling assumes a human is the last decision-maker before code merges, and agentic workflows are increasingly designed to remove that checkpoint. SAST and DAST scanners were built to catch vulnerabilities in code a person wrote and intends to ship. They weren't built to catch a scenario where the code itself is fine, but the agent that wrote it was steered there by a poisoned prompt, a compromised MCP tool response, or a manipulated issue thread — and then auto-merged the change because CI passed. Surveys of software teams through 2025 consistently found autonomous, multi-step agents growing fastest in exactly the CI/CD and PR-review stages where a scanner's "all green" result now has to account for who, or what, approved the change. Scanning the diff isn't enough when the real question is whether the process that produced the diff can be trusted.
How Safeguard Helps
Safeguard treats autonomous coding agents as what they are: privileged, non-human actors in the software supply chain, not extensions of the developer who launched them. That means provenance and attestation on every artifact an agent touches, so a build produced by an agent session is traceable back to the exact prompt, tool calls, and dependency versions involved — not just the final diff. It means scoped, short-lived credentials for agent-driven CI/CD steps, enforced at the pipeline level rather than left to whichever token happened to be sitting in the environment. It means monitoring MCP and tool-call activity for the patterns behind tool poisoning and rug-pull attacks, rather than only scanning the code an agent eventually commits. And it means SBOM and dependency-integrity checks that run on every agent-initiated install or version bump, catching the kind of anomalous maintainer or registry behavior seen in the 2025 npm worm campaigns before an agent's "fix the build" task turns into a supply chain incident. Autonomous agents are already writing, testing, and merging production code. Safeguard's job is making sure the pipeline they operate in is held to the same trust standard as the humans it used to depend on entirely.