The risk is what your AI can do with the access you gave it.
A chatbot answers a question. An agent takes an action: it books, buys, queries your database, runs code, with real permissions. So one hijacked instruction stops being a bad sentence. It becomes an action taken with your access, at machine speed, with no one watching.
Give a model autonomy and tools, and a single bad input has a blast radius.
OWASP now ranks prompt injection as the number-one risk to these applications, with “excessive agency” (handing an agent more power than it needs) close behind. In a lab, researchers went one step further: they demonstrated a proof-of-concept “AI worm,” a prompt injection that copies itself from one agent to the next with no human in the loop. No one has seen it loose in the wild. What it proved is the mechanism: the model’s permissions are now part of your attack surface.
One instruction hidden in what the agent reads, fired straight into the access it already holds.
And they walk straight through zero trust.
Zero trust was supposed to catch exactly this. But it was built for human-initiated actions: someone joins, gets credentials, changes role, leaves. Agents don’t break a working system; they walk through the gaps in one that was never finished. Four fault lines open the moment they arrive.
The identity explosion
A developer spins up five agents on a Tuesday afternoon. Each gets credentials, access and a signed token, with no approval and nobody watching. To the policy engine, every one looks like a valid user. Handshake complete. Trusted.
“Can I?” was never “should I?”
Least privilege checks whether an agent can act. But an agent reasons its way to needing more (competitor data, then HR access, then send-email) and is often granted it. Zero trust has almost no mechanism for whether it should.
The attack it can’t see
Indirect prompt injection hides instructions inside data the agent is authorised to read. Valid identity, authorised action, foreign agenda. The policy engine is blind to the email body. It sees a valid user issuing a valid command.
Where accountability dies
Human → agent → agent → agent → resource. When hop four does the damage, the log shows the last agent. The compromise was three hops upstream. And an agent’s whole point is doing the unexpected, so anomaly detection has nothing to grip.
By the action that does the damage, the original intent has all but evaporated, and the log points at the wrong agent.
The short version. We wrote the full teardown: the identity math, why anomaly detection can’t catch a compromised agent, and the mitigations that actually cut exposure. Read “The Day Zero Trust Died” →
We red-team the agent and its tool-chain.
What can it be talked into doing?
We test the agent against the permissions and tools it actually holds (payments, code execution, data access), not just whether the model says something it shouldn’t. The question is what an attacker can make it do with your access.
Instructions hidden in what it reads
The dangerous prompt often isn’t typed by a user. It’s buried in an email, a web page, or a document the agent ingests and obeys. We smuggle instructions through the content channel, the way the AI-worm research did, and see what fires.
The model you didn’t build
Third-party models, plugins, datasets, and the vector stores behind retrieval all carry risk you inherit. We assess what comes in with them, because most teams are integrating AI, not training it from scratch.
The offensive edge of the AI work we already do, and we build our own offensive models to do it faster. Engagements map to the frameworks buyers recognise: OWASP’s LLM Top 10, MITRE ATLAS, and NIST’s AI risk guidance. See the broader practice on AI security testing.
Before you give an agent the keys, find out what it does with them.
If it can move money, touch customer data, or run code, it deserves the same adversarial test you’d give a new employee with those powers. Before it goes live, not after.