Agent Security

A team that spent months getting its harness right — reads auto-approved, writes gated, force-pushes default-denied, a per-session network allowlist enforced beneath all of it — runs its first serious security review against the whole AI-assisted pipeline rather than against any single session. The review does not find a hole in the permission tiers or a gap in the sandbox boundary; those held. What it finds instead is a dependency nobody remembers approving, hallucinated by an agent months earlier, installed without a second thought because the name looked exactly like the real thing, and quietly registered on the public package index by someone who had never touched the codebase and never needed to.

None of the defenses this Library has already covered were built to catch that. Permission tiers govern what an agent is allowed to do inside a session; sandboxing and egress control bound what it can reach if that check is wrong. Both assume the threat arrives as an action the agent takes on a developer’s behalf, inside a session someone is watching. A squatted package arrives as a name the agent typed with complete confidence, gets installed by a command that looks like every other install in the log, and does its damage on the next import — long after the session that introduced it has ended. This volume’s previous chapter tracked who or what wrote a given line; this one asks what that line, once trusted and merged, could be made to do. Agent security is the set of threats that don’t fit neatly inside the harness, because they exploit the agent’s outputs, its access, or its confidence, rather than a gap in what it was permitted to do.

Four threats, not one

Security commentary on AI coding tools tends to collapse into a single worry — “AI is a security risk” — which is true and useless in roughly equal measure, because the things that phrase usually gestures at require almost entirely different defenses. Prompt injection, this Library’s Volume IV covered in detail across its chapters on permission architecture and sandboxing: hostile instructions hidden in a file, a page, or a tool’s own output, redirecting an agent toward actions nobody asked for. OWASP’s Gen AI Security Project ranks it the top risk for LLM applications for a reason — it is the mechanism by which an agent behaving exactly as designed produces a harmful outcome, because the design never distinguished between an instruction from a person and text the agent merely read. This chapter treats injection as established background, not new territory, and turns to three things that sit alongside it and get far less airtime: data exfiltration, supply-chain compromise through hallucinated dependencies, and what actually stops either one when the permission and sandbox layers are, for whatever reason, not enough.

Data exfiltration: when access becomes the exploit

Exfiltration does not require an agent to be compromised in any dramatic sense. It requires only that an agent has broad access and a reason — injected, mistaken, or simply overbroad by design — to send something it can read to somewhere it should not go. OWASP’s excessive-agency entry names the mechanism precisely: a system built with more functionality, more permission, or more autonomy than its actual task requires is a system where a single manipulated instruction can turn ordinary access into theft. The entry’s own illustrative case is almost dull in its plausibility — an email-summarization agent gains the ability to send mail, a poisoned message talks it into forwarding the inbox to an outside address, and nothing about the agent’s own reasoning looked unusual at any step.

Coding agents make this concrete rather than hypothetical. In early 2026, Check Point Research disclosed a chain of flaws in Claude Code’s project-level configuration — hooks that could run shell commands before a repository’s trust dialog was confirmed, an MCP-server setting that could bypass that same dialog, and an environment variable that could redirect the tool’s own API traffic through an attacker-controlled endpoint, at which point Claude Code sent its authorization header — the developer’s live Anthropic API key — in plaintext to whoever controlled it. None of it required a person to approve anything; cloning a booby-trapped repository and opening it was enough to start the chain. Anthropic fixed all three paths before publication, and the episode is worth citing precisely because it sits one layer below the permission prompts this Library’s Volume IV described — in the configuration files an agent reads before a session’s first approval ever fires.

The aggregate data points the same direction. GitGuardian’s 2025 secrets-sprawl analysis of public GitHub found AI-service credentials growing 81% year over year, and — the more pointed finding — commits co-authored by Claude Code leaking secrets at roughly double the baseline rate across the same public dataset. Neither number proves the tool is unsafe; both are consistent with a simpler mechanism — AI-assisted development moves at a pace that outruns the manual credential hygiene teams built for a slower cadence, and speed without a matching governance step is exactly where a secret ends up in a diff nobody scanned. The defense for this threat was already built in Volume IV’s sandboxing chapter: a deny-by-default network egress allowlist stops a credential from leaving even when a session has read it, regardless of whether the read was injected, mistaken, or entirely legitimate. This chapter is naming the case egress control exists to catch.

Supply chain: the package that was never real

