What Is AI Assurance? Techniques and Evidence for AI Agents

What Is AI Assurance?

AI assurance is the process of measuring and evaluating an AI system against written criteria, such as a law, a standard, an ethical guideline or a company policy, and reporting the result with the evidence behind it. Its output is a reasoned judgment that an auditor, a regulator or a release manager can act on.

The UK Department for Science, Innovation and Technology (DSIT) gives one widely used definition. Its Portfolio of AI assurance techniques, published on 7 June 2023, defines it this way: AI assurance "is about building confidence in AI systems by measuring, evaluating and communicating whether an AI system meets relevant criteria", with regulation, standards, ethical guidelines and organizational values as its examples of such criteria.

DSIT's Introduction to AI assurance of 12 February 2024 condenses it further: in the case of AI, "assurance measures, evaluates and communicates the trustworthiness of AI systems". Read as engineering requirements, the definitions ask for:

• Confidence with reasons - a belief backed by evidence, never a guarantee; an assured system can still fail on a case nobody tested.
• Written criteria - something specific to assure against, such as a regulation clause, a standard or a policy line, written down before the check.
• Communicated results - evidence that reaches the people who decide, as a report, a certificate or a release verdict.

In the US, NIST's AI Risk Management Framework, released on 26 January 2023 for voluntary use and now being revised as part of the White House AI Action Plan, covers the same ground from the risk side.

The AI RMF Core has four functions (govern, map, measure and manage); under measure, AI systems are to be tested before deployment and at regular points in operation, and measurement outcomes go to manage for risk monitoring and response. Read that way, most assurance work belongs to measure and feeds manage, with govern running through the other three.

What Are the Main AI Assurance Techniques?

The DSIT portfolio presents eight techniques as examples, introduced with "Some of these are listed below". The right-hand column is this article's mapping to the engineering work each one implies for an agent that acts.

The gov.uk AI assurance techniques library goes wider: its technique filter has 11 options, adding data assurance, risk assessment and assurance warranty, and the page reports 75 case studies.

DSIT's 2024 Introduction to AI assurance also lists risk assessment first among its six techniques.

The library's use-case filter includes "virtual agents or artificial conversational interfaces" and "robotic process automation and decision management", so systems that act are in scope. The short descriptions leave the evidence for such a system to the team that owns it.

How Does AI Assurance Change When AI Agents Act?

The definition carries over to agents; the evidence it takes is what changes. Some DSIT descriptions are framed around outputs, as when a bias audit examines inputs, outputs and the outcome of a decision. An agent plans steps, calls tools and changes records in other systems, which strains output-only checking:

• Effects outside the reply - a refund succeeds or fails in the payments record, whatever the reply says; the Agent Assurance docs warn that an agent "can produce a confident, well-written summary of work it never completed".
• One step can hide another - a wrong tool call at step two can be masked by a plausible recovery later, so a check on the final answer can still pass.
• Tools change on their own schedule - a renamed parameter in an API the agent calls can break it while the model and prompt stay the same.
• Write access raises the stakes - with a refund, email or delete tool, a failure costs whatever that tool can change.

The question moves from what the system said to what it did, and what evidence shows it. The post introducing Agent Assurance lists failure modes that slip past a transcript, such as confident false reports and silent policy violations. Policies, audit trails and how NIST compares with the EU AI Act are covered in agentic AI governance.

What Is the Difference Between AI Assurance, Observability and Evals?

Observability explains what an AI system did, mostly in production; evals score outputs against criteria someone defined; pre-release AI assurance decides whether an agent meets its written criteria, with evidence behind each verdict. Production tracing reports a failure after it shipped, and it is not built to hold the release that caused it.

The table compares the categories with Agent Assurance as the pre-release example. Its first and last rows are this article's framing, and the rows between follow the comparison in the Rook CLI README.

The eval and observability columns describe what each category does by default, not one product: several eval tools generate cases, check tool calls against a list and run red-team modules, and some observability platforms can also run datasets as offline experiments in CI.

Most observability and eval tools score an agent's replies and traces; Agent Assurance checks what each run changed and counts separately what it could not verify. The hub on AI observability covers tracing and metrics in production, and the guide to AI evals explains how an eval works and how to run one.

What Should an AI Assurance Verdict Contain?

For a governance team the verdict is the deliverable, and for an engineering team it is the release gate. A verdict that serves both includes:

