Handbook / Trust & Governance

Before you let AI act on its own, you need more than a good model.

For banks, insurers, hospitals, ministries and regulators, the places where "usually right" is not good enough. This page starts with the problem in plain terms, then shows the discipline we teach, the architecture we have shipped to enforce it, and our research behind both. For everyone who has to build AI, ship it, sign off on it, and answer for it.

First, the problem, in plain terms.

For a few years, AI mostly talked. You asked, it answered, and if the answer was wrong you saw it and moved on. That era is ending. The new systems do not answer, they act: they send the email, update the record, move the money, reply to the patient. And an action you never saw is an action you cannot catch.

You never see this in the shiny demo. Because in the shiny demo it is always the happy path: a clean question, a known answer, a controlled room. Your work is none of those things. In production these systems are usually right, and "usually" is a lovely word in a chatbot and a dangerous one in a bank. Something right 95% of the time, taking a thousand actions a day, is quietly wrong fifty times a day, in your name. In a hospital, an insurer or a ministry, "usually right" is not a release criterion.

So the useful question is not "is the AI clever?" It is "what happens the moment it is wrong, and who is accountable when it is?" Most AI projects never ask it. This page is the answer.

What "trust" actually means here.

Trust is not a property of the model. It is a property of the system you build around it. A model can score brilliantly on a public benchmark and still be a stranger to your reality: your data, your workflows, your context, your clients, your money, your reputation.

The benchmark answers "is the model capable?" It never answers the only question that matters to you: can I trust this system, on my data, for my work, with my clients and my money on the line?

A 94%-accurate data manager is not a 94%-trustworthy system; the benchmark number is the start of the conversation, not the end. The real work is scoping, verification, governance and monitoring, in that order, run as a discipline that survives the next change of model, and enforced by a layer that sits between every agent and everything that matters.

Cohorte builds this layer in the open, and trains the people who run it. What follows is both, in plain terms first, with the proof underneath.

The discipline: four layers.

Most "AI governance" programmes start at the wrong layer. They begin with policy, then add evaluation, then attempt to scope use cases later. The result is policy applied to the wrong systems, and verification applied to systems that should never have been built. The layers run the other way.

The platform that enforces it.

Think of it as one security checkpoint that every AI action has to pass through, the way everyone in a building badges through the same door whatever laptop they carry in. The AI tools can be anything and can change weekly; the checkpoint never moves, and nothing reaches your data or takes an action without clearing it. In the architecture that checkpoint is a permanent layer, and everything above and below it is replaceable. Local AI systems reach organisational data and actions only through it. Nothing bypasses it.

A governed request, end to end.

This is what "the gateway mediates everything" means in practice. One request from one agent, every checkpoint it passes, and what each one decides. A non-technical reader can follow the left column; a security reviewer can read the right.

Start with our open-source libraries.

Everything in the diagram above is code you can read, not a roadmap. The gateway is open-source and versioned. Each component is tested and benchmarked on its own, and the permission model is formally verified. You can adopt the pieces as separate libraries or run them as one integrated middleware. The policies are plain YAML in git, and the audit trail is append-only. Engineers can inspect it before they rely on it, and so can auditors.

Six repositories, over two thousand tests between them, every policy auditable in git, every decision on an append-only trail. The book that ties them together, The Enterprise Agentic Platform, is published.

Verification: how a system earns the right to deploy.

How do you know a system is good enough to trust with real work? You don't take the vendor's word and you don't trust the demo. You measure it, the way a new drug is measured before it is approved: run it many times, on real cases, and attach a number to how often it is right, with a guarantee. Below the bar, it does not ship.

That number is the reliability level. Under the hood: sample the system several times on a task, group the answers that mean the same thing, calibrate against a held-out set, and you get the confidence at which the top answer is trustworthy, with a finite-sample, distribution-free guarantee that holds regardless of the model's hidden biases. It needs no ground truth at run time and no access to the model's internals. The method is published, and the gate is shipped, open-source, as trustgate.

