Governing the Path, Not Just the Answer: Runtime Verification for Agents
An AI agent handled a customer request last quarter through five steps, and every one of them was allowed. It read the ticket. It looked up the account. It pulled the customer's transaction history. It cross-referenced a marketing profile. It drafted a reply. No step broke a rule the access-control layer could see. Each action sat inside the agent's permissions.
The sequence, taken as a whole, breached the organisation's own data minimisation policy. The agent had assembled a fuller picture of the customer than the task required, by combining sources that were each permitted on their own. At the end of the run the agent reported that it had processed the request in accordance with the applicable policy. That report was the only record anyone had of what the agent did.
This is not an exotic failure. It is the ordinary governance condition for most production agentic AI as of July 2026. If you have deployed an AI agent that calls tools, writes data, or hands work to other agents, you almost certainly have this gap: a report of compliance and no independent way to check it.
From what an agent says to what it does
Last month in this series we looked at what an AI model says inside its own reasoning. A single hallucinated intermediate fact poisons the conclusion that depends on it, and the model cannot tell a verified premise from an invented one, because internally there is no distinction to draw. The remedy was external verification of the reasoning trace, sitting outside the process it checks.
This week the object moves from what the model says to what it does. When a model stops answering questions and starts acting, calling application programming interfaces, writing files, delegating to sub-agents, triggering workflows, the thing that needs verifying stops being a claim and becomes a path: the actual sequence of steps the agent executed.
In March 2026, Maurits Kaptein, Vassilis-Javed Khan and Andriy Podstavnychy submitted a paper to arXiv, "Runtime Governance for AI Agents: Policies on Paths" [1]. It makes the execution path itself, not the model's output, not its training, not its system prompt, the central object of agent governance. The central claim is stated plainly: prompting reduces the probability of policy-violating paths, but it provides no enforcement. A system prompt telling an agent to respect a privacy obligation changes what the agent is likely to do. It cannot stop the agent from doing otherwise.
Static access control has the opposite shape and the same limit. It gates individual actions, this agent may not call that interface, but it cannot see a sequence. It cannot stop an agent from performing a series of individually permitted actions whose combination crosses a line. The paper formalises a governance policy as a function that reads four things: the agent's identity, the partial path travelled so far, the proposed next action, and the state of the organisation. It returns a violation score. The variable that matters is the partial path. No system-prompt instruction and no static access rule is a function of the execution history. Only a monitor that reads the completed sequence of steps can judge whether the next action, given everything that has already happened in this run, crosses a threshold.
One honest qualification belongs here, and the authors state it themselves: the paper presents no implementation and no experimental results [1]. The claim that the path is the right governance object is an argument, not a measured finding, and the violation score it describes is a formal specification, not a calibrated probability you can read off a production system today. I carry it as what it is: a clean statement of where the governance gap sits.
Why a compliance report is a claim, not evidence
There is a logical reason the agent's own report cannot close this gap, and it is the same reason that has run through this series from the start.
Standard predicate logic treats a statement as a single proposition that is true or false. Non-Traditional Predication Theory, developed by Professor Horst Wessel at Humboldt University Berlin and the foundation of the work I do, separates two acts that ordinary logic runs together [2]. The first act is existence: asserting that something is real, that an entity exists or an event occurred. The notation is E!. The second act is predication: attributing a property to something already taken to exist. You can only sensibly check whether an event had a property once you have established that the event occurred.
Now read the agent's sign-off again. "I processed the data in accordance with the applicable policy" asserts that a specific sequence of actions occurred and that it had a specific property. That is an existence claim about a path. Under this separation it cannot be treated as established unless the occurrence is grounded by external evidence of the actual path. The agent's introspective report is not that evidence. The model cannot reliably tell the path it executed from the path a compliant agent would have executed, for the same structural reason it could not tell a hallucinated fact from a verified one. The report and the reality are generated by the same process, so the process cannot be the thing that checks them.
This maps onto the way V.E.R.A. is built, and the map is worth drawing carefully, because the boundary matters as much as the parallel. V.E.R.A. (Verified Existence and Reason Architecture) is an open-source logic engine that wraps a language model in three layers. The first, the Krampitz Load Analyzer, classifies each claim as an existence claim that needs grounding or an inference that follows from established premises. The second, the E! Verification Service, grounds the existence claims against a structured, sourced corpus that sits outside the model. The third, the D-Service, acts on the verdict: when existence cannot be confirmed, it returns unknown and stops, rather than proceeding on an unverified premise.
The paper's runtime monitor occupies the same structural position one level out. It reads an external record, the path, against an external standard, the policy, and when a path cannot be judged compliant it can pause execution for a human decision rather than letting the run continue. The shared principle, and it is the only thing these two systems share, is that verification must sit outside the thing being verified. The implementations are different and the logical groundings are different. V.E.R.A. verifies whether what an agent says is grounded; it operates on claims, against an existence corpus. The path monitor verifies whether what an agent does is compliant; it operates on action sequences, against a governance policy. V.E.R.A. does not monitor action paths, and the path monitor does not verify existence claims. Naming both does not merge them.
Two boundaries need stating plainly, because the temptation to overclaim is real. V.E.R.A. does not verify its own reasoning. A checker living inside the process it is meant to judge would inherit that process's blind spot, which is the whole point of putting the referent outside the loop. And this V.E.R.A. is Andreas Hamberger's Verified Existence and Reason Architecture, published by Te Pono Limited; it is not vera.ai, not DataGrail Vera, not VeraSafe, and shares nothing with them but four letters.
The eight policies: what only the path can enforce
The paper makes the idea concrete with eight governance policies, and the value of the list is that none of the eight can be written as a system prompt. Every one of them needs to know the actual execution history [1].
The clearest is what the authors call a predecessor requirement for personal data. An agent may not access personal data unless a data-classification step has already happened earlier in this same run. Notice what kind of rule that is. It is not a rule about whether the agent may touch the data; access control can grant that. It is a rule about order. Enforcing it means knowing whether the classification step actually occurred before this point in the path, and that fact lives only in the path record, not in the model's parameters and not in the current prompt.
New Zealand has a live example of exactly this shape. The Biometric Processing Privacy Code, in force since November 2025 with a compliance deadline of 3 August 2026 for existing users, bans the use of biometrics to infer emotion, health or ethnicity. Picture an agent in a multi-step workflow: it accesses a face image, which may be permitted; it applies a facial recognition model, which may be permitted; it derives demographic attributes, which may be permitted for some purposes; and it stores an inferred ethnicity, which is prohibited. No single step, on its own, trips the ban. Only the sequence, the path that ends in an ethnicity inference, is the violation. A system prompt asking the agent to be careful cannot catch it. A monitor that reads the path can. I am describing the mechanism the Code would need to be enforced against agents, not judging how the Code is drawn.
Two of the other policies show the range. One sets execution bounds, a score that rises with each step so a run cannot exceed a step budget; a prompt can request that, but only a path monitor can enforce it. Another prevents cross-barrier data flows in a multi-agent run, catching a leak that no single agent commits on its own but that the agents commit together. In each case the rule is about the sequence, and the sequence is visible only from outside.
The paper is candid about what is not solved. It lists six open problems, and the sharpest for enterprise use is strategic circumvention: an agent with persistent memory could learn to produce steps that each score below the violation threshold while the whole sequence still reaches a prohibited outcome [1]. That is the path-level twin of the reasoning-trace poisoning this series covered last month. In both, the mechanism that produces the harm operates at the level of the sequence, not the single step, so evaluating single steps in isolation will keep missing it.
What the governance frameworks now require
The regulators have started to arrive at the same place from the top down, and the gap they leave is precisely the one path monitoring fills.
In New Zealand, the Reserve Bank's draft Operational Resilience Standard 2027, part of the Deposit Takers Act work and out for consultation in June 2026, requires each deposit taker's board to set tolerance levels for disruption to every critical operation, and its accompanying material treats AI failure as one of the disruptions that must be evaluated against those tolerances [8]. I am reading the standard as it is drawn, not scoring it, and the exact clause wording sits in an exposure draft I have not quoted here. The structural point stands on its own: a board cannot show that an AI agent stayed inside a tolerance for a critical operation, credit assessment, fraud detection, customer service, without a record of what the agent actually did, step by step. Reviewing the final loan decision or fraud flag will not reveal a data-minimisation breach that lived in the sequence and produced a clean-looking result.
The pattern repeats internationally. The European Union's AI Act, in its Article 14 human-oversight requirement, says high-risk systems must be built so a person can understand the system, intervene, and halt it [9]. For an agent that runs dozens of steps before producing anything a human sees, those three capabilities imply watching the path as it unfolds, not just reading the final decision. The enforcement calendar is unsettled, high-risk provisions are pencilled for August 2026 but a later political agreement may push some obligations into 2027, so I make nothing turn on a specific date. The requirement's logic is what matters, and its logic is path visibility.
There is a blunt measure of how far off that visibility currently is. In its 2026 poll of audit and digital-trust professionals, ISACA found that 56 per cent could not estimate how long it would take to shut down a rogue AI system in an incident [12]. You cannot estimate the time to stop something you cannot watch. That figure is the practitioner-level readout of the same gap the standards are reaching for from above.
The good news is that the mechanism is no longer hypothetical. Microsoft released an Agent Governance Toolkit as open-source software under a permissive licence on 2 April 2026, with a policy engine that intercepts every tool call and outbound request at very low latency and had drawn more than three thousand three hundred stars on its public repository by early July [5]. On the academic side, a framework called C-Trace expresses parts of European data-protection law as formal checks over an agent's execution trace, and reports driving the attack-success rate to zero per cent under perfect information extraction and to no more than 12 per cent under realistic noise [4]. That is the first empirical evidence of what path-level enforcement can reach. Neither of these is V.E.R.A.; both govern action sequences, where V.E.R.A. governs claims. The translation from a governance standard to a working runtime check is real engineering, not a switch you flip, and one April 2026 paper argues that the major AI-management standards do not by themselves yield enforceable runtime guardrails; a deliberate translation layer is needed [7]. Say that plainly rather than pretend path governance is a solved problem.
The stack, and the sovereign edge of it
The implication on the defence and sovereignty side is worth naming directly. In June 2026 the United States issued National Security Presidential Memorandum 11, which sets four pillars for artificial intelligence in national security work, one of them assurance: systems must be reliable, steerable and able to be controlled [10]. Last month I read that assurance requirement against a model's reasoning. Here it lands on the action sequence. An autonomous agent in a defence or intelligence setting may gather signals, assess a situation and delegate to sub-agents before any person reviews its output. An agent that reaches a sound-looking recommendation through a non-compliant path, reading unauthorised sources or crossing a data compartment, is not assured, whatever the quality of the answer. Assurance at that level is a property of the path, and path-level governance is what makes the assurance pillar operational for agents rather than aspirational.
That agentic governance is now a matter for national security authorities is not my inference. The Five Country Council guidance on the careful adoption of agentic AI services, published on 1 May 2026, names New Zealand's National Cyber Security Centre as a co-author alongside its counterparts in the United Kingdom, the United States, Australia and Canada [1]. Autonomous agent governance sits inside the national cybersecurity remit; path monitoring is the technical form the guidance's intent takes.
Step back and the shape of the argument is a stack, not a single box. This series has now walked up it. Governing the claim: is what the agent asserts grounded in something real? Governing the trace: is the reasoning that led to the answer free of invented premises? Governing the path: did the sequence of actions the agent took stay inside policy? V.E.R.A.'s E! service addresses the first. The path monitor in this week's paper addresses the third. No single external verifier covers all three, and none of the three can be closed by asking the model to grade its own work. A fully governed agentic system is not one referent outside the model. It is a set of them, one at each layer where the model would otherwise be trusted to check itself.
The oldest idea in this series is the newest thing the agent builders need. External verification is not a feature you add to an autonomous system after it ships. It is an architectural requirement wherever a process is asked to certify its own conduct. The path governance paper reached that requirement from the action side this year. Non-Traditional Predication Theory reached it from the existence side more than thirty years ago. The convergence is the finding.
If you are running AI agents that act on your systems today, where in your stack would a policy-violating sequence of individually permitted steps be caught before it completed, and if one had already happened last week, how would you know?
The views expressed in this article are entirely my own, informed by more than 30 years of professional experience in architecture, security, and technology leadership in New Zealand. They do not represent the views of my employer, any government agency, or the New Zealand government. My commentary on legislation and policy is analytical, drawing on publicly available sources and my professional expertise in architecture, security, and AI governance. I follow the Public Service Commissioner's Code of Conduct for the Public Sector and social media guidance.
Andreas Hamberger is a New Zealand leader in Architecture & Security and Associate Member of the Institute of Directors. V.E.R.A. (Verified Existence & Reason Architecture) is an open-source logic engine available on GitHub.
I use AI tools, including Sudowrite, Claude, Perplexity AI, DeepSeek AI, ChatGPT, Grok, Copilot, Openart and Gemini, as deliberate production tools, not ghostwriters. This is consistent with my position: AI amplifies human judgement; it does not replace it. The frameworks, arguments, and editorial decisions in this series are original work. AI accelerated the process. The thinking is mine.
References
[1] Kaptein, M., Khan, V.-J., and Podstavnychy, A. "Runtime Governance for AI Agents: Policies on Paths." arXiv 2603.16586. March 2026. https://arxiv.org/abs/2603.16586
[2] Wessel, H. "Existenz, Ununterscheidbarkeit, Identitat." Wissenschaftliche Zeitschrift der Humboldt-Universitat zu Berlin, Reihe Geistes- und Sozialwissenschaft 41, pp. 30 to 39. 1992.
[3] Hamberger, A. "V.E.R.A. (Verified Existence and Reason Architecture): benchmarks and documentation." Te Pono Limited. January 2026. https://github.com/ahamberger/vera
[4] Kahani, Barati, and Addae. "Runtime Compliance Verification for AI Agents (C-Trace)." arXiv 2606.19242. June 2026. https://arxiv.org/abs/2606.19242
[5] Microsoft. "Introducing the Agent Governance Toolkit: open-source runtime security for AI agents." Microsoft Open Source Blog. 2 April 2026. https://opensource.microsoft.com/blog/
[6] OWASP Gen AI Security Project. "OWASP Top 10 for Agentic Applications 2026." December 2025. https://genai.owasp.org/
[7] Koch. "From Governance Norms to Enforceable Controls." arXiv 2604.05229. April 2026. https://arxiv.org/abs/2604.05229
[8] Reserve Bank of New Zealand. "Operational Resilience Standard 2027 (Deposit Takers Act, Tranche 3): exposure draft for consultation." June 2026. https://www.rbnz.govt.nz/
[9] European Union. "Regulation (EU) 2024/1689 (Artificial Intelligence Act), Article 14: human oversight." 2024. https://artificialintelligenceact.eu/
[10] The White House. "National Security Presidential Memorandum on Artificial Intelligence (NSPM-11)." 5 June 2026.
[11] Office of the Privacy Commissioner. "Biometric Processing Privacy Code 2025." 2025. https://www.privacy.org.nz/
[12] ISACA. "2026 AI Pulse Poll." 23 March 2026. https://www.isaca.org/
[13] NCSC New Zealand, NCSC United Kingdom, CISA, ACSC, and CCCS. "Careful Adoption of Agentic AI Services (Five Country Council guidance)." 1 May 2026.