If you wrote PHP long enough, there is a scar you carry: the day you understood what unserialize() does when an attacker controls the string. POP chains, phar tricks, session blobs that turned into shells — we spent years learning that a stored value is still user input, no matter how many layers it passed through on the way to disk. I bring this up because the AI agent ecosystem is currently re-taking that exam, question by question, and mostly getting the same answers wrong we did. That's my thesis: the security story around agent frameworks in 2026 is not a new discipline. It's our old one, and PHP developers are unusually well equipped to apply it.

The occasion is Black Hat 2026. Yarden Porat and Shahar Tal of Check Point Research spent a year attacking the frameworks everyone is building agents on — LangChain, LangGraph, CrewAI, AutoGen, Microsoft's Agent Framework, Google's ADK — and walked away with eleven vulnerabilities; The Register picked it up this week. Tal's reported analysis is worth attributing precisely: you should assume agents will read hostile content, and the actual failure is when that content ends up steering the trusted machinery — orchestration, memory, system instructions. He added that an agent doesn't even need dangerous tools enabled to be turned against you; ingesting the wrong document can suffice. Note what that argument does: it moves the bug out of the model and into framework code. Which is where we live.

Take the Microsoft Agent Framework finding. Agents persist checkpoints — snapshots of their state so a task can resume after a failure. Check Point showed a payload could ride inside a message, get frozen into that checkpoint, and then execute when a different user resumed the session later, because the framework treated its own stored state as inherently clean. Result: remote access to the server, a $10,000 bounty, a fix, and no CVE since the framework wasn't generally available yet. Now do a find-and-replace: call the checkpoint a serialized session blob and this is a finding any PHP security review would have circled in red before the coffee got cold. We literally have conference-talk folklore about exactly this failure.

Google's ADK entry in the list is a different classic. The kit ships a built-in coding assistant for the development team — and in a standard deployment it answers to the open internet with no authentication at all. From there an attacker could have it write a file that runs automatically, execute it, and pivot to environment credentials and the service account the box uses to talk to the rest of Google Cloud. Google initially declined to treat it as a bug, then paid $3,133.70 and shipped a partial fix. Every PHP team I know has a deploy checklist item that exists purely because someone once left a debug toolbar, an exposed .env, or a wide-open Xdebug port on a production host. The lesson wasn't PHP-specific. Apparently it also wasn't learned outside our house.

And the Black Hat batch isn't an outlier. In June, the same Check Point team published a chain against LangGraph — a library with roughly 46.5 million monthly downloads — that starts with SQL injection in get_state_history() and ends in remote code execution. SQL injection. In 2026. The bug that prepared statements and a decade of PDO evangelism were supposed to make extinct. In May, Microsoft itself documented two critical holes in Semantic Kernel where a single prompt was enough to pop calc.exe on the host machine. Over in MCP land, a chain of three critical vulnerabilities in Anthropic's official mcp-server-git allowed remote code execution, and scans of public MCP servers keep surfacing path traversal and tool poisoning — tool descriptions manipulated so the model behaves differently than its operator intended.

Let me concede the strongest objection, because it's real: LLMs do add something genuinely new. There is no htmlspecialchars() for natural language. You cannot parameterize a prompt the way you parameterize a query, and prompt injection may simply be unsolvable at the model layer. Granted. But look at where the damage actually landed in every case above: a query assembled by string concatenation, a stored blob executed on trust, an endpoint nobody bothered to authenticate, a process running with credentials it never needed. The model was the messenger; deterministic code did the harm. And deterministic code is territory where we know how to win. You can't sanitize an attacker's prose — you can absolutely refuse to exec() something because a resurrected string asked politely.

This matters to us concretely, because agents are landing in PHP shops right now: MCP servers written in PHP, Laravel queue workers calling agent APIs, Symfony backends persisting conversation state next to customer data. So apply the reflexes we already own. Anything an agent stores and later re-reads is $_POST with a delay — validate on the way out of storage, not just on the way in. Run every tool the agent can invoke under the least privilege you'd give a cron job you didn't write. Authenticate endpoints even when they're 'only for the team.' And if you're on Psalm, its taint analysis was built for exactly this shape of problem: tracing untrusted input to a dangerous sink through code that looks innocent in the middle.

Two researchers, twelve months, eleven vulnerabilities across the most popular agent frameworks on earth — that ratio tells you how little scrutiny this layer has had, and how much low-hanging fruit remains. The PHP community went through its own hardening decade and came out with instincts worth exporting; this is a moment to be the adults in the room, not the skeptics in the corner. So here's what I actually want to know from you: where do you draw the trust boundary in your own agent integrations? When output or state comes back from an agent you deployed, do you validate it like a form submission from a stranger — or do you, honestly, still treat it as internal?