What an AI Agent Governance Platform Must Prove Before Compliance Signs Off

If you are the person who has to sign off before agents go live, you are being sold dashboards. This is a checklist for telling a governance platform from a reporting tool, written for the sign-off, not the demo.

Start from what you will actually be asked

Not "is the model accurate." The questions that arrive are narrower and harder:

• Which agent took this action, and under whose authority?
• What rule permitted it?
• Why did it decide that, given what it knew at the time?
• Where is that record, and will it still exist in eighteen months?

A platform that cannot answer those four has not solved your problem, however good its charts are.

The reason a certificate will not save you

The EU AI Act's high-risk provisions came into force on 2 August 2026. Autonomous systems taking consequential actions fall within scope, with obligations covering human oversight, accuracy, robustness and logging.

The EU AI Office has published no agent-specific guidance. Its own service desk describes considerations on agents as preliminary. Independent analysis has concluded the technical standards under development are unlikely to fully address agent-specific risk.

That is an unusual position: live obligation, absent standard. It has one practical consequence for you. Compliance here cannot be bought as a certificate, because there is no certificate to buy. What can be produced is evidence — and any vendor offering to make you "AI Act compliant" is selling something that does not exist.

Meanwhile the sector regulators have been more concrete. India's SEBI framework, binding since April 2026, requires per-order identifiers, audit trails and a kill switch for algorithmic trading, holding the broker accountable for algorithms on its platform. FINRA's 2026 report expects firms to limit agent system access and monitor agents so that unauthorised or out-of-bounds actions are blocked — and holds members responsible for third-party AI.

Those are specific enough to check a vendor against.

Eight things to require

1. It judges actions, not text. Ask what the unit of evaluation is. If the answer is the model's output, you have a content filter. The failure that generates liability is a consequential action produced by a defective chain of reasoning, where each step looks well-formed in the log.

2. It reads your policies. Not a general model of good behaviour — your exposure limits, eligibility rules, disclosure requirements, procedures. Ask specifically what happens when a policy changes. If the answer involves retraining, there will be a window where it is enforcing the old rules.

3. Verdicts name the rule. "Blocked, confidence 0.87" is not evidence. "Blocked under clause 4.2" is. This is the single clearest test of whether output is examiner-ready.

4. It is independent of the agent. Process safety keeps the safety system separate from the control system, because a system must never certify its own safety. A vendor evaluating its own agents fails that test definitionally. So does a stop that the agent must choose to obey — there is a documented case of an AI coding agent deleting a production database during an explicit code freeze.

5. Isolation is scoped. Stopping one misbehaving agent must not mean stopping every agent that is working correctly. Ask how granular containment is, and how it is triggered.

6. It runs where your data is. If evaluation happens in a vendor cloud, every prompt and record under evaluation leaves your perimeter. Under data residency obligations or in a segmented network, that is disqualifying rather than negotiable.

7. The record survives the vendor. Ask what happens to eighteen months of audit records if you terminate. If the answer is a support ticket, that is a dependency your continuity plan has to carry.

8. It reports its own false-positive rate on your traffic. Not a benchmark. Yours. A vendor unwilling to measure that in a shadow deployment is asking you to enforce blind.

Two questions that separate honest vendors from confident ones

"What is not built yet?"

Every platform in this category has a roadmap presented as a product. Ask directly which capabilities exist today, which are in development, and which are aspirational. A vendor who names their own boundary is telling you something reliable about everything else they said.

"Show me a conditional verdict."

Ask to see the system evaluate an action that is mostly right — correct in direction, missing a required control. A filter returns pass or fail. A judge returns "permitted, subject to clause X, which is absent."

Then ask to see it evaluate a correct refusal — the agent declining to do something unsafe. A keyword-based system fails it, because the dangerous string is present. A system reasoning about outcomes passes it and explains why. That single test tells you more than an accuracy figure.

How to de-risk the decision itself

Do not enforce on day one. Run a shadow deployment: the layer observes and judges every consequential action, blocks nothing, and reports at the end of the period what it would have caught, what it would have wrongly flagged, and what latency it added.

You then turn enforcement on policy by policy, with your real false-positive rate in hand. That inverts the usual risk: instead of trusting a vendor's claims in production, you measure them in parallel and decide afterwards.

Where we sit against our own checklist

Since we wrote the list, we should answer it.

Syntrox judges actions against your own policy corpus, retrieved at inference time so a policy change requires no retraining. Verdicts name the specific rule. The judge is independent of the agent and holds an isolation path outside it. Isolation is per-agent or fleet-wide. It runs inside your own network — VPC, on-premises, or edge — with no data egress. Shadow deployment is how every engagement starts.

What is not built, plainly: correction and steering are not shipped. Automatic isolation triggers on spend and cost ceilings today, not on policy-violation thresholds generally. We have no shipped vertical policy packs — those are built with design partners against their real documents. And we do not certify anyone's compliance, because no vendor honestly can.

Take this list to every vendor you are evaluating, including us. The ones who answer question eight without hedging are the short list.