The third threat is stranger, because the vulnerability is not a flaw in the agent’s access — it is a flaw in the agent’s memory, and it was documented before most teams had reason to look for it. Large language models generating installable code hallucinate package names at a measurable, repeatable rate: a comprehensive study across sixteen commercial and open-source models, evaluated over 576,000 generated code samples in Python and JavaScript, found that 19.7% of recommended packages did not exist, at rates from 5.2% on commercial models to 21.7% on open-source ones — and, the detail that turns a quality problem into a security one, the same hallucinated name reappeared across repeated prompts often enough to be practically predictable rather than random noise. The paper won a best-paper award at USENIX Security 2025 and catalogued 205,474 unique hallucinated package names across its sample.

Predictable hallucination is an open door, and the industry now has a name for walking through it: slopsquatting, coined by the Python Software Foundation’s Seth Larson and popularized shortly after — a deliberate echo of typosquatting, except the attacker does not need to guess a plausible misspelling of a real package. The agent already told them, in advance, exactly which nonexistent name developers were likely to try installing. The pattern is not theoretical: security researcher Bar Lanyado registered an empty package under a name — huggingface-cli — that models kept hallucinating in place of the real installation command, and it collected more than 30,000 downloads in three months, in part because a major AI lab had copied the AI-suggested command straight into a public repository’s own README. A registered slopsquat does not need to be sophisticated malware to be a foothold; it only needs to run once, at install time, inside whatever the developer’s environment can already reach.

An attacker squatting a hallucinated package is not guessing. The agent already told them exactly which name to register.

The rate is not standing still, though not entirely in the reassuring direction either. An independent re-evaluation across 2026’s frontier model cohort found overall hallucination rates compressed into a much narrower 4.6%–6.1% band — real progress, roughly an order of magnitude tighter than 2024’s spread between commercial and open-source models. The same study still found 127 package names hallucinated by every model it tested, of which 53 remained unregistered and available to claim at the time of writing. Fewer hallucinations is not the same as zero attack surface, and the names that survive model improvement are, almost by construction, the most plausible-sounding ones — exactly what an attacker would want to register. It is also worth being precise about what OWASP’s own supply-chain category currently covers: its 2025 entry documents compromised dependencies and tampered models in the conventional sense, but does not yet name hallucination-driven squatting as its own line item. The authoritative documentation of this specific pattern currently lives in academic and vendor security research, not in the standards body’s own list — itself a useful data point about how new the pattern is.

Four threats, four defenses

Blast radius is the answer to all four

The throughline is not a coincidence, and Volume IV named it before this chapter needed it: blast radius, treated as a design budget rather than an inherited default, is the structural answer to every threat here, including the two new to this chapter. An injected instruction cannot exfiltrate a credential the session’s environment was never handed in the first place. A hallucinated package cannot reach a network it has no egress path to, and it cannot do lasting damage inside a sandbox scoped to a disposable working directory. None of that requires predicting the specific attack — a squatted package registered next month, an injection technique nobody has published yet — because none of it depends on recognizing the attack by name. It depends only on the question Volume IV already asked: given everything this session can reach, how bad could the worst case actually be, independent of what caused it.

What is genuinely new to this chapter, rather than inherited from the harness layer, is a narrower kind of check: does this specific dependency exist, on this specific registry, with a provenance history that predates the session asking for it. That is not a permission decision or a sandbox boundary — it is a verification, cheap enough to run automatically before every install, which is this volume’s argument in miniature. A session that generates an install command has generated it in seconds; confirming the package is real, was not published last week, and was not published by a first-time author costs almost nothing to check, and catches exactly the failure mode the harness was never built to catch — because from the harness’s point of view, installing a named package is an entirely ordinary, fully permitted action. This volume’s next chapter, on trust calibration, is the general form of the same idea: deciding when an agent’s output is trustworthy enough to skip the check, and when it categorically is not.

What the security telemetry should show

Putting it into practice

1. Treat exfiltration as a distinct threat from injection, and defend it the same way regardless of cause: a deny-by-default egress allowlist, not a check for whether a given instruction looked hostile.
2. Verify that a package exists — and has more than a few days of registry history — before an agent-generated install command runs, especially in CI or any unattended session.
3. Do not wait for a standards body to formally catalog a pattern before defending against it; slopsquatting was documented and actively exploited before it had a name.
4. Audit configuration files, not just sessions — hooks, MCP server settings, and environment variables are read before a permission prompt ever fires, and a booby-trapped repository only has to be cloned to start the chain.
5. Size the blast radius, not the attack list. A session scoped to the smallest access it needs is defended against threats nobody has published yet.