- what it is
- one process on the path, between your application and a model
- what you run
- one binary, no database, no sidecar
- what it refuses
- a call your policy denies, in line, with the rule named
- what it leaves
- a signed record of the decision, checkable by anyone
What an AI enforcement layer is
An enforcement layer is the process between an application and a model that can refuse a call, change what it carries, and prove what it did. A governance platform writes the policy and reads the decisions back. An API gateway routes the call and counts it. A detector classifies a piece of text it is handed. Governance platforms name runtime enforcement as something they integrate with rather than something they do, and this is the thing they integrate with.
A programme decides what should be true, and an audit asks afterwards whether it was. Something has to make it true while the request is in flight, and the frameworks stop short of naming what. Where AI governance came from traces that gap to the discipline's origins in model risk management, and to the two 2026 documents that put the deferral in writing.
- On the path. It holds the connection rather than watching a copy of it, so a rule refuses a request instead of flagging it afterwards.
- Every call kind. A model request, an MCP tool call and a message to a peer agent arrive at the same door, under the same keys, rules, budgets, guardrails and record.
- Decided per request. A prompt is assembled at runtime out of a conversation, a record lookup and a tool result, so what reaches the model is a property of the request rather than of the code. The decision is made at the moment the request is.
- Evidence on your side. Each decision is signed by the node that made it and chained to the one before, in a store you hold, and
pistra audit verifyis a check anybody can run.
Counted from the recognizer tables and the packs, not from a datasheet. Every identifier, every credential, every pack.
Without one
The parts exist separately.
A proxy for the keys, a detector for the content, a log pipeline for the record, and a client library in every language your services are written in.
That assembly keeps no single record covering model calls, tool calls and agent messages, because each part keeps its own. It says nothing about the services that skip the library, which are ungoverned and unrecorded. And it hands somebody outside the system no check to run, because a log says what its writer chose to write. Where pistra sits walks one request against the six positions that fill part of it.
Keys decide, detectors inspect, the record proves.
- Access. Teams get keys, budgets and the models they are allowed. MCP servers and A2A agents sit behind the same door as the models, so a tool call and a message to a peer agent are policed at their hop with the same rules. The SDKs they already use change one line. Govern your first provider.
- Enforce. Detectors run in the same process as the connection. A rule in CEL reads the key, the model, the tool and what the detectors found, and denies, rewrites or annotates. Responses are inspected in the stream without buffering. The guardrail pipeline.
- Prove. Every decision is a signed, chained record naming the rule and the control it stood for. The record carries counts and never the content.
pistra audit verifyreports anything altered, removed, moved, forged or cut short. The audit trail.
Nothing to run beside it.
One binary, no database, no sidecar, raft inside. Keys, budgets and certificates live in its own log, so there is no Postgres and no Redis to run, back up or make highly available. A chart or a container, on VMs or in a cluster, in front of the traffic or beside a gateway you already run. Three replicas are the cluster, and losing its quorum stops key mints and budget writes rather than traffic. Deployment requirements, the architecture, and what a cluster survives.
The order carries reasons.
Where each of the three runs, in the order the binary does it. Request guardrails run before the channel is chosen and before the cost is estimated, so every later stage works from the redacted bytes. The budget is held last, so a refusal above it costs nothing.
What goes wrong on the path
A prompt is assembled at runtime out of a conversation, a record lookup and a tool result, so what reaches the model is decided per request. So is where it goes: the endpoint that serves a request is resolved per call, and endpoints differ in what they preserve. Each page below takes one thing that goes wrong on the way, says what pistra does about it, what that costs, and what it leaves undone.
Personal data
83 kinds of identifier, found before the request leaves.
Card numbers, names and identifiers are found in the request and rewritten before the provider sees them. What each operator leaves for the model and for a tool, and why the realistic ones fail quietly.
Prompt injection
User turns, system prompts and tool results are all inspected.
Instructions arrive in a user turn or inside a document a tool fetched. What pistra inspects by default, how a classifier and a judge differ, and why both reduce rather than prevent.
Non-English requests
A profile picks the guard your language needs.
No single prompt-injection checkpoint serves a deployment in more than one language. 314 of 315 red-team prompts change verdict with the language they are written in, from none flagged in English to 98% in Bengali. The checkpoint that fixes that gives up English quality to do it, so both are pinned and a profile picks which inspects its traffic.
Agents and tools
Your MCP servers and agents answer at a door you govern.
MCP servers and A2A agents sit behind the same door as the models. What a rule reads at the tool call and at the message to a peer agent, who the upstream sees, how a client finds an approved server, and what the door refuses.
Routing
The endpoint you evaluated is the one that serves.
An eval passes against a model, on one endpoint, with a particular set of capabilities honoured. A request names an alias instead, and the provider that serves it resolves that alias itself. What pins the validated behaviour to a route, and what is counted when one changes.
Unmetered traffic
The provider's own ledger checks yours.
A ledger cannot report what it did not see. A second ledger built from the provider's own usage API is judged against the gateway's per day, so the claim that every request went through it has a verdict rather than an assurance. The audit of AI you do know about, not discovery of AI you do not.
Every number describes this binary.
Most of those pages carry a measured table, and the tables are the reason to believe them. pistra guardrails eval produces them by compiling the config the way the gateway compiles it and scoring labelled text at byte offsets, so the number describes the binary rather than a checkpoint on a hub. Any checkpoint can be pinned to a commit and verified on the way in, and the graph runs in this process or on a box with a GPU. Choosing a detector.
Every decision is signed where it was made.
Each record is chained to the one before it, and the check runs on a machine that trusts neither the gateway nor the store it reads.4 control packs each carry one regime's rules, citing the article each was read from and certifying nothing. What you can prove, and what you can start from.
Threats and limits
One entry per thing the product is asked to stop, grouped by where the text arrives, each with the asset at risk, who writes the text that puts it there, the control, and the limit. It is a page of its own because it is the one somebody forwards to a reviewer. Threats and limits, and the threat model that ships with the binary, in the docs.
Where pistra sits
Six kinds of product sit on the path between an application and a model, and each arrived carrying its first buyer's concerns. Three questions separate them, and one row each says when to use one of them instead of pistra. Where pistra sits.