Prompt injection is now a pentest finding. Here's how we test for it.

We build an autonomous offensive agent, you can watch it take a machine from a bare IP to root, so we spend a lot of time thinking about what happens when the thing under test is itself an agent. That used to be a research curiosity. In 2026 it's a line item. HackerOne reported a 540% surge in prompt-injection reports, calling it the fastest-growing threat in AI security, and the incidents stopped being toy demos: a coding agent tricked into writing a malicious tool-config file and achieving remote code execution, a hostile package that shipped fifteen clean releases before adding exfiltration, an RCE rated 9.6 in core agent-tooling infrastructure.

If your product has an LLM with tools wired to it, and most products now do, then prompt injection is no longer a novelty. It's a finding class that belongs in a pentest. This post is how we think about it. To be upfront: testing customer AI agents is not a shipped Pwnkemon SKU today, this is our perspective as people who build one, not a feature announcement.

Why prompt injection is different

Classic injection, SQL, command, has a clean boundary: code here, data there, and the bug is data crossing into the code channel. An LLM erases that boundary by design. Instructions and data arrive in the same channel, natural-language text, and the model's entire job is to act on that text. There is no equivalent of a prepared statement that cleanly separates the two. That's why prompt injection is stubborn: it isn't a bug in one parser, it's a property of how the system works.

The danger isn't the model saying something rude. It's the model acting, because it has tools. An agent that can read your email, call your APIs, run shell commands, or write files is an agent that can be steered into doing those things by text it was merely supposed to read. The two shapes that matter:

• Direct injection: the user tells the agent to ignore its instructions. Annoying, mostly a policy problem.
• Indirect injection: the malicious instruction is hidden in content the agent processes, a web page it summarizes, an email it triages, a file it reads, a tool result it ingests. The attacker never talks to the agent directly. This is the dangerous one, and it's the one that produced this year's real RCEs: content the agent trusted told it to write a config that handed an attacker control.

How we'd test an agent

The same way we test anything, assume breach and see how far it goes. The relevant questions aren't “can we make the model misbehave” (you almost always can, given effort) but “what can a successful injection actually reach?”

1. Map the tools. What can the agent do? Every tool is a capability an injection inherits. An agent with a read-only search tool and an agent with a shell tool are not the same risk, even with the identical prompt.
2. Find the untrusted-content paths. Every place external content enters the context, retrieved documents, tool outputs, user uploads, third-party API responses, is an indirect-injection surface. This is the actual attack surface, and it's usually bigger than the team thinks.
3. Test privilege boundaries under injection. If an injection succeeds, can it call a tool the current user shouldn't be able to? Read another tenant's data? Escalate? A prompt that gets the model to try a privileged action is only a finding if the action isn't independently authorized, which is the whole point.
4. Check the exfiltration paths. Can an injection get data out, by making a network call, embedding it in a rendered image URL, writing it somewhere readable? Data theft doesn't need shell access if the agent will politely hand it over.

The principle that actually helps

There's a line from the research this year that's worth internalizing: an agent that thinks must never act, at least not without an independent gate. You will not fully prevent prompt injection at the model layer, treating it as a filtering problem is a losing game. What you can do is make a successful injection worthless by putting the authorization outside the model.

Concretely: don't let the model's decision to call a tool be the same thing as the authorization to call it. Gate privileged actions on the actual user's permissions, checked by code the model can't talk its way past. Scope tool credentials to the minimum. Treat every tool result as untrusted input, not trusted context. This is exactly the design we use in our own agent, its offensive primitives run against real targets, but destructive or lateral moves sit behind explicit gates and audit, the same posture we described in how a compromised scan container still can't leak your code. The model proposes; independent code disposes.

The three layers that work

No single control is enough. The combination that holds up:

• Injection red-teaming, actively trying to steer the agent through its untrusted-content paths, before an attacker does.
• Tool-call authorization, every privileged action checked against the real user's permissions by non-model code.
• Runtime containment, least-privilege credentials, egress controls, and isolation, so a successful injection reaches as little as possible.

Where this leaves you

If you're shipping an agent, the honest self-assessment is: list every tool it can call, list every place untrusted content enters its context, and ask what happens at the intersection. If the answer depends on the model “being careful,” you have a finding, because the model can be talked out of being careful, and this year attackers proved it 540% more often than last.

We're not selling you agent-testing today, we're telling you how we'd approach it, because we build the kind of agent that would do the attacking. If you want to see that offensive agent work against a conventional target first, the Enigma writeup is the place to start, and pricing covers the scans we do ship.