Governance platforms

On one side is a platform that owns the policy document, the risk register and the binder the auditor reads. On the other is a gateway that has been forwarding requests all year. The binder needs runtime evidence for a control named something like AI-07 by the end of the quarter, and somebody has to join the two.

The platform’s integrations page lists a Python SDK. The gateway is written in Go.

Before and after

A governance platform sits before the call and after it. Before: the inventory of models and use cases, the risk assessment, the policy pack that maps a framework’s articles to controls with names like AI-07. After: the evidence that the control ran, collected into a binder, with a status per control. The call sits between those two, and the platform is not there. It is a system of record, and the request path is not its business.

Where a platform does enter the call, it does so as an SDK the application embeds. An SDK inside the application sees the prompt and the response the application built, which is most of what a gateway would see, and it can redact and block on them. It never sees the credential and the budget, which belong to the gateway, or the bytes the provider was actually sent, which belong to post 5. And it sees only the calls that go through the SDK: a Go service, a batch job in another language, or an MCP server the agent talks to directly never link it, and their absence from the binder is silent.

So the platform needs a runtime that witnessed every call, and it needs that runtime to hand over evidence the platform can rely on without relying on the runtime. The runtime signs each decision, and the platform reads them back by revision.

What a record has to be

Two words.

A record is complete when a reader can tell that nothing was altered or removed from the middle. Each record is chained to the one before it on the same node and signed by that node’s key, so a record altered, removed, moved or forged becomes a finding with a sequence number instead of an absence somebody has to notice. A chain cannot show on its own that it was not cut short at the end. That needs a witness outside the node, which post 11 demonstrates.

A record is bounded when it says what it does not contain. pistra’s trail does not list admitted requests. A trail of everything that went through is the traffic log, and refusals buried in it go unread. What ran on an admitted request is shown by the policy revision in force at the time, which is recorded, together with the traffic log. A guardrail record also says which detectors only contributed what they already knew about this text from an earlier turn, and whether the outcome was acted on or merely computed, so that a reader never has to reconstruct whether something was actually blocked.

The binder asks five questions, and each reads a different part of that. Inventory reads the meter: what was actually used, by route, provider and model. Policy binding reads decide: which rule refused or redacted, and the control names the rule carries. Monitoring reads bounded: the revision in force and the honesty fields, so that absence is never mistaken for a control that ran. Evidence reads the record back by revision. An incident reads all four at once.

Who should rely on the SDK anyway

A shop whose AI calls all go through one application, in a language the SDK supports, with no agents talking to tools directly. The SDK sees everything there is to see, and it is already integrated with the binder. That is a real deployment and, for now, a common one. It stops working at the first service that does not embed it.

What pistra does at this box

A rule, whether an access rule, an MCP rule or a guardrail rule, can carry a list of control identifiers the platform assigned, controls: [acme:AI-07, eu-ai-act:art-50]. pistra checks their shape and not their meaning, since the platform owns the taxonomy. Every record that rule produces carries the list, in the rule’s order, and the same list rides as a log attribute so a collector can answer “every decision under AI-07 this quarter” without parsing a body.

The integration is four ordinary steps. The platform gets an identity from your issuer. One line of admin policy grants it a configuration source of its own and the right to read. It writes its policy into that source, with a precondition on the revision so two writers never silently overwrite each other, and the revision it gets back is the join key. It reads the decisions back from your collector, by that revision, and verifies the chain with a command it can run itself.

All posts