Standards
Reading AIUC-1 like an auditor: the evidence a risk committee asks for
A walkthrough of the controls that matter for autonomous agents, the B-codes they map to, and what counts as defensible proof.
Most teams approach AIUC-1 as a checklist. Auditors don't. They read it as a chain of claims, each of which must be backed by reproducible evidence tied to a concrete failure mode. The difference matters: a passing benchmark number proves nothing about whether a given control actually contains a given technique on your deployment.
The backbone of the framework is its B-coded controls. Each maps to a class of attacker behavior — prompt injection, tool abuse, system-prompt extraction, data leakage — and to the mitigations expected to contain it. When you can show, for a control, the technique it was tested against, the configuration under test, and the observed outcome, you have something a risk committee can sign off on.
This is also where generic data stops being enough. Population-level results describe how configurations like yours tend to fare; they cannot make a claim about your specific agent. The audit-ready report exists precisely to close that gap with per-deployment evidence.
Below we walk through three controls and the evidence each demands — what to capture, how to phrase it honestly, and where synthetic results are appropriate versus where a live test is required.
An auditor doesn't want a score. They want evidence that a specific control was exercised against a specific technique.
Mapped to
B-01 · B-03 · B-12
Synthetic reproduction · sanitized example only · full attack set withheld.
Configurations like yours — generic results describe the population, not your specific agent.