Who holds the evidence about your AI agents?

Your agents do not live in one place

Count the places an agent runs in your organisation right now. Something is on Azure because that is where the tenant is. Something is on Bedrock because a team liked the model. Something is a Python service a developer wrote in a fortnight and nobody has looked at since. Something is a coding agent with a shell and repository write access. Something is a vendor's agent, acting on your data, inside their product.

Every one of those platforms has, over the last eighteen months, shipped a governance story. Microsoft open-sourced its Agent Governance Toolkit under an MIT licence, with policy decisions evaluated before a tool call executes. verified 1 Sep 2026 AWS shipped policy enforcement in front of agent tool calls. Frameworks added their own hooks: LangGraph ships a before_tool_call interception point, so “there is nowhere to put a check” is no longer true of anything serious.

This is genuine progress, and it settles a question that was open two years ago. Interception is solved. Every one of those systems can stop an action before it happens.

What none of them solves is the question you get asked afterwards. Not “can you stop a bad action?” but “show me that you did.” And there, each platform can speak only about its own slice, in its own format, on its own word. Nobody holds the whole. Nobody outside holds any of it.

What is already settled, and where this picks up

Two arguments in this area are settled well enough that repeating them wastes your time. (If the category itself is new to you, start with what AI agent governance is — this piece assumes it.)

The first is that an agent cannot govern itself. The system optimised to complete a task is the wrong system to decide whether the task should happen; the proposer and the evaluator have to be architecturally separate. We argued that at length in Agentic AI Governance: The Infrastructure Gap Nobody's Filling, and it is no longer controversial.

The second is what a good record looks like once you have one — hash-chained, append-only, tamper-evident, with the reasoning attached. That is covered on Trust and specified in the technical specification.

This article assumes both and moves one level up the stack. The agent is not the governor — fine. But who governs the platform that governs the agent, and who keeps the record of what it decided? That question is not about the agent at all. It is about the runtime, the vendor who operates it, and the awkward fact that in almost every deployment today, they are the same party.

Custody is the question, not capability

There is a discussion open on Microsoft's own Agent Governance Toolkit repository, titled “Agent governance: policy enforcement vs decision evidence”. It was opened in March 2026 and has run to more than fifty comments. It is the most useful public document in this space, and it is worth reading in full, because a group of practitioners talked themselves step by step into the conclusion this article is about.

It opens with a simple proposal: treat the decision itself as a first-class artifact, in a pipeline of Intent → Policy → Decision → Evidence → Execution, where the decision and the evidence are sealed and replayable. A maintainer answered honestly, and the honesty is the point:

Read that again with a compliance hat on. The decisions exist. They are logged. They are hash-chained. And they are inside — not objects you can hand to someone who was not there.

Another participant put the gap in the form of the question an outside party actually has:

Capability and custody are different axes, and the industry has been sprinting along one of them. You can have a world-class policy engine, sub-millisecond decisions, a perfect chain — and still have nothing you can give a regulator, an insurer, an acquirer, or a customer's security team that does not reduce to trust us.

Integrity is not faithful capture

This is the heart of it, and it is the distinction almost every vendor page in this category quietly elides.

A hash chain is a strong guarantee about one specific thing: that the bytes have not changed since they were written. Anchoring the chain externally strengthens it further, making the record operator-independent once it exists. Both are real, and both are worth doing.

Neither says anything at all about whether the bytes were true when they were written. As one participant in the discussion put it, with unusual precision:

Sit with the failure mode, because it is not exotic. A runtime is compromised, or merely misconfigured. It does not need to break any cryptography. It does not need to tamper with a sealed chain. It simply authors the entry before sealing it — and then every downstream mechanism you have built faithfully preserves the fabrication. Canonicalisation makes it neat. The signature makes it authentic. The anchor makes it permanent. You have built an extremely rigorous pipeline for laundering a false statement into an official record.

This is not hypothetical hand-waving. Another participant described hitting it in production: a platform returning a success status for content that did not exist and would not exist unless a challenge was answered within five minutes, producing what they described as

Forty-one signed, well-formed, deterministically replayable records of things that never occurred. Every integrity check passes. The evidence is worthless.

The reason this matters structurally, rather than as a bug to be patched, was identified in the same thread: capture happens inside the governed runtime's process boundary. In Microsoft's toolkit, the policy engine and the agents share that boundary by design — which is exactly what makes it fast. Performance and independence are pulling in opposite directions here, and almost every product in this category has chosen performance, mostly without telling you that it chose.

Why platform-native governance has a structural ceiling

Now put the two halves together, and the commercial shape of the problem appears.

Microsoft's governance covers agents built on Microsoft. AWS's covers agents built on AWS. A framework's hooks cover agents built in that framework. This is not a criticism — it is the only thing any of them could reasonably ship. But it produces two consequences that no amount of engineering inside any one platform can fix.

The first is coverage. Your fleet spans several of these, plus code you wrote yourself. Every platform sees its own slice, in its own schema, with its own semantics for what “blocked” means. There is no view of the whole, and assembling one after the fact from four incompatible logs is precisely the exercise that goes badly in an incident review at two in the morning.