Worked examples from the published study (GPT-4.1 shown). The method itself is model-agnostic; the figures are a snapshot of the frontier models tested at the time, not a fixed claim about any one model.

Reliability is only half the question. The other half is cost.

A system can be reliable and still be a disaster, if it is reliable at the wrong price. The real question is never just "does it work?" but "what reliability, at what cost, for this workflow?" A pilot that answers beautifully and costs a dollar a request will break the budget the week it succeeds.

This is the bill almost nobody forecasts. The price per token has fallen by roughly three quarters, which sounds like relief. But an agent does not make one call, it makes hundreds: it loops, retries, reads context, calls tools, checks its own work. Consumption can rise two-hundred-fold. Multiply a token that is 75% cheaper by hundreds of times more tokens, and the bill still climbs an order of magnitude or more. Teams that expected a modest increase are opening invoices fifty or sixty times larger, and some are quietly discovering the AI cost more than the people it was meant to help.

So cost is not an afterthought to governance, it is part of it. The LLM gateway in the architecture above meters every call, attributes it to an owner, and enforces a budget, because a workflow's reliability target and its cost ceiling are decided together, not discovered on the invoice. Performance-against-cost belongs beside reliability, security and sovereignty as a first-class question, and it is the subject of its own briefing.

What if your AI supply gets cut off?

There is a quieter risk in building your business on someone else's API: you are one decision away from losing it. A lab retires the model you depend on. A government restricts where a model may run, as happened when the US blocked Fable 5 from rolling out beyond its borders. A provider changes its terms, its price, or its access overnight. If your whole organisation stops working the day a single vendor in a single country decides you no longer get tokens, that is not a strategy. It is an exposure.

The answer is not paranoia, it is portability. Keep the model behind an interface you own, so you can host your own where it matters, run open weights, and swap providers without rewriting the system or re-earning trust. Sovereignty here is not a flag-waving slogan; it is the plain ability to keep operating when someone upstream changes their mind. Briefing 05 maps it dimension by dimension.

Can an agent be talked into breaking your rules?

This is the security layer of trust, and most of what is said about it is guesswork. Everyone worries about AI being "hacked." Far fewer have tested what genuinely works. We did, about 10,000 times, across seven frontier models, in real sandboxed machines with real tools, and published the results. We tried twelve different ways to talk an agent into breaking its own rules. Nine of them did nothing at all.

One worked alarmingly well, and it is not the one people expect. You don't jailbreak the agent, you change the story. Tell it the task is a puzzle or a security challenge, and it quietly reinterprets breaking the rules as winning the game, exploiting the system 32–40% of the time on some models, even when it was explicitly told to follow every rule. The exact same prompt did nothing on others. The agent never "decides" to disobey; it convinces itself the exploit is the task.

The lesson is the uncomfortable one. Telling a model to "be careful" does not work. Constraining what it can reach, and checking what it actually does, is the only thing that does. That is why governance has to live in the architecture, not in a prompt.

Where the large platforms stop.

The big platforms all let you build agents. The question a CISO should actually ask is narrower, and it has two parts. Can an agent ever do something its own user is not allowed to do? And when an action is risky, can a human always stop it, in a way the agent cannot fake or skip? Those two guarantees, an agent's powers staying inside its user's, and approvals it cannot forge, are the line between a governed agent and a liability. We formalised them, proved them with a model checker, and checked the field. The table below is not marketing; it is from the published permission-model paper.

In the same framework, no governance blocks 0 of 5 attack scenarios, basic role-based access blocks 4, and the full control plane blocks all 5, cutting cross-domain data leakage from 26% to 12%. The proof covers 4.6 million states with zero invariant violations.

The briefings.

Each briefing is a standalone A4 document built for forwarding to procurement, security, and the relevant leader on the buying side. They reference each other; none requires the others to make sense. The CISO & vendor briefing sits next to them as the security-and-procurement companion.

Why this practice exists.

How this connects to the programs.

Trust and governance is the content. The four Cohorte programs are the installation mechanism.

The references.

The frameworks on this page are not opinions. Each maps to public regulation or to published research. The research is on the research page; the papers are preprints under review.