Agents are writing our codebases and running on our platforms, and the security conversation hasn't caught up. A field note on the vectors that came back, and one I opened on myself.
Agents are writing our codebases and running on our platforms, and the security conversation hasn’t caught up. Six months ago, when I was the one writing the code, vulnerabilities were a huge topic. Now that agents build the codebase, the problem got harder, not easier, and it’s gone quiet. It isn’t just the code they write. It’s the invisibility of the ACL and security boundaries. And yes, I do not inspect every line the agent writes. Don’t tell me you do.
Then it compounds when you run an agent on your platform. There are just so many vectors to exploit now, and the exploiter has become everyone with an agent, not only those who understand software deeply.
Twenty years ago #
Around twenty years ago I tested about ten popular public websites in one day and was able to gain some form of access to eight of them, and I’m not a security expert. That’s how bad the situation was. (I posted a blog about it, without disclosing the details, and emailed the affected sites.)
Most of it was XSS and SQL injection. Those largely disappeared over the years thanks to:
- more secure-code awareness,
- better automated vulnerability detection (npm audit, Chrome, and friends), and
- libraries that abstracted away the highly vulnerable surfaces: ORMs wrapping SQL queries, React refusing to render raw HTML, and so on.
The dangerous defaults got replaced with safe ones. You had to go out of your way to be insecure.
The same door, reopened #
But in the same way copy-and-paste came back into fashion, so did insecure code.
I’ve just been reviewing the work my agent did, and there are security vulnerabilities all over the place. Most of it is ACL inconsistencies, likely from loss of information in the human-to-LLM communication of what the ACL actually needs to be. The boundary lived in my head; it didn’t survive the trip into the prompt.
The scary ones, though, come from the agents I deployed for customers.
I recently gave an agent the ability to receive and send emails. Then I decided to add instructions inside the emails for the agent to follow. It took me a few minutes to realize I’d just opened a huge security hole. Email senders can be spoofed easily. SPF helps, but that’s domain-level. So an email becomes prompt injection and an ACL hole at the same time.
We’re not thinking security-first #
Because we’re building so fast, we’re inherently not thinking security-first. I’m doing that now, when normally I’d already be building with security in mind. Years of coding taught us to write secure code and to lean on frameworks that made the safe path the default.
That isn’t built into the agent workflow yet.
Am I missing a big agent-security channel that everyone else is on? Has Claude hidden it from me? If you’re having this conversation somewhere I’m not, point me at it. I’d rather learn the vectors from a thread than from a customer.
Read part two: You can’t prompt your way out of prompt injection: how I designed a security-first architecture for agents that’s ACL-gated by design, so a fully hijacked agent still can’t do any damage.