• The criterion - one checkable statement traceable to a policy or spec, such as a rule that a refund over the approval limit needs an approval record.
• Evidence of what changed - recorded tool calls, files written, artifacts, command output and exit status, and records read back from the target system; the agent's reply carries the least weight.
• A three-way outcome - Pass when the criterion was checked and held, Fail when it was checked and did not hold, and Unable to Verify when the evidence could not settle it, counted on its own and never as a pass or a Fail.
• Coverage beside the pass rate - in an example in the Agent Assurance docs, eight scenarios pass and none fail, a 100% scenario pass rate, while 12 of the 20 acceptance criteria behind them are Unable to Verify: 40% of criteria verified. Say which denominator each figure uses.
• Reproducibility - the scenario definitions, agent version, invocation profile and date, so a rerun can be compared; an LLM agent can take a different path each time, so expect comparable results rather than identical ones.
• Retention - verdicts and evidence stored with the build, failed runs included, so a later review can see what the release decision rested on.

Sign-off, exceptions and the changes that should trigger a new run belong to the release record around the verdict, which AI agent validation walks through.

Which Pre-Release Assurance Checks Can You Run With Agent Assurance?

TestMu AI's Agent Assurance produces this kind of verdict for agents you own that act on systems: agents that use tools, edit files, call APIs and change records. It is pre-alpha and publicly installable. The terminal command is rook; install it from npm and confirm the version:

npm install -g @testmuai/rook
rook --version

Installing through npm takes Node.js 20 or newer. The Rook CLI install docs list macOS and Linux, and 64-bit Windows through npm or WSL, as supported platforms, and give brew install lambdatest/rook/rook for Homebrew users on macOS or Linux.

• Scenarios from code or spec - it explores a local checkout of the agent, or its PRD or spec, and generates scenarios across three classes and 16 categories. By default, generation plans functional and adversarial scenarios, though the planner can leave attacks out for a small agent; attack scenarios are mapped to the OWASP Top 10 for LLM Applications (2025), the OWASP Top 10 for Agentic Applications (2026) and MITRE ATLAS.
• The real agent, on staging - it invokes the agent through a profile you add, such as an HTTP endpoint or a command. It does not sandbox the agent or undo its writes, which is why runs belong on staging.
• Criteria graded on evidence - each acceptance criterion is checked against files changed, artifacts produced, tool calls compared with the agent's declared tools, and read-only checks through a tool you approve, as far as the access and profile you give it allow. Model judges score some criteria, but an action the agent only claims is never taken as proof.
• Verdicts and run-over-run changes - each criterion gets a single verdict of Pass, Fail or Unable to Verify, with a count of its own kept for the unverifiable ones; a second run shows which scenarios newly fail and which were fixed.

For a release gate, the Agent Assurance CI/CD docs call a zero exit code "not an agent-quality gate", and the Rook CLI README explains why: a run that finishes exits 0 even when some scenarios fail. Gate on the JSON from rook run --json, which carries ok, run_id, halted and, when available, the report totals; the docs' sample gate script fails closed when a required total is missing.

Run unmodified against four hand-made result files on 17 October 2026 (Node.js 25.5.0; sample data, not a rook run), that script passed only the complete suite:

rook-run.json      passed failed unverifiable  gate
all-passed              3      0            0  exit 0
one-failed              2      1            0  exit 1
one-unverifiable        2      0            1  exit 1
totals-missing          -      -            -  exit 1

In the docs, the GitHub Actions, Jenkins and Argo CD examples use a strict gate that blocks on Unable to Verify without relabeling it as Fail. None is an automatic pull-request check: the GitHub Actions workflow is triggered manually, the Jenkins job runs on a reviewed branch and the Argo CD job runs after a sync.

The docs list its pre-alpha limits: commands and stored file formats can change; native file, image and pull-request attachment delivery is not implemented yet; and it records image dimensions but cannot judge image pixels. It does not watch production traffic or block anything at runtime, and whether an agent meets a regulation stays a decision for your compliance team and auditors.

For a first read on one attack surface before a suite exists, the Agent Red-Team Scan sends prompt injection, jailbreak and PII-leak probes to an LLM API you name and scores how it held up. It tests the model endpoint, not the actions an agent takes.

If the agent talks to people instead of acting on systems, Agent Testing is the TestMu AI product for it, with simulated personas across chat, voice, phone, video and image agents.

Conclusion

Pick one agent that changes real state, such as a refund, ticket-routing or code-change agent, and write five acceptance criteria for it, two of them adversarial. Check them in a staging run and count how many the run could verify from the systems the agent touched; read beside the pass rate, that count shows how much of the agent's behavior your evidence covers today.

Once the suite is stable, run it with Agent Assurance as a release gate on the report's verdict totals; the setup is in Run Agent Assurance in CI/CD.