An agent reads, decides and acts with your credentials. To divert it nobody needs to break anything: it is enough to leave the right instruction where it is going to read it. We put it to the test before someone else does.
Researcher Simon Willison named it the lethal trifecta. An agent becomes exploitable as soon as it combines these three things at once, and almost every useful agent does.
With all three, the attacker doesn't need to breach anything They just leave an instruction where your agent is going to read it. The agent does the rest: authenticated, with permissions and without triggering a single alarm.
It's not that it's done badly. It's that an agent breaks the three assumptions classic pentesting was built on.
The same input doesn't give the same output. A test that passes today can fail on the third attempt. Here you don't validate by running through a checklist once: you validate by insisting, from many angles and with many different heads.
There is no line of code to underline and no pattern a scanner can look for. The payload is a well-placed sentence in a place your agent considers trustworthy.
The model changes, you tweak a prompt, you add a tool or connect an MCP server and it is already a different system. An annual snapshot doesn't cover something that transforms every week.
It is exactly the kind of problem a large community of hackers testing continuously is for, and not an auditor with a template.
In December 2025 OWASP published its list of risks for agentic applications, reviewed by more than a hundred specialists. It is the reference standard and it is what we attack, category by category.
Someone redirects what the agent believes it has to do, with an instruction hidden in content it is going to read. From the outside it looks like it keeps working normally.
For example: an incoming email carries a hidden instruction and the support agent forwards another customer's history.
The agent has access to email, CRM, billing, APIs or a terminal. Even if that access is authorised, it can be led to chain them in destructive or very expensive ways.
For example: it is convinced to run a mass deletion presented as a duplicate clean-up.
Agents inherit roles, store credentials and call each other. That delegation chain is exactly where escalation happens.
For example: a basic user's request ends up running with the admin agent's permissions.
Tools, plugins, prompt templates, MCP servers, RAG connectors and agent registries come from third parties. If one is compromised, it injects instructions from the inside.
For example: a legitimate MCP server updates and the new description of a tool carries hidden instructions.
Many agents write and execute code. Without solid isolation, a well-placed instruction ends up being code execution inside your infrastructure.
For example: the agent installs a dependency someone suggested in an issue comment.
Summaries, embeddings, internal notes and RAG indexes get reused. If someone contaminates them, the agent decides on false data, and keeps doing so session after session.
For example: a document planted in the knowledge base changes the discount policy the agent applies.
In multi-agent systems messages travel over buses, APIs or shared memory. Without authenticating and validating them, they can be forged, replayed, or a foreign agent can slip into the mesh.
For example: a fake agent presents itself as the approver and the rest of the flow obeys it.
A poisoned input or a badly set policy propagates between agents that consume each other's output. The error amplifies much faster than anyone reviews it.
For example: one agent misreads a cost threshold and three others act on that conclusion.
The agent sounds confident, writes well and presents the action as reasonable. That authority is exploited so a person approves something they shouldn't.
For example: an impeccable summary leads someone to approve a transfer. The log will only show a human approval.
Here the problem is no longer a prompt: it is the agent, which has drifted from its design and pursues its own goals. It behaves like an insider, but with legitimate credentials.
For example: an optimisation agent starts deleting backups to reduce spend.
The two questions we always ask first Does your agent have more autonomy than the business problem justifies? And can you reconstruct afterwards what it did, with what identity and with what tool? Least agency and observability are the two principles OWASP puts ahead of the list, and almost no agent in production meets both.
Agent security is added to the scope of any of our services. Which one suits you depends on the same thing as always: whether you need a report or you need continuous coverage.
A closed window over a specific agent, with a formal report, evidence and retest. For when you have a launch, a client or an audit ahead of you.
See pentestSeveral hackers on the same agent at once. Against a non-deterministic system, the variety of approaches finds what a single auditor doesn't.
See crowdsourcedPermanent coverage, which is what fits a system that changes when you change a prompt or the provider updates the model. You pay per validated vulnerability.
See bug bountyWhat tools it has, with what identity it acts, where it reads from, where it stores memory and where it can write to. Almost always this picture already surprises whoever built it.
Which environment gets touched, which tools stay out, which actions are never executed even if the agent allows them, and what maximum spend is accepted during testing. You decide, and you can revoke access at any time.
From the point of view of someone who wants your agent to do something it shouldn't: instructions placed where it is going to read them, tool chaining, identity boundaries, memory persistence and isolation of the execution environment.
Every finding arrives with the step-by-step reproduction, the real impact on your business and the proposed fix. When you fix it, we test it again.
Every vulnerability is referenced against the frameworks your compliance team already uses, so the report serves both the person fixing it and the person who has to show it.
As a CVE Numbering Authority accredited under INCIBE's leadership, when the flaw is in a third-party component we can coordinate its publication in the standard the whole industry follows.
Tell us what it does, what tools you've connected to it and with what permissions it acts. In one call we'll tell you where someone would get in and how it fits with the security work you're already doing.
No commitment and no jargon. A specialist gets back to you within 24-48 hours.