The second is independence, and it is the one that does not yield to integration work. When the party that operates the runtime is also the party that captures the record of what the runtime decided, that record is self-attestation with extra steps. It does not matter how good the cryptography is. The signature proves who signed. It does not establish that the signer was a disinterested observer — because the signer was the operator.

One participant in the discussion drew the analogy that makes this land, and stated the principle better than we would have:

That sentence is the whole argument. You cannot add independence to a record by adding a field to it. Independence is a fact about where the witness stood, and no amount of schema design relocates a witness that is already inside the process it is describing.

It is worth being fair about who is saying this. Several of the practitioners quoted here are building products in this space, ours included. That is not a reason to discount the argument — it is the reason the argument is being made in public at all, on a competitor's repository, by people who disagree with each other about nearly everything else. Read the thread and judge it yourself.

What an auditor actually asks

Engineering discussions about evidence tend to fixate on format. Auditors do not care about your format. They ask a different set of questions, and the discussion surfaced them cleanly.

There is a second question, just as practical, and it catches out systems that log verdicts without logging the rule that produced them:

This one is easy to fail without noticing. Policies change. An action approved in March was approved under March's rules. If your record stores the verdict but not the policy version and content that produced it, then in November you can prove that something approved it and prove nothing about whether that approval was correct. You have preserved the answer and thrown away the question.

A useful test, also from the thread: given the same intent, the same policy version, and the same normalised inputs, can the system reproduce the same decision — or clearly explain why replay is no longer valid? If not, what you have is a log, not evidence.

Self-reported, observed, attested: the basis of a fact

The most immediately useful idea to come out of that discussion is small, and you can apply it to whatever you have already built this week.

Every fact in a governance record carries a basis — how it came to be known — and the basis should be a typed, load-bearing field rather than an adjective in a description:

• self_reported

  The runtime asserts it. Worth something, but it is the runtime's word about the runtime's own behaviour.

• observed

  Independently detectable at decision time, rather than simply claimed after the fact.

• attested

  Signed by an authority external to the runtime — one whose key the runtime does not hold.

The reason this bounds the fabrication case is mechanical rather than rhetorical. A compromised runtime can emit anything it likes with a self_reported basis. It cannot produce a valid attested basis for a fact it is forging, because it does not hold the external signer's key. So a record whose load-bearing facts are required to be attested fails closed rather than failing convincingly.

The same thread adds a warning worth repeating: observed and attested collapse into each other very easily in practice, which is why the basis has to be typed and enforced rather than a free-text label. Otherwise the record reads stronger than it is — which is the failure mode this entire article is about, in miniature.

Alongside the basis sits a custody axis: which party captured the record, at what moment relative to execution, and what the trust-domain relationship is between the capturer and the executor — same domain, the deployer's domain, or a genuinely independent third party. Without it, as the discussion notes, two records can be byte-identical and carry entirely different evidentiary weight in front of a supervisor.

Four properties of evidence you can hand to a stranger

Pulling the threads together, here is the checklist. Apply it to whatever governs your agents today, whoever built it — including us.

1. Independence of capture. Was the record authored by a party with an interest in the outcome? If the operator of the runtime is the author of the record, the answer is yes, and everything downstream inherits that. This is a question about position, not about cryptography.
2. Policy-version binding. Does each decision carry the snapshot of the control that evaluated it, so someone can re-evaluate it later rather than take the verdict on faith?
3. Typed basis per fact. Can a verifier tell, per field, whether something was self-reported, observed, or externally attested — and do the load-bearing fields fail closed when the strong basis is absent?
4. Portability. Can the record leave the system that produced it and still be checked — by someone with no access to that system, no account with that vendor, and no reason to trust either?

Most agent governance available today scores well on integrity and poorly on all four of these, because the industry spent eighteen months solving interception and has spent rather less time asking who the resulting record is for.

If you take one thing from this article, make it the first item. The other three are engineering. The first is architecture, and it is decided the moment you choose where the governance layer runs.

How GaaS produces this

This section describes our own implementation. The argument above stands on its own and applies equally to systems we did not build; we would rather you evaluated it than took our word.

GaaS is an external governance layer. Agents declare intent to it before acting, it evaluates that intent against your policy, and it returns one of four verdicts — approve, modify, escalate, or block — along with a record of the decision. The details of the pipeline are on How It Works, and the record's mechanics are specified on Trust.

The relevant property here is not the verdicts. Several platforms now have verdicts, and as noted above, Microsoft's toolkit ships a superset of ours. verified 1 Sep 2026 The relevant property is that GaaS is not the runtime that executes the action. It sits outside the process boundary of the thing it is governing, which means the record of a decision is authored by a party that did not perform the act being recorded — and cannot quietly become one, because it never holds execution.

That is a structural position rather than a feature, which is the entire point of this article. It is also the one thing a platform-native governor cannot copy without ceasing to be platform-native.

We are not claiming this solves faithful capture completely. Nothing does. A governance layer still receives its inputs from somewhere, and an agent that lies about its intent to an external governor has moved the problem rather than eliminated it — which is why the typed-basis discipline above matters just as much to us as to anyone. What an external layer changes is the custody question specifically: who authored the record, and what interest did they have in its contents.

Frequently Asked Questions