AI agent security assessment

Evals measure capability. They do not measure blast radius.

Agent deployments get tested the way features get tested: does it complete the task, does it score well on the eval set, does it behave in the demo. Those are capability questions.

The security questions are different, and they are usually unasked:

• What can this agent actually reach — every tool, every credential, every system on the far side of an integration?
• What can an untrusted input make it do? Not just a user prompt: a retrieved document, a web page, a ticket body, a file name, a tool's own response.
• What happens when a tool returns something adversarial rather than something malformed?
• When the agent is wrong, how far does the damage reach before a human sees it?

An agent is a program whose control flow is determined by text it did not author. That is an unusual trust model, and most of the deployments we see have not had it examined by anyone.

What you get

• A capability and reach map: every tool, credential, data source and downstream system the agent can touch, transitively. This is the artifact clients tell us they did not have — it is usually wider than the team believed.
• Injection reachability analysis — direct and indirect. Not "we tried some prompts," but which untrusted inputs reach the model's context, through what path, and what each one can steer.
• Blast-radius assessment per tool. A read-only search tool and a tool that can write to a ticketing system fail very differently. Ranked by consequence, not by call frequency.
• Trust-boundary review of the agent stack — model provider, orchestration framework, MCP servers and plugins, vector store, memory. Each is a supply-chain dependency with its own reachability.
• Failure-mode analysis: behaviour on adversarial tool output, context poisoning, memory persistence across sessions, and multi-agent trust between components.
• Human-in-the-loop review — where approval gates exist, whether they can be bypassed or made meaningless by volume, and whether the approver is shown enough to actually decide.
• A coverage ledger. Every surface and every class considered, with a verdict and evidence per cell — including what came back clean and how we know.

How we work

Reach before prompts. The first question is not "can I jailbreak it" — it is what the agent can do at all, and with whose credentials. An agent that cannot reach anything consequential is a different risk from one holding a production API token, no matter how injectable either is.

Untrusted input is traced to its source. Every path by which text the attacker controls arrives in the model's context, including the indirect ones teams rarely enumerate: retrieved documents, tool responses, file metadata, upstream agent output.

Tools are assessed as an attack surface, not as a feature list. Argument validation, authorization at the tool boundary rather than in the prompt, what a confused-deputy call looks like, and what the tool does with a value the agent was talked into producing.

Non-determinism is treated as a testing problem, not an excuse. "It didn't do that in our tests" is not a control. We look for the properties that must hold on every run and whether anything enforces them, rather than sampling behaviour and hoping.

Findings come with reproductions. Probabilistic does not mean unverifiable — it means we state the conditions and the observed rate rather than claiming determinism we did not see.

On critical infrastructure specifically

Where agents touch operational environments, two things dominate the assessment: what the agent can do without a human in the path, and what the system does when the agent fails or is unavailable. Fail-safe behaviour matters more than accuracy. We are explicit about the line between assessing an agent and certifying an OT system — we do the former.

The EU AI Act's high-risk classification covers critical-infrastructure AI, so this work increasingly has a compliance driver alongside the security one.

Why us

We build and operate multi-agent systems ourselves — our own research pipeline is one, with a coverage ledger, per-cell verdicts, and a positive control behind every empty result.

That matters for a specific reason. The dominant failure in agent systems is not the dramatic jailbreak — it is the silent one: a tool that returned nothing because it was misconfigured, a retrieval that matched nothing because the index was empty, a step that was skipped because an earlier one failed quietly. The agent proceeds confidently on an absence and produces a fluent, wrong answer.

We have hit every one of those in our own systems, and the discipline we built to catch them is the discipline we bring to yours.

Engagement shapes

Shape	Fits	Typical duration
Agent assessment	One deployed agent or workflow	1–3 weeks
Platform assessment	The agent framework and tool layer several agents share	3–5 weeks
Pre-deployment review	Before an agent gets production credentials	1–2 weeks
Retained review	Each new tool or capability reviewed before it ships	ongoing

Scoped per engagement. The pre-deployment review is the cheapest useful moment — reach is far easier to constrain before an agent has been wired into six systems than after.

Questions we get asked

We already red-team the model. Isn't that this? No. Model red-teaming asks what the model will say. This asks what the system will do — which is mostly a question about tools, credentials and reach, and is largely independent of which model you run. Swapping models does not change your blast radius.

Our agent only reads. Is it in scope? Usually yes, and read-only agents are where people are most surprised. Exfiltration is an action, and an agent that can read sensitive data and emit text into any channel an attacker observes has a path out.

Can you test against production? No. We work against a representative environment with the same tool surface and credentials scoped to match. We do not exercise live actions in an operational system, and we will say so plainly if a finding cannot be safely demonstrated outside production.

What if the finding is "the design is wrong"? Then that is the finding, and we would rather deliver it than a list of prompt filters that treat the symptom. Prompt-level mitigations for a reach problem buy very little.