The Orchestrator

The five controls assume the agent’s tooling is what it claims to be. The attackers of 2025 spent most of their effort on that assumption, and OWASP’s agentic list ranks the result fourth: the MCP servers, plugins, rules files, prompt templates, and registries an agent loads — often at runtime, often on the strength of a package name — are a supply chain, and it is attacked like one.

Start with the server. In September 2025 an npm package called postmark-mcp — by Koi Security’s account a copy of the transactional-email company’s official MCP server, published under the same name by someone else — shipped version 1.0.16 with one added line: a BCC that sent a copy of every email the agent sent to an address the publisher controlled. Fifteen prior versions had been clean. The package was downloaded on the order of 1,500 times a week, and the publisher removed it shortly after researchers made contact.¹² The number that matters is not the download count. It is what the server held. An MCP server runs with whatever the agent was given — here, the customer’s Postmark credentials and every message that passed through — and it appears in no asset inventory, because nobody thought of a connector as a vendor. Koi’s estimates of how many organizations were exposed are estimates and I do not repeat them; the mechanism is established, and the mechanism is sufficient.

Then the file. Chapter 6 called the project-instruction layer the least-governed part of the instruction tree, and Pillar’s rules-file work is the security bill for that. A rules file is text the model reads before every generation; if it came from a starter template, a forum, or a forked repository, its provenance is whatever the last committer’s was. Cursor’s position when Pillar disclosed was that the content of rules files is the user’s responsibility; GitHub took the same view and then, in May 2025, began warning when a file on github.com contains hidden Unicode text. Both responses are defensible and both leave the work with the orchestrator. SKILL.md files are the same artifact with more reach, because a skill loads across many runs and, as Chapter 6 put it, gets reused when the person who wrote it is not in the room.

Then the dependency that was never about agents at all. The Nx packages published to npm on August 26, 2025 carried a postinstall script that inventoried the developer’s machine for secrets — SSH keys, .env files, npm and GitHub tokens, cryptocurrency wallets — and pushed the results to a new public repository in the victim’s own GitHub account. What makes it belong in this book is one block of that script. Before scanning on its own, it checked for three binaries: claude, gemini, and q. If it found one, it ran it with a prompt asking the agent to search the home directory for credential-shaped files and write their paths to /tmp/inventory.txt, and it passed the flag that turns off the permission prompt — --dangerously-skip-permissions, --yolo, --trust-all-tools, one per tool. Wiz observed that step succeed in hundreds of cases and noted that provider guardrails sometimes intervened; the malware had its own scanner too, so the sources do not establish how much worse the agents made it. They establish something narrower: the coding agent on a developer’s machine is now an asset attackers plan for, and the flag Chapter 5 described as a habit is, to malware, an API. The downstream damage was ordinary supply-chain damage at scale: Wiz counted more than a thousand valid GitHub tokens in the leaked data, and a second wave used them to turn more than 5,500 private repositories public.

The last artifact has no incident behind it that I can cite, and I want to name it before it acquires one. Every one of these systems accumulates memory — Chapter 6 covered what that layer is and why it needs provenance and an owner. The security addendum is that memory is a store of whatever the agent saw, and agents see secrets: a connection string in a .env file read to debug a test, a token pasted into a task, a customer record summarized on the way to a decision. OWASP’s guidance under its memory-poisoning entry includes scanning every memory write for sensitive content before commit and expiring what cannot be verified. I have not seen a public breach that ran through an agent’s memory store. I expect to.

The controls follow the artifacts.

• Pin MCP servers and review them like dependencies, because that is what they are. Version-pin or hash-pin every server, install only from a registry you have approved, and read the diff on update. OWASP is candid that pinning does not stop a payload that ships in the pinned version; what pinning buys is the chance to read it before it runs.
• Give each server its own credential and its own container. A postmark-mcp holding a send-only token and nothing else can still BCC an attacker; a server running in the agent’s process with the agent’s ambient credentials can do everything the agent can. The first failure is smaller than the second.
• Put rules files and skills under code review, with a machine check for what people cannot see. A pre-commit hook or CI step that rejects invisible Unicode in .cursor/rules, CLAUDE.md, AGENTS.md, and every SKILL.md is cheap and defeats Pillar’s technique outright. The review itself is the review any dependency gets: who wrote this, what changed, and why.
• Scope secrets to runs. The Nx script found what it found because developer machines hold long-lived credentials in files. An agent that receives a short-lived token at the start of a run, injected by the harness and expired at the end, leaves nothing in a .env file for the next malicious postinstall to read, and nothing durable to remember.
• Scan memory stores for secrets with the scanners the repository already gets, and treat a hit the way a hit in a commit is treated: rotate the credential first, then find out how it got there.

None of that is exotic. The dependency scanners were simply not pointed at these four kinds of file.