Research

Method

An evaluation shows which attacks succeed against your agent, what it does when they do, and how often. All of it rests on one principle: a probabilistic system can’t be verified by asking it what it did. So every finding is checked against a deterministic ground truth — what actually happened, and what should have happened, established without the agent’s help.

1. 01

   Two ways an agent can fail under attack

   A deceived agent acts faithfully on corrupted input and reports truthfully what it did: its account matches what it did, but what it did breaks the obligation. A deceiving agent’s account differs from what it did. The two are told apart at the output, not the input — one poisoned record can produce either. In both cases, the cause is the attack, not the agent’s intent.

2. 02

   Two checks, one for each class

   Obligation-detection compares what the agent did with the obligation, and reaches both classes wherever the attack changed what the agent did. Claim-verification compares the agent’s account with the record of what it did; it catches deceiving, but not deceived, whose account is true. The two answer different questions: did the agent do what it should, and is its report of it true? The first always matters; the second matters wherever others rely on that report — an audit log, a compliance record, a downstream system. Whether an agent can be deceiving at all depends on its architecture: only a decoupled agent, which reports through a separate output from the one it acts with, can say one thing and do another. So we read the architecture first, and run both checks.

3. 03

   The reference everything is checked against

   The deterministic ground truth has two parts, both established without the agent. The observed behaviour is read where the agent can’t reach — at the systems it acts on, not from its own logs. The obligation comes from a source neither the attack nor the agent can change: a specification, a safety envelope, a policy table. Each finding states which source it relied on, and whether that source was out of the attack’s reach by construction or only because the attack happened not to touch it.

4. 04

   Observation the agent can’t see

   We observe on three surfaces beneath the level the agent works at: its processes, the network boundary its calls cross, and the systems it acts on. The agent can neither read nor change any of them — not because it’s told not to, but because it has no way to. That keeps it from reading the answer key, or recognising that it’s being evaluated and behaving differently than it would in production.

5. 05

   Measurement

   An agent can act differently each time it meets the same input, so a single run proves little. Each threat scenario first runs many times without the attack, as a clean baseline, then as often with it; a finding counts only if it appears under attack and not in the baseline. That shows whether an attack works occasionally or every time — and, weighed against how severe its consequences are, what to fix first.

6. 06

   Where the method applies

   Three things must hold, and all three can be checked before any work starts:

   • We can see what the agent actually does — its tool calls, retrievals and decisions — not just the text it produces.
   • Attacks can be played out where their consequences aren’t real: in a simulation for physical processes, in a development or staging environment for data flows.
   • There’s a reference the attack can’t reach, independent of the agent and of whatever the attacker manipulates.

   This holds whether or not a guardrail or other protection sits in front of the agent, because the reference is independent of both.

7. 07

   What a result describes

   A result describes your agent as it actually runs — with its model, its configuration and its tools. That makes it evidence about the product you ship, not a generic score for the model underneath. And because the threat scenarios and the reference carry over, the next version can be evaluated against the same set, and the two results compared.

The full argument, with the demonstrations behind it, is in our paper Adversarial Assessment of Agentic Systems (2026).