Tech Evolution #7 — a weekly series on where AI in technology actually is, where the data says it's going, and — clearly flagged — what might happen next. Last week, The Bottleneck Moved to the Spec covered the review-time inversion in AI-assisted development. This week: the security side of the same shift — what happens when the tools an agent calls become the attack surface.
Where we actually are
For two years, the security conversation around AI agents was mostly hypothetical: red-teamers showing that a poisoned webpage could trick a model into leaking data, in a lab, on a slide. That conversation ended sometime around March 2026. A backdoored update to LiteLLM — the model-gateway library sitting underneath CrewAI, DSPy, MLflow, and dozens of other agent frameworks — sat on PyPI for roughly three hours and picked up tens of thousands of downloads before anyone caught it (Help Net Security). Anyone who updated during that window pulled in a three-stage credential stealer along with their dependency bump: it swept SSH keys, cloud credentials and Kubernetes tokens, encrypted them out to a domain registered the day before, and left behind a systemd service that polled for further payloads (Snyk). The attacker didn't phish a developer or guess a password. The publishing token was lifted straight out of LiteLLM's own build runner by a poisoned release of Trivy — the security scanner running inside its CI pipeline. And one link in that chain was itself automated: researchers attribute the upstream compromise to a component called hackerbot-claw, which used an AI agent for attack targeting — documented as one of the first operational uses of an AI agent in a software supply-chain campaign (Aikido).
That incident is now one line item in a much longer ledger. OWASP's State of Agentic AI Security and Governance (v2.01) reads nothing like the 2025 edition, which mostly catalogued plausible threats. The 2026 edition catalogues CVEs. CVE-2025-6514 is a 9.6-severity remote code execution flaw in mcp-remote, the npm bridge that connects local LLM clients to remote Model Context Protocol servers — more than 437,000 downloads at the time of disclosure, and a hostile server could hand it a crafted authorization URL that landed as a shell command on the developer's own machine (JFrog). CVE-2026-22708 shows an attacker poisoning a Cursor agent's execution environment so that an allowlisted command like git branch delivers an arbitrary payload — the allowlist was the vulnerability, because it auto-approved exactly the command the attacker needed. CVE-2025-59532 did the same trick against OpenAI's Codex CLI, letting the agent's own output redefine the edge of its sandbox (Help Net Security).
The pattern underneath all of it has a name now: Simon Willison's "lethal trifecta" — an agent that has access to private data, is exposed to untrusted content, and can communicate externally is one crafted sentence away from becoming an exfiltration tool (simonwillison.net). This isn't a bug you patch. Large language models process the system prompt, the user's request, and any text pulled from a webpage, email, or tool response as one undifferentiated stream of tokens. There is no reliable boundary between "instruction" and "data" inside that stream, which is why a calendar invite or a tool description can carry the same authority as a command from the operator.
Model Context Protocol made this worse before anyone made it better, because MCP tool descriptions are themselves untrusted content that gets fed straight into that stream. Researchers demonstrated a poisoned WhatsApp MCP server whose tool description quietly instructed the connected model to exfiltrate a user's entire message history through what looked like a routine tool call — nothing about it showed up in the visible output (Cloud Security Alliance). A separate case, postmark-mcp, shipped fifteen clean releases to build trust before a sixteenth quietly added one line of exfiltration code — the software-supply-chain "rug pull," aimed at agent tooling instead of npm packages. OX Security's April 2026 disclosure put a number on the blast radius of one architectural default baked into official MCP SDKs: an estimated 200,000 vulnerable server instances across a dependency graph with more than 150 million downloads. Not a bug in one product — a default everyone inherited.
And the exposure isn't evenly spread. Of the 53 agentic projects OWASP's State of AI Surveyor tracks, 28 are coding agents, and the five fastest-growing tools — Claude Code, Gemini CLI, Codex, Cline, Aider — all sit in that bucket. The five repositories with the most security advisories are n8n (57), Claude Code (22), AutoGPT (15), Dify (13), and Roo-Code (11): every one a semi-autonomous framework or coding agent, several of them shipping releases daily or faster (Help Net Security). Coding agents are the epicenter of this risk category for the same reason they're the epicenter of enterprise AI adoption: they're the tools with the deepest, most valuable access — to source, to secrets, to CI/CD.
The trajectory
The industry's actual answer, so far, is a budget rather than a fix. Meta formalized it as the "Agents Rule of Two": Willison's three properties — private data access, untrusted content exposure, external communication — are treated as a budget of two. An unsupervised agent may satisfy at most two of the three; combining all three requires a human in the loop (Help Net Security). Underneath that heuristic, the concrete mitigations converging across vendors are unglamorous and familiar to anyone who's done cloud security: scoped OAuth tokens instead of wildcard permissions, short-lived credentials instead of long-lived secrets, sandboxed execution with default-deny outbound network access, and static analysis run against tool descriptions before they're ever loaded, specifically to catch hidden instructions (Practical DevSecOps; SOC Prime).
None of that is novel security engineering — it's least-privilege and defense-in-depth, decades old, now being re-derived for a new class of system because the first wave of MCP servers shipped without it. The honest extrapolation is that agent tooling follows the same curve web application security did: a chaotic build phase, a wave of real incidents, then a slow, uneven adoption of the boring controls that were always the answer. Where the extrapolation runs out is timing and completion. Willison's own framing is blunt about the ceiling: "we still don't know how to 100% reliably prevent this from happening" through prompt-level defenses, because the model genuinely cannot distinguish instruction from data inside its own context window. Rule of Two, scoped tokens, and sandboxes reduce blast radius; none of them close the architectural gap. Regulation is arriving in parallel but on its own clock — DORA's four-hour incident notification, NIS2's 24-hour early warning, New York's RAISE Act at 72 hours, California's SB 53 at 15 days, 42 regulatory instruments tracked across 10 jurisdictions in the OWASP report — which mostly guarantees that incidents get reported faster, not that they get prevented.
And there's real evidence against the tidy "governance catches up" story: adoption is outrunning the fixes, not waiting for them. The five most advisory-flagged frameworks are also the five fastest-growing. a16z's adoption data puts coding agents ahead of every other enterprise AI use case by nearly an order of magnitude. IBM data cited in the same OWASP report found only 37% of organizations have any policy to even detect unauthorized "shadow AI" tool use inside their own walls (Help Net Security). If the market were self-correcting on any reasonable timeline, that number would not still be this low a full year after the first wave of serious incidents. The more honest reading may be that security is once again a tax paid after the fact, at whatever pace incidents force it — not a precondition adoption is waiting on.
What if...
What if tool manifests get cryptographically signed at the protocol level — the equivalent of package signing for npm or PyPI, but for MCP tool descriptions themselves, so a client refuses to load a tool whose description changed since the last trusted build. This would close the specific "rug pull" and "shadowing" patterns behind postmark-mcp and the WhatsApp demo. For it to happen, it needs coordinated buy-in from the handful of companies that control the dominant MCP clients, a registry willing to enforce signing rather than merely recommend it, and a migration path that doesn't break the long tail of servers already in production. Nothing currently forces that coordination.
What if "agent identity and audit trail" becomes a genuine compliance line item, the way SOC 2 did for cloud vendors — every tool call cryptographically attributable to a specific agent, task, and human authorization, queryable after the fact the way financial transactions are. The regulatory pressure (DORA, NIS2, RAISE, SB 53) points this direction, but it requires the reporting clocks currently aimed at incident notification to expand into routine attestation, which is a much bigger ask than anything on the books today.
What if the Rule of Two gets automated instead of policed by convention — agent frameworks refusing by default to instantiate a configuration that satisfies all three trifecta properties, the way modern browsers refuse mixed HTTP/HTTPS content instead of trusting developers to remember. This is the most tractable of the three, and the one I'd bet on first, precisely because it doesn't require cross-vendor coordination — one framework doing it well creates competitive pressure on the rest.
What I'm doing about it
The part of my own portfolio that maps most directly onto this problem is HawkClaw, an autonomous red-team platform I built that orchestrates 17 agents across the phases of a kill chain, benchmarked at 7 of 8 on XBOW's hard tier. The engineering lesson that transfers isn't about attack technique — it's that the moment you give a fleet of agents real tool access, the governance layer (rules of engagement, MITRE ATT&CK mapping as a shared vocabulary, explicit deconfliction between agents acting concurrently) stops being paperwork and becomes the thing that decides whether the system is trustworthy at all. That's the same lesson OWASP is deriving from the defensive side, just arrived at from the offensive one. I run my own content and research operation on a fleet of scheduled, tool-calling agents, and the practical version of the Rule of Two shows up in mundane places: which agent gets a scoped credential versus none at all, which actions require my own confirmation before executing, and what gets logged so a bad decision is traceable after the fact rather than invisible. None of that is exotic. It's the same least-privilege discipline this article just described enterprises re-learning at scale — just applied to a much smaller fleet, first.
Next week, back to the agents themselves: what changes when the automation running a piece of your business has more standing autonomy than the people accountable for it realize.
Research home: blackicelabs.ca