How is agent assurance different from AI safety?

AI safety mostly concerns the model: preventing harmful, biased, or dangerous outputs in general. Agent assurance concerns a specific deployment: whether this agent's work met the brief and whether this action complies with this business's commercial policy. A perfectly safe model can still promise a refund it has no authority to give.

Does assurance replace human review?

No. It routes it. Most actions are clean and ship instantly. Actions that exceed authority come back as require_approval, so humans review the 2% that matters instead of sampling the 98% that does not.

Why does the assurance layer need to be independent?

A vendor grading its own agent has an incentive problem, and an agent checking itself shares the same blind spots and the same prompt. Independence is what makes the verdict usable as evidence with customers, auditors, and courts.

What does assurance cost per action?

Deterministic policy checks (discount caps, spend authority, required disclaimers) cost effectively nothing and run in milliseconds. Semantic checks add one model call, typically one to two seconds. EvalLayer prices authorization from $0.01 per check.

What is AI agent assurance?

Published 2026-07-27 · EvalLayer

AI agent assurance is the independent layer that verifies an AI agent's work after it is done and authorizes the agent's consequential actions before they happen. It answers two questions no agent should answer about itself: was this work actually good, and should this action actually ship? The verdicts it produces (pass or fail, allow or block) come with reasons, and every decision is stored as an audit record the business can stand behind.

Why agent assurance exists

AI agents stopped being chat interfaces. They quote prices, reply to customers, issue refunds, book work, publish content, and negotiate terms. Every one of those actions can bind the business that deployed the agent. The legal direction of travel is unambiguous: when Air Canada's chatbot invented a refund policy, a tribunal held the airline liable and rejected the argument that the bot was a separate entity. The company eats what the bot promises.

Meanwhile the failure modes have moved from embarrassing to expensive: support bots inventing licensing policies, a customer talking an after-hours chatbot into an 80% discount on an 8,000 GBP order, agents committing to delivery dates nobody approved. A 2026 Gravitee survey found 82% of US companies had seen an AI agent go rogue in the previous 12 months. The pattern in every case is the same: the action shipped first and the humans found out later.

The three layers everyone conflates

"Guardrails" gets used for three different jobs, and the confusion is where incidents live:

Model safety keeps outputs non-harmful in general: no toxicity, no jailbreaks, no leaking system prompts. It ships with the model or sits beside it.
Identity and access control decides what an agent is allowed to touch: which tools, which APIs, which data, with which credentials. This is where most security vendors operate.
Action assurance decides whether the specific thing the agent is about to do complies with the business's commercial policy: the discount is inside authority, the commitment is one the company can honor, the claim is approved, the disclaimer is present.

A deployment can pass the first two layers perfectly and still fail the third. The agent was allowed to send email (access control), the email contained nothing harmful (model safety), and the email guaranteed a go-live date the company cannot hit (commercial catastrophe). Access control decides if the agent can act. Assurance decides whether this action should ship. The distinction is developed further in guardrails vs authorization.

The industry is converging on the same conclusion. The Cloud Security Alliance now maintains an open specification for exactly this layer, Autonomous Action Runtime Management (AARM), which frames runtime action security in terms of context, policy, intent, and behavior. And a March 2026 study of deployed agents, aptly titled Before the Tool Call, found there is still no standard authorization layer at the tool-call boundary: 27.2% of engineering teams surveyed had abandoned framework-provided controls and hardcoded their own checks instead.

What an assurance layer does

1. Evaluation: judge completed work

Post-hoc evaluation takes a finished deliverable (research, code, content, an answer) and returns a structured verdict: extracted claims, evidence support, a quality score, and a pass or fail with rationale. This is how buyers of agent work verify they got what they paid for, and how agent marketplaces settle payment disputes without a human referee.

2. Authorization: gate consequential actions

Pre-action authorization intercepts the agent's intended output before it reaches the world. The action plus a policy go in; one of four decisions comes out: allow, rewrite (a compliant version is returned), require_approval (a human signs off), or block. The mechanics are covered in depth in the authorization guide.

3. Audit: keep evidence

Every verdict and every authorization is stored with the content hash, the policy that was applied, the violations found, and the decision. When a customer disputes what the agent said, or a regulator asks what controls existed, the answer is a record, not a shrug.

4. Reputation: make trust portable

Verdicts accumulate. An agent that consistently passes evaluation earns a track record that travels with it across platforms and counterparties, which is the raw material for agent-to-agent commerce that does not require blind trust.

How pre-action authorization works

The policy is the contract. A commercial policy is small and concrete: maximum discount percentage, spend authority in dollars, forbidden commitment types (delivery guarantees, indemnification, refund promises), approved claims the agent may assert, required disclaimers, blocked topics.

Checking splits into two stages for a reason. Anything countable (money, percentages, required text) is checked deterministically: exact, instant, and immune to model moods. Anything semantic (is this sentence a delivery guarantee?) gets one model pass with the policy in context. Violations carry severity, and severity drives the decision ladder: hard violations block, authority violations require approval, soft violations trigger a rewrite that is itself re-checked before it is offered.

You can watch this happen in about 90 seconds: the live demo runs a quote email with three planted violations against a sample policy and returns the decision card.

Who needs it, and when

Teams deploying agents that touch pricing, refunds, commitments, or public statements. The moment an agent can create an obligation, assurance is the difference between a control and a hope.
Agent vendors whose enterprise deals stall on the question "what stops it from promising something we cannot deliver?" An independent authorization layer is a better answer than "our system prompt."
Agent platforms and marketplaces that need disputes settled and quality enforced without humans in every loop.

The honest sequencing: you need evaluation as soon as you pay for agent work, and you need authorization the day an agent gets commercial authority. Most teams discover both requirements from their first incident. The cheaper path is reading about other people's incidents instead.