Agentic AI governance and the limits of execution proof

The useful question about an autonomous agent is not how it reasons.

It is what it was allowed to do, and what was written down at the moment it was allowed.

Where agentic governance actually happens

Most of an agent programme sits either side of the agent running. Before: which use cases are permitted, which model, which evaluations, which red-team exercise, who signed it off. After: monitoring, incident review, sampling, periodic audit. Both halves are real work and a serious programme needs both.

The part that is hard to evidence is the thin slice in between. An agent proposes an action — a database query, a file write, an outbound API call, a payment. Between the proposal and the side effect there is a boundary, and at that boundary four things have to be true at the same time: the action as proposed, the policy in force, the verdict, and the party the system holds responsible.

Miss that moment and you are reconstructing it later out of logs built to describe system behaviour rather than governance. That reconstruction can be perfectly convincing. What it cannot be is something the person asking can check without trusting whoever assembled it — and not having to take that on trust is usually why they are asking.

That slice is where MeshQu operates: an execution-proof layer within AI governance.

Three experiments, and the thing they keep showing

We have run the same setup three times over public UK procurement filings — an agent reading the records, a policy engine reading the same records, every verdict bound into a signed receipt.

• The agent almost never said no. Across 283 unique decisions the policy engine returned 144 allows and 139 denials; the agent returned 7 allows, 276 reviews and no denial at all. Rewording a single over-strict rule lifted agreement roughly elevenfold — a finding about policy authoring, not agent capability. (When AI hedges and policy commits · the plain-language version)
• More governance context did not steadily help. Adding context one rung at a time held the agent between 97.5% and 100% review for three rungs. Then it committed 107 denials — 37.8% — in a single step when it was shown past decisions on similar records, and backed 46 of those off again once it saw the full policy text. (When precedents commit AI and policy pulls it back · the plain-language version)
• Reasoning travelled between models; verdicts did not. Two models from different vendors read the same records the same way — the same reasoning pattern dominating at 93% and 100% — and committed to a verdict on 23% and 80% of records respectively. (Precedents, policy, and commitment · the plain-language version)

Read together, the operational point is not about which model to buy. It is that the decisiveness of a governed agent is a property of the context it is handed, not a fixed property of the agent. Change the prompt, the retrieved examples or the policy text and you have changed the control surface. If the evidence that your agent behaves is a test you ran in April, and the context changed in May, the evidence describes a different system.

That is the argument for recording the decision rather than the demonstration.

These three are research previews, published with their corpora and their limitations. They are a good-faith application of public regulatory frameworks to public data — not a vendor demonstration, and not peer-reviewed.

The gate is not the guard

The integration is less clever than people expect, and the plainness is the point.

Your runtime intercepts the proposed action before the side effect and asks whether it is allowed. MeshQu evaluates it against the policy and returns a verdict — allow, review, deny, or an advisory alert. Your runtime is then the thing that actually lets the tool call through, queues it for a human, or refuses. MeshQu does not intercept your agent's tool calls, and a denial is a signal your integration has to honour.

Four practical consequences, all of them in the recipe:

• The hot path and the audit path are different calls. Gating thousands of routine tool calls uses the stateless evaluation, which stores nothing. The consequential ones — a production write, a data export, anything someone will ask about later — use the call that evaluates and persists a signed receipt.
• A retried gate call is not a second authorisation. Supply an idempotency key and a retry returns the original receipt rather than minting a new one, which matters when the thing doing the retrying is an agent in a loop.
• A new agent rule can run without biting. In shadow mode the engine evaluates the rule and surfaces what it would have denied as an advisory alert, while the verdict your runtime reads stays unaffected until you promote it. Useful when you cannot afford to wrongly block an agent mid-run.
• Unreachable should mean refused. For a high-stakes action, a gate you cannot reach is a gate that failed closed, not a gate you skip.

The honest boundary here is worth stating: what the receipt evidences is the authorisation, not the execution. If your runtime is handed a denial and runs the action anyway, the receipt still says denied. That gap is a property of your integration, and no record closes it for you.

What the record says about who acted

This is the part most likely to be over-read, so here it is precisely.

The schema carries an actor: an identifier, an optional role, and a type that is either human or automated. The identifier travels into the decision context and is covered by the integrity check. The descriptive fields — the role, the display name, and the human-or-automated type itself — are stored for audit display and are not part of the hash.

MeshQu records the actor identity you supply. It does not authenticate it. There is no check against your identity provider, and no way for the service to know whether the thing on the other end of the call was the agent you named. The authenticated API key identifies the calling system; the actor field identifies the party that system says was responsible. Both are recorded; only one of them is authenticated, and it is not the actor.

So a receipt does not establish which agent acted, and it does not establish which model was behind it. It establishes that a particular identity was supplied at the moment of the decision, and that the identifier has not changed since. If agent identity is load-bearing in your programme, its strength is a property of the system that supplied it — and that is a design question for your side of the boundary. Actor attribution is the authoritative version, including which fields are bound and which are annotation.

What this does not prove

• Verification proves issuance and integrity. It never proves correctness. A passing check says the record was issued under a known key and has not changed since. It says nothing about whether the policy was right, the action was safe, or the verdict was the one that should have been reached.
• A valid signature alone does not detect an edit. The signature covers the integrity hash, and the integrity hash is what binds the content. It is the two checks together that make tampering evident.
• A recorded rationale is a record of what the agent said, not a check on it. The cross-model experiment makes the point at the agent's expense: shown a deliberately inverted rule, 88% of records produced the same verdict as under the unperturbed policy, and the reasoning cited the rule the agent thought it was applying rather than the one it had actually been given. Storing an explanation binds the explanation. It does not audit it.
• MeshQu does not authenticate the actor. Stated above, and worth the repetition — it is the claim this subject invites most.
• Anchoring is checked offline. A receipt can be anchored to a public transparency log and verified offline against a pinned log key. Live inclusion-proof verification against a co-signed witness is not implemented.
• A human resolution is tracked, not signed into the receipt. When an action held for review is later approved or rejected, that outcome is recorded against the decision. It sits alongside the signed artefact rather than inside it.

Why this is the version worth having

An agent that is governed and an agent that can be shown to have been governed are different states, and only the second one survives the question six months later, asked by someone who was not there and has no reason to take your word for it.

Execution proof does not make an agent safe. It makes a specific claim about a specific moment: this action was proposed, this policy was in force, this verdict came back, this identity was supplied. Everything past that boundary — whether the policy was wise, whether the identity was real, whether the runtime obeyed — stays your problem, and a record that pretended otherwise would be worth less, not more.