Autonomous agents
AI agent security testing
An agent is a program that decides what to do next based on text it was given. Every security property you care about depends on what it is allowed to do when that text is hostile.
The context
Why this is different
Single-turn LLM features have a bounded blast radius. The model produces text, you render it, and the damage is limited to what that text can reach. Agents remove the bound. They plan, they call tools, they observe results, and they call more tools based on what they observed. A single injected instruction early in that loop can influence every step that follows.
The interesting failures are almost never in one tool. They are in composition. A read tool and a write tool are both individually reasonable; chained by an attacker they exfiltrate. A tool that fetches a URL and a tool that reads a file are fine separately; together they read your environment and post it somewhere.
The second recurring problem is identity. Agents frequently run with a service account because that was the fastest way to make them work. The agent then has more authority than the user it is acting for, and the whole permission model collapses into whatever the agent can be talked into doing.
What we look for
The failure classes that actually show up.
Privilege escalation across a tool chain
No individual tool is over-permissioned. The composition is. We enumerate every tool and look for pairs and triples that combine into something none of them grants alone.
read_file('.env') -> summarise -> http_post(url, body) three reasonable tools, one exfiltration path
The agent acts with more authority than the user
Tools run with a service account or an admin token rather than credentials scoped to the requesting user. Any successful injection then inherits that authority, and your application-level permissions become decorative.
Indirect injection through observed content
Agents read what they fetch. A web page, a ticket, an email, a repository file or an API response becomes instruction rather than data. The attacker plants content and waits for the agent to encounter it.
Memory and state poisoning
Agents with persistent memory can be given instructions in one session that fire in another, potentially for a different user. We test whether memory writes are attributable, scoped and bounded, and whether a poisoned entry survives a session boundary.
Human-in-the-loop bypass
Approval gates that check the wrong thing. Confirming an action by name while the parameters change afterwards, batching many operations behind one approval, or approval prompts that the agent itself composes and can therefore describe misleadingly.
Unbounded loops and denial of wallet
No cap on plan depth, no per-task token budget, no timeout. An input that causes the agent to retry indefinitely is both an availability problem and a direct cost problem, and it does not require an attacker to trigger.
Trust between agents
In multi-agent systems, output from one agent becomes input to another and is usually treated as trusted. We test whether a compromised or manipulated sub-agent can influence a more privileged one.
Actions you cannot reconstruct
When an agent does something wrong, can you determine what it did, why, and on whose behalf? Absent or unattributable logging turns a contained incident into an unbounded one, and it fails Annex A 8.15 as well.
How we test it
The engagement.
- 01
Enumerate tools and their real credentials
Every tool the agent can invoke, what identity it runs as, and what that identity can reach. We compare that against what the requesting user is permitted to do, and the gap is the finding.
- 02
Compose escalation chains
Systematic search for tool combinations that produce capabilities no single tool grants. Read plus network egress, write plus execution, credential access plus anything.
- 03
Plant hostile content in every observation path
Web pages the agent fetches, files it reads, tickets it processes, API responses it receives. We follow whether planted instructions change the plan and what they can then reach.
- 04
Attack the approval boundary
Where a human confirms actions, we test whether what is displayed matches what executes, whether parameters can change after approval, and whether batching hides individual operations.
- 05
Memory and cross-session testing
Whether one user can write memory another user's session reads, whether poisoned entries persist, and whether memory is scoped per tenant as well as per user.
- 06
Limits, then verify
Loop depth, token budgets, cost ceilings and timeouts tested for real rather than read from configuration. Every finding reproduced by a consultant, then retested after you fix it.
What you get
Deliverables
- From
- $7,500
- Typical duration
- 2 to 3 weeks
- Tool inventory with the effective privilege of each one
- Escalation chains found, with a working proof of concept for each
- Injection paths traced from source through to consequence
- Approval boundary assessment with bypasses demonstrated
- Memory and multi-agent trust findings
- Cost and availability limits tested, with recommended ceilings
- Free retest and reissued report after remediation
Questions
The ones engineers ask.
Scope tool credentials to the requesting user rather than to a service account. It is unglamorous and it collapses most of the severe findings at once, because an injection that succeeds can then only do what that user could already do. Everything else is defence in depth on top of that.
Use one if you like, but do not build your security model on it. Filters are probabilistic and attackers iterate. Design so that a successful injection reaches nothing important, then add detection as a second layer.
Yes, and read-only is less protective than it sounds. Read plus any network egress is exfiltration. Read plus the ability to write into a shared context that another user sees is a delivery mechanism. We look specifically at what read access composes with.
We test the boundary rather than the behaviour. Whether a specific prompt succeeds on a given run varies. Whether the tool runs with an over-broad credential does not, and neither does whether output is sanitised before it reaches a sink. Findings are structural, which is also why they stay fixed.
Yes, and it should. The report serves the same evidence purpose as any application penetration test for Annex A 8.8 and 8.29, and the tool permission mapping is directly useful for your access control documentation.
Know exactly what an auditor, and an attacker, would find.
Tell us what you need certified or tested. We will scope it properly, quote a fixed price, and tell you honestly if the timeline you have in mind is realistic.
No sales sequence. A scoping call and a written proposal cost nothing.