The tools you build software with are now the attack surface
An agent that reads your codebase, calls your APIs, and spins up your infrastructure is powerful precisely because it can act, not just answer. That same power is exactly what makes it a target unlike anything model-safety guardrails were built to stop.
Guardrails care about what a model says. This course cares about what the system built around that model can be tricked, tampered with, or poisoned into doing — the software supply chain and the runtime tool-integration surface underneath the agent, not the model's output policy. Nothing here overlaps with a jailbreak or a refusal bypass, because the vulnerability isn't in the model's behavior at all.
Three doors into that surface open in this lesson: a poisoned dependency that rode straight into production agent stacks, the specific shape of tooling this risk clusters around, and a crack in the very software that connects agents to the tools they use.
A backdoor that rode in on a package install
Agent frameworks and orchestration libraries are dependencies like any other — pulled in with one command, trusted by default, because a package manager doesn't ask you to review a diff before installing. In March 2026, a backdoored version of LiteLLM, a widely used library for routing calls across LLM providers, was published to PyPI and sat there accumulating installs before anyone caught it.
The scale is the part worth sitting with: nearly 47,000 downloads before it was removed. That's not a niche package nobody uses — that's a piece of plumbing quietly present in a meaningful slice of production agent stacks by the time it was pulled.
Unlike a vulnerability in your own code, you don't get to review this attack surface. It arrives already trusted, several layers removed from anything your own code review process ever looks at — and popularity alone doesn't explain why one narrow slice of the ecosystem ends up absorbing more of this risk than the rest.
The catch: Supply-chain risk doesn't respect your security maturity. LiteLLM was popular specifically because engineers trusted it, and that popularity is exactly what made a backdoored version's blast radius so large. Trust and exposure scale together here, not in opposite directions.
Why coding agents are the leading edge of this risk
OWASP's GenAI Security Project has been tracking agentic AI projects across the ecosystem, and of the 53 it currently tracks, 28 — 53 percent — are coding agents. That's not a rounding error. It's a majority, and it isn't evenly distributed by growth either.
The five fastest-growing tools it tracks — Claude Code, Gemini CLI, Codex, Cline, and Aider — are all in that same category. The tools engineers reach for every day to write and ship software are the dominant, fastest-growing part of the emerging attack surface, not a side branch of it.
The mechanism is straightforward once you name it: a coding agent isn't scoped to answer questions. Its entire value proposition is that it can read your repository, run your shell, install your dependencies, and push your changes — and every one of those capabilities is also a lever an attacker would want. A chat-only agent simply doesn't have most of them. The surface isn't only the agent itself, either — it's everything the agent was built to plug into.
The catch: The tools most useful for engineering are, for exactly the same reasons, the tools with the most to lose if compromised. Usefulness and attack surface grow from the same root here, not from separate ones.
The protocol that lets agents call tools has its own CVEs
Model Context Protocol, MCP, is the connective tissue that lets an agent discover and call tools without every integration being bespoke — and connective tissue sitting between an agent and everything it can touch is exactly where a vulnerability does the most damage.
mcp-remote, a widely used MCP client tool, carried a critical vulnerability — CVE-2025-6514, rated 9.6 out of 10 on the CVSS scale — with more than 437,000 downloads already exposed by the time it was disclosed.
A 9.6 puts a vulnerability in the same tier as flaws that grant remote code execution or full credential exposure. For a tool sitting at the boundary between an agent and its tools, that severity is close to worst case.
The catch: A bug like this gets patched once it's found — but it's a symptom of something the patch doesn't fix. MCP has a structural property, independent of any single implementation's bugs, that keeps this whole class of vulnerability recurring.
One layer of defense doesn't cover this ground
Three real incidents: a poisoned dependency, concentrated risk in the tools you use daily, and a critical vulnerability in the protocol's own client. None of them a failure of model alignment or a jailbroken prompt — they're failures in code, packaging, and protocol design.
That's the actual distinction from a guardrails course worth sitting with. No classifier, no RLHF pass, no red-teamed refusal behavior touches any of this, because the vulnerability isn't in what the model says — it's in the software wrapped around it.
mcp-remote's bug will get patched. But MCP has a design choice — dynamic tool registration — that creates risk that isn't a bug at all, just a consequence of how the protocol was built to be flexible. That's next.