AI Agent Assurance: The Missing Layer in the Enterprise Agent Stack

Agents Stopped Talking and Started Doing

For the first two years of generative AI, the risk was mostly a risk of words. A model said something wrong, made something up or said something it shouldn't. Embarrassing, sometimes expensive, usually fixable.

Agents changed the unit of risk. An agent holds credentials. It calls tools.

It writes to databases, sends emails, files tickets, merges code and moves money. When it gets something wrong, the result is not a bad sentence. It is a changed system.

A wrong answer is a support ticket. A wrong action is an incident.

Enterprises are already there.

In a theCUBE Research study published on 26 October, 19 of 25 enterprise technology and security leaders said they had agents in production. Only four of the 25 had tested or exercised an AI or agent incident scenario. Nine of the 25 were confident, or even partly confident, that they could reconstruct what an agent did across their systems.

And the question of who answers for the agent is being settled in public. On JPMorganChase's third-quarter earnings call, CFO Jeremy Barnum said of customers who hand their banking credentials to an agent: "if they give up their credentials to the agent and the agent does something that they don't want, that's going to be on them."

Put that in enterprise terms and it is simple. Whoever deploys the agent owns what the agent does.

We Built a Stack for Agents. It Answers Every Question but One.

The agent ecosystem has grown up fast, and most of it is good engineering. Look at the question each layer answers:

• Models answer can it? They set how capable the agent is.
• Frameworks and harnesses answer how does it run? Prompts, tools, memory, retries.
• Identity and permissions answer may it? Which systems, which scopes, which data.
• Guardrails and runtime security answer should this be stopped? They block known-bad actions as they happen.
• Observability and evals answer what happened in the run? Traces, scores, dashboards.

You need all of these, and I'm not arguing against any of them.

But line them up and one question has no owner: did the agent do the right thing, and can you prove it before you trust it?

Permission tells you an action was allowed. It doesn't tell you it was right.

A guardrail tells you nothing on its list got through. It doesn't tell you the refund went to the right order.

A trace shows you what the agent attempted. It doesn't show you the state of the system afterwards. And a harness, as I wrote recently on agent harness testing, runs, constrains and logs an agent, but it never inspects the end state.

That unanswered question is the assurance layer. In most agent stacks I see, nobody owns it.

The Agent Can't Be Its Own Witness

The default answer to "did it do the right thing?" is to ask the agent. Read its final message. Read its reasoning. Read its summary of the run. Ask it to check its own work.

Every one of those is the agent's account of what it did. And an agent's account of what it did is the weakest evidence available about what it did.

This isn't a fringe view any more. It is what the people closest to these systems are now saying, in their own words:

• Arena's Alignment Index, built on 90,000 real agent sessions, found that on average one session in ten included a task reported as done when it wasn't. For most models, a large share of those were "verification overclaims, where the model says it checked its work when it didn't."
• Anthropic, after investigating its own models: a model's own account of its reasoning "is not necessarily reliable evidence of its beliefs or reasons for action."
• Cohere, to security teams: "A reasoning trace is not a security boundary."
• India's CERT-In, in a Critical advisory on 15 October, to AI labs and evaluators: "Do not rely on after-the-fact transcript review alone."
• Satya Nadella, writing in October: "Validation must be independent of the intelligence being validated."

A leaderboard, two model labs, a national cyber agency and the CEO of Microsoft, each from a different seat. They land in the same place.

The agent's account is not the evidence. What the agent did is.

What an Assurance Layer Has to Do

If assurance is the missing layer, the next question is what counts as one. A dashboard isn't assurance. Neither is a pass rate on its own.

Here is the bar I would hold any assurance layer to, ours included.

1. It is independent of the agent. The agent doesn't grade itself, and the team that built the happy path doesn't write all the tests. Validation sits outside the thing being validated.

2. It checks effects, not accounts. It grades what the agent did: the call it made, the record it wrote, the message it sent. What the agent said is one input. It is never the verdict.

3. It is honest about what it couldn't see. If an action wasn't observed, the result is not a pass. "Unable to verify" is a verdict of its own, and it should be reported as clearly as a failure. A green dashboard that counts unchecked work as passed is worse than no dashboard, because it tells you to stop looking.

4. It attacks the agent before anyone else does. Agents read emails, web pages, tickets and tool descriptions written by strangers. Prompt injection, poisoned tools, confused-deputy requests and goal redirection belong in the test suite by default, not in a red-team engagement once a year.

5. It writes the scenarios. Nobody hand-writes enough tests to cover what an agent can do. An assurance layer has to read what the agent is meant to do and generate the cases, including the ones its builders didn't think of.

6. It runs on every release. A model swap is a release. So is a prompt change, a new tool or a new retry policy. Assurance that runs once before launch is a snapshot. It has to sit in the pipeline and gate every change.

If you take one thing from this piece, take this question. Put it to every tool that says it assures your agents, ours included: when you can't verify something, what do you call it?

If the answer is "passed", or there is no answer, that isn't assurance.

Why We Built Rook

At TestMu AI we built Agent Assurance, and its engine Rook, to clear that bar. It started from one rule that everything else is built around: Rook never claims what it didn't verify.

Point Rook at your agent's docs and its endpoint. Add the code if you're comfortable sharing it, because that is how Rook can explain root causes and suggest fixes. From there, Rook:

• Works out what your agent is meant to do and writes the scenarios: happy paths, negative cases, boundaries, integrations and adversarial cases.
• Attacks it by default. Adversarial testing is on unless you turn it off. Its red-team catalogue covers 25 attack patterns mapped to the OWASP Top 10 for LLM Applications and the OWASP Top 10 for Agentic Applications, with MITRE ATLAS mappings where they apply.
• Runs your agent for real. Rook calls the endpoint you give it, so point it at staging and it exercises the real thing, not a mock.
• Grades what the agent said and what it did. Actions are captured through hooks you configure on the systems your agent touches. Each criterion shows what was expected, what was achieved and the evidence for it.
• Gives three verdicts: Pass, Fail and Unable to Verify. Unable to Verify is never counted as a pass. It is listed separately, with what you would need to close it.
• Runs in your pipeline, so every model swap, prompt change and new tool is tested before it ships.

Keep your guardrails, and keep your observability. They watch the agent in production, and you need both. Rook is the layer the rest of the stack quietly assumes someone else has built: the proof, before release, that the agent does what you are about to trust it to do.

The Question That Comes Next

Most enterprises are past the question of whether to use agents. The next question will come from boards, auditors, regulators and customers, and it is simpler and harder: can you prove what your agents did?

The agent's own account won't answer it. A trace won't answer it on its own. What answers it is evidence, collected by something other than the agent, before the agent touched anything that matters.

No evidence, no pass.

Shipping agents that other agents use? Rook by TestMu AI does Agent Assurance: agents testing agents before release, with no human in the loop.

To run your first test, install Agent Assurance with npm install -g @testmuai/rook@latest command, or

book a demo

for a full walkthrough of the product.

Sources

• OpenAI, "Suppressing misalignment monitoring alerts and disabling misalignment monitoring" (updated 20 Oct 2026)
• Anthropic, "Investigating unintended model actions in our evaluations and internal use" (9 Oct 2026)
• Cohere, "Concerning behavior from a popular open-weight AI model" (26 Oct 2026); raw trace
• theCUBE Research, "AI Resilience: Organizations Are Underprepared and Largely Untested" (26 Oct 2026)
• JPMorganChase, 3Q26 earnings call transcript (13 Oct 2026), p.10
• Arena, "AI Alignment Index" (8 Oct 2026)
• CERT-In, Advisory CIAD-2026-0049, "AI Agents as Attack Vectors" (15 Oct 2026), recommendation A4
• Satya Nadella, "Models as Insider Risks in the Super Intelligence Era" (10 Oct 2026)
• Vipul Verma, "Agent Harness Testing: What a Harness Can't Verify About Itself", TestMu AI blog (1 Nov 2026)