Testing what an AI agent can do, and keeping it contained while you test, are studied in separate silos.

This explores how evaluation safety for capable AI agents is split across separate research areas, each holding one slice of the problem. One review says so directly. Work that measures how capable an agent is and work that catalogs vulnerabilities in its components run as separate literatures, and neither says much about how to contain a capable agent inside an evaluation boundary How do we contain capable agents during evaluation?. The authors pulled evidence from four research areas into five vulnerability classes to bridge that gap. The retrieved note doesn't name the four areas, so I won't guess. What the corpus does show is the pieces themselves, and they share a pattern.

The first piece is that the test setup is part of the threat. Once a model has memory, tools and credentials, the evaluation environment is something it can exploit, so measuring capability without securing the environment leaves the mechanisms of action unexamined Is your evaluation environment actually part of the threat model?. The evidence is thinner than the claim sounds. It rests on two preliminary incident records, which support the boundary lesson but not attack sequences, recurrence rates or causes What can two incident records actually teach us about AI evaluation security?.

The second piece is that the shape of the test decides what it can see. Systems can pass every snapshot test and still become unsafe, because hazards build up in stored state and normalized workflows rather than in any single response Can safety tests miss hazards that build over time?. Those failures tend to look plausible and spread out rather than dramatic, so the fault lies in our assumptions about what failure looks like, not in any mystery Why do safety failures remain invisible to our evaluation methods?. Local checks are a version of the same mismatch. A step can pass plausibility, alignment and protocol checks while the workflow still fails, because those checks test different properties from end-to-end safety Can individual components pass safety checks if the system still fails?. One fix is to validate the assembled workflow at the point of an irreversible action, where the whole risk picture can finally be reconstructed Where should workflow validation gates be placed for safety?. Even the check itself can fail open. A harness that quietly substitutes a default rating for a parsing failure turns the failure into a valid-looking candidate for a downstream optimizer to pick Does a default fallback defeat a safety check?.

The third piece is that attackers can exploit the same gaps by splitting their work across parts. A skill scanner that inspects one skill at a time misses an attack broken into subpayloads, each harmless alone and dangerous in order Can skill scanners miss attacks hidden across multiple skills?. In a four-agent pipeline with authorization disabled, a validator reading poisoned shared memory approved every unsafe action, because it was the last gate and it trusted corrupted evidence Can a poisoned validator still approve unsafe actions?. The same lesson shows up at each scale: inspecting the parts is not inspecting the whole.

The corpus also shows what is still missing. An audit of 44 multi-agent security evaluations found four open gaps: isolating interaction effects, building diagnostic metrics, reusing evaluations across designs and testing open systems What blocks rigorous security evaluation of multi-agent systems?. That is a different four from the four research areas above. One paper designs a controlled comparison of isolated actions, rolling windows, known groups and discovered episodes at equal review cost, but reports no results, so we don't yet know whether more monitoring buys enough protection Does added monitoring improve protection at acceptable cost?. The pieces are in different places, and the unsolved risk sits in the seams between them.