How do you evaluate an AI agent governance platform?

Test six properties rather than comparing feature lists: whether the record is tamper-evident, whether completion is attested by something other than the agent, whether approvals are attributed to a named human, whether you can reconstruct what the approver saw, what happens when a budget ceiling is reached, and whether the system can run with no outbound network access.

What is the difference between logging and tamper-evidence?

Logs record what happened and can be edited, rotated, or expired afterwards. Tamper-evidence means altering history is detectable — typically an append-only structure where each entry is chained to the previous one and signed, so a changed record breaks the chain.

Why does it matter who attests that agent work is complete?

Because the agent reporting its own success is the claim under question. If completion is self-reported, the governance system is recording an assertion rather than verifying it. Independent attestation means something other than the actor — CI, a separate verifier — confirms the work.

Do policy gateways and governance ledgers do the same thing?

No. A gateway sits in the request path and decides whether an individual call is permitted, in real time. A governance ledger sits around the work and records what was done, who approved it, and what evidence existed. Many teams need both; they answer different questions.

Six things an agent governance system must prove.

Every vendor in this category will tell you they provide audit trails, approvals, and cost controls. Those words are cheap. These are six properties you can actually test, with the question to ask in each case — and our own answers, including where we don't apply.

Run this on us too. A standard you can't fail isn't a standard, it's a brochure.

The tests

Test 01

Tamper-evidence, not just logging

Logs record what happened and can be edited, rotated, or expired. A governance record has to make alteration detectable — otherwise it proves nothing about the past, because anyone with database access could have changed it.

Ask: "If an administrator edits a past record directly in the database, what breaks?" If the answer is "nothing, but we restrict access," it's a log with permissions.

Provostry: append-only, hash-chained. Each entry chains to the one before it. With a signing key set, every appended event is HMAC-signed, so an altered record breaks the chain and shows up as a verification failure rather than passing silently.

Test 02

Completion attested by something other than the actor

The agent reporting its own success is the exact claim under question. A system that records "agent says done" is storing an assertion, not verifying one.

Ask: "Can an agent mark its own work complete and have that count?" If yes, every downstream metric inherits the agent's optimism.

Provostry: CI attests completed work. Synced commits stay unverified until CI attests them, and the velocity metric only moves on attested work. The agent does not get a vote on whether it succeeded.

Test 03

Decisions attributed to a named human

"The system approved it" is not an answer anyone can act on. When something goes wrong, the question is who authorised it — and that has to resolve to a person, not a service account or a policy rule.

Ask: "Show me a past approval. Whose name is on it?" Watch for approvals attributed to the platform, a bot, or a role rather than an individual.

Provostry: escalations reach a person in Slack, Teams, or Telegram, and approve/reject is recorded as a decision against the individual who clicked, in the ledger.

Test 04

Evidence reconstructable as of the decision

Knowing who approved something is half of it. The other half is what they were looking at when they did — the state of the work at that moment, not the state it's in now. Systems that show current state cannot answer the question that matters in a review.

Ask: "For an approval from three months ago, can you show me exactly what the approver saw at the time?"

Provostry: evidence bundles are appended events, so the record of what existed at decision time is immutable and retrievable alongside the decision itself.

Test 05

Budget ceilings that stop work, not report on it

There is a large difference between a system that tells you the budget was exceeded and one where exceeding it is not possible without a human saying so. The first is a dashboard; the second is a control.

Ask: "What happens at the moment the ceiling is reached — does work stop, or does it continue and notify?"

Provostry: work carries a budget; reaching the ceiling raises an escalation and stops, and the increase is a recorded decision with a name on it rather than an overage reported afterwards.

Test 06

Runs with no outbound network access

For the teams who need governance most — regulated, defence, health, financial — the ledger of decisions is itself sensitive. If the system requires calling home to function, it is not deployable in the environments where the requirement is strictest.

Ask: "Can this run fully air-gapped, and what stops working if it can't reach you?"

Provostry: single container, file ledger or Postgres, fully air-gapped, no phone-home. Chat and ticketing integrations are optional per-organization connections you can simply not configure.

Where we don't apply

What this test doesn't cover — and what we aren't

A standard that only measures what we happen to do would be worthless to you, so here is the honest boundary.

Provostry does not sit in the request path. It will not intercept an individual tool call in flight and block it before it executes. Policy gateways and MCP proxies do that, and they do it well; if your requirement is "this agent must never be able to call that endpoint," that is a gateway's job, not ours.

What we govern is the work — initiatives, work packages, evidence, budgets, approvals, and the record of all of it. A gateway answers "was this call allowed?" A governance ledger answers "was this work actually done, who said so, and can you prove it a year from now?" Plenty of serious deployments want both, and they compose fine: the gateway enforces at the boundary, the ledger holds the account.

If what you need is the second question answered, that is what an operating system for AI organizations is for.

Questions

Common questions

How do you evaluate an AI agent governance platform?: Test the six properties above rather than comparing feature lists. Feature lists converge; behaviour under these questions does not.
What's the difference between logging and tamper-evidence?: Logs can be edited, rotated, or expired. Tamper-evidence means alteration is detectable — an append-only chain where a changed record breaks verification.
Do gateways and governance ledgers do the same thing?: No. One decides whether a call is permitted, in real time. The other records what was done and who is accountable. Many teams need both.

Run it

Test us first

The integration docs are open, there is no email gate, and you can have an agent writing into a ledger in one HTTP call. Start with test 01 and try to break the chain.

Read the integration docs →