Agentic AI Needs More Than Oversight. It Needs Verifiable Boundaries.

In September 2026, researchers Rick Hennessy and Carolyn Ashurst published Behavioural Assurance of Agentic AI for Sensitive and High-Stakes Organisations through the Centre for Emerging Technology and Security (CETaS) at The Alan Turing Institute.

The paper identifies eight behavioural failure modes in agentic AI, including goal displacement, misreporting, policy-invisible violations, pseudo-corroboration, and failures emerging from interactions between multiple agents and humans.

Its central message is important: evaluating an AI agent's final output is not enough. Organisations also need to understand how the agent behaved while producing it.

That distinction is becoming increasingly important as AI agents move from answering questions to executing tasks, accessing systems, modifying software, and collaborating with other agents.

But it raises a practical question: how can an organisation establish that an autonomous agent acted within its authorised boundaries — rather than simply trusting the agent's account of what happened?

A reviewer is not the same as a verifier

Imagine two AI agents working together. Agent A develops a software change. Agent B reviews it and reports that the change is acceptable.

This is useful. It can improve quality and catch mistakes. But what does Agent B's approval actually establish?

Did both agents review the same version of the files? Were the acceptance criteria unchanged? Did the developer operate within its assigned mandate? Were any required checks skipped? And could both agents have relied on the same incorrect assumption?

The CETaS paper describes one important failure mode as pseudo-corroboration: multiple AI systems appearing to independently confirm a conclusion when their agreement reflects shared assumptions or correlated errors.

Adding a second model does not automatically create independent assurance.

The missing boundary between intention and action

An organisation might instruct an agent to update a service, investigate an incident, or prepare a compliance assessment.

The instruction expresses an intention. The agent's output expresses a claimed result. Between those two points lies a sequence of actions, decisions, tool calls, dependencies, permissions, and potentially changing circumstances.

This is where governance becomes difficult. An agent can produce a technically correct output after taking an unauthorised action. It can follow visible instructions while missing a policy that was not available in its context. It can report success even when an important verification step was never completed.

The CETaS research makes these risks explicit.

We believe this points toward a necessary architectural separation:

1. 01AI agents perform work.
2. 02A separate verification layer evaluates the evidence and applicable authority boundaries.
3. 03The execution environment enforces the resulting permissions and restrictions.

These are distinct responsibilities.

Building EVE: verification rather than self-certification

EVE — Evidence Verification Engine — is our work toward this separation.

Its objective is not to replace AI agents, decide what they should think, or become another general-purpose orchestration framework. Instead, EVE is designed to make consequential agent activity attributable, bounded, and verifiable.

Our architecture separates several questions.

These are not interchangeable checks. An authorised start does not prove compliant execution. A successful output does not establish that every intermediate action was permitted. And an intact cryptographic record does not establish that the underlying business decision was correct.

EVE is designed to preserve these distinctions.

What we have demonstrated

We have used OpenClaw- and Hermes-based agents in owner-approved, budget- and time-bounded development and review runs. In these runs EVE's verified-handoff check ran inside the execution chain: before each receiving agent was started, it checked the handoff package against its recorded identity and scope and admitted it only once. These runs were tested by the team that built them and have not been independently verified.

We have demonstrated owner-signed work periods, recorded reviewer decisions and handoffs linked to their evidence, with outcomes marked CHAIN_VERIFIED by our chain verifier. CHAIN_VERIFIED means the recorded chain of handoffs and evidence is complete and consistent within that verifier's defined checks; it is not a statement that the delivered code is correct, and it has not been independently verified.

We have also encountered real engineering limitations:

• A reviewer's rejection does not depend on pinpointing every defect. In our runs a rejection could rest on an unmet acceptance criterion, such as a failing server build. In one recorded run the reviewer rejected correctly but repeated an imprecise defect location from the developer's own notes, so we do not claim the reviewer found the defect on its own.
• If an agent run is interrupted, its cost may not be recorded reliably. We found this by code analysis rather than from a production incident. Our design treats any unrecorded cost as unknown and stops further runs until a person has reviewed it; a stricter turn-level journal has been tested in isolation and is under qualification. Cost figures from agent frameworks are estimates, not provider invoices.
• We do not treat the exit of a command-line client as evidence that an agent's work has stopped. Source-code analysis and isolated tests of the agent runtime we use showed that a separate gateway process can continue a turn after its client has returned, so end-of-work must be established at an execution boundary the platform controls.

We design agent execution on least privilege and credential isolation: an agent's tools should reach only the credentials and services its task requires, and a credential should never be readable from an agent's own working environment.

These observations reinforce a central lesson: a verified handoff is not the same as verified execution isolation, and neither is equivalent to proof that an AI-generated conclusion is true.

Our DURING v1 baseline defines contracts for conditions that must keep holding while an action runs, records observations pulled from declared sources, assesses whether each condition still holds, and links directives, acknowledgements and outcomes. It does not execute, stop or terminate agent actions; enforcement remains the responsibility of the surrounding execution environment. It is covered by its own test suite and has not yet been used in our agent runs.

Our automated correction loop — in which failing machine-test results are fed back to the same agent for a small, fixed number of retries within its approved mandate — and the related execution hardening have been built and tested in isolation. They are under qualification and are not treated as production-proven capabilities.

That distinction matters. A credible verification system must be equally capable of reporting what is not established.

Behavioural assurance needs technical evidence

The CETaS paper argues that organisations should assess deployed agent behaviour, not models in isolation. We agree. But behavioural assurance becomes more operationally useful when its findings can be linked to reproducible evidence.

For example, organisations should be able to establish:

• Which mandate authorised a specific action.
• Which inputs, evidence and policy versions were in scope.
• Which agent produced an output and which agent reviewed it.
• Whether the reviewer examined the exact submitted artefacts.
• Which deterministic checks passed, failed or were not performed.
• Whether an observed deviation required escalation.
• Whether an authorised human made the consequential decision.
• Whether the resulting evidence record has remained intact.

These questions cannot all be answered reliably by asking the agent to describe its own behaviour. They require controls and evidence outside the agent's own narrative.

The next step is verifiable autonomy

The emerging challenge is not merely to build agents that can complete longer tasks. It is to enable agents to work together while preserving meaningful human authority, reliable evidence, and enforceable execution boundaries.

Behavioural research helps identify what can go wrong. Engineering must establish what can actually be checked.

The objective of EVE is to connect these concerns: allowing agents to collaborate and adapt while making the limits of their authority, the evidence supporting their actions, and the history of their decisions independently inspectable.

This is still an evolving engineering challenge. Not every proposed boundary has been fully qualified, and independent assurance requires more than a second agent agreeing with the first.

But the direction is clear: the future of agentic AI should not depend on trusting agents to certify their own behaviour. It should depend on systems that make the relevant claims verifiable.