pistra

Where pistra sits

Every AI gateway routes. pistra decides, and proves what it decided.

Six kinds of product sit on the path between your application and a model, and each arrived carrying its first buyer's concerns. Which moments of one request each of them is present for, the cases where you should use one instead of us, and the questions that separate them.

what is compared
6 positions on the path, not products
what decides one
which moments of a request it is present for
what is not here
a feature table, which is wrong within a quarter
as of
28 August 2026

Position is the part that keeps. Where a product sits on the path, and who pays it for what, holds for years: a marketplace will not stop being the counterparty, a gateway will not stop thinking in routes, a governance platform will not build a data plane. Features move the other way. The products here are converging on one list from opposite directions, so a cell saying any of them lacks something is wrong within a quarter. The grid below is drawn from position rather than features, and a deployment can be planned around it.

One request, and who is present at each moment

A single call in the order it happens, in the same four bands the product figure draws, from the credential the client presents to the check somebody outside the system can run on what was decided. Under it, one row per product: a filled mark where that product acts at that stage, a ring where it acts only through something else, and the case where it is the right answer and pistra is not. Take a stage and its column lights, with what is true there and what is not.

admitnothing sent yetsendone attemptdeliverthe record of itprovea different clockclientthe tool result comes back heredetectora string out, a verdict backprovidera model · an MCP server12345678910
A stage of one request

1 of 10The client authenticates

on the path here
A marketplace, a proxy, the API gateway you run, the cloud's own service, pistra. Each issues its own credential and holds the provider's.
not on it
A detector and a governance SDK are handed text by an application that already holds the provider key.

2 of 10The request is admitted or refused

on the path here
A proxy, the API gateway you run, the cloud's own service, pistra. A key, a model allowlist, a quota, a rule.
not on it
A marketplace bills the call it has already made. A detector returns a score and admits nothing.

3 of 10What the request says is read

on the path here
A detector, the cloud's own service, pistra. pistra runs the detectors inside the process holding the connection.
not on it
A proxy calls a detector over the network, so that detector's latency and its failure mode are the network's.

4 of 10What a tool result says is read

on the path here
pistra, on the tool_result segment, by default. That is where an injection arrives when a page an agent fetched carries one.
not on it
A product that thinks in routes sees one request body. A detector reads a tool result only when the application passes it one.

5 of 10What comes back is read in the stream

on the path here
The cloud's own service for its own models, pistra. Inspected as it streams, without buffering the response.
not on it
A detector called once the response is assembled answers after the user has read it.

6 of 10The tool call and the message to a peer agent

on the path here
pistra, at /mcp/<name> and /a2a/<name>, under the same keys, rules, budgets and record as the model call.
not on it
An API gateway with an MCP plugin reaches the call and not what the arguments say. The rest sit in front of a model endpoint.

7 of 10What it cost is settled

on the path here
A marketplace, a proxy, the API gateway you run, the cloud's own service, pistra. pistra reserves the cost before the call and settles it against real usage after.
not on it
A detector and a governance SDK never see usage. A rate limit counts requests rather than spend.

8 of 10What was decided is written down

on the path here
Every position writes something. pistra signs each decision with the key of the node that made it and chains it to the one before.
not on it
A record kept in the vendor's account is the vendor's to produce, and says what the vendor chose to write.

9 of 10The claim is checked

on the path here
pistra audit verify reads a trail in any order and reports every record altered, removed, moved, forged or cut short.
not on it
Nothing else on the path offers a check somebody outside it can run.

10 of 10What never came through

on the path here
pistra builds a second ledger from the provider's own usage API and judges the two against each other per day.
not on it
A ledger inside any product on the path cannot report the traffic that went around it.
PositionStage 1: The client authenticatesStage 2: The request is admitted or refusedStage 3: What the request says is readStage 4: What a tool result says is readStage 5: What comes back is read in the streamStage 6: The tool call and the message to a peer agentStage 7: What it cost is settledStage 8: What was decided is written downStage 9: The claim is checkedStage 10: What never came through
A marketplaceOpenRouter, Requesty, Vercel AI GatewayA developer with nobody asking. One person, one project, the model changes weekly, and a marketplace that does not store prompts by default beats most teams' own logging.presentnot presentnot presentnot presentnot presentnot presentpresentpresentnot presentnot present
A proxyLiteLLM, Portkey, HeliconeFive people and three providers. Run LiteLLM, and keep it upgraded, because that is where the list of known fields lives.presentpresentpresent only through another productnot presentnot presentnot presentpresentpresentnot presentnot present
The API gateway you runKong, Apigee, Tyk, Traefik, Envoy AI Gateway, kgateway, agentgatewayKeep the one you run. Keys, quotas and a model allowlist are answered by its own AI plugin, on the routes it already owns.presentpresentnot presentnot presentnot presentpresent only through another productpresentpresentnot presentnot present
The cloud's ownBedrock Guardrails, Azure API Management, Model ArmorA single-cloud shop whose verifier reads the account's logs from inside the account. Everything it covers, it covers for that one cloud.presentpresentpresentnot presentpresentnot presentpresentpresentnot presentnot present
A detectorPresidio, Lakera, Prisma AIRS, Guardrails AI, NeMo GuardrailsAny content the process on the path cannot recognise on its own: injection, jailbreaks, toxicity. Buy the detector, then decide separately what holds the connection.not presentnot presentpresentpresent only through another productpresent only through another productnot presentnot presentpresentnot presentnot present
A governance platform's SDKCredo AI, Holistic AI, watsonx.governance, OneTrustOne application, one supported language, no agents talking to tools directly. It stops working at the first service that does not embed it.not presentnot presentnot presentnot presentnot presentnot presentnot presentpresentnot presentnot present
pistraThe whole path, and the two stages past the cut: a record signed on the node that decided, a check somebody outside the system can run, and a second ledger for the traffic that never arrived.presentpresentpresentpresentpresentpresentpresentpresentpresentpresent

Every position acts somewhere in the first eight stages, and a deployment that needs only what one of them does there is well served by the row that names it. Two of those eight are already thin: the tool result nothing else on the path reads, and the tool call an MCP plugin reaches without reading its arguments. Every product writes something down at the eighth, which is why that column is full and why a record on its own settles nothing.

The line is cut after it. The last two stages are not moments in a request, they are a check run later and a reconciliation run daily, and that is the cell pistra was built for: a record signed on the node that decided it, a check that runs without trusting the store it reads, and a second ledger for the traffic that never arrived. They start to matter at the first question about what a prompt contained, or whether a rule ran, and by then the quarter being asked about has already been forwarded.

Ask about the evidence

Each question asks about a position instead of about anybody's product, so the answers keep for longer than a feature table does. Ask them of any vendor on the figure, and of us.

  1. Which node signed this record?
  2. What chains it to the one before?
  3. Which party, besides the store the records sit in, has to be honest for that check to hold?

A product that has an answer to all three keeps a record you can verify. A product that has an answer to the first two keeps a record that is tamper-evident, as long as nobody cut it short. A product with an answer to none keeps a log, and a log is fine until somebody asks. We are not going to fill these in for anyone else. Ask, and read what comes back.

Our answers

  1. Which node signed this record?Every record pistra writes is signed with the key of the node that made the decision.
  2. What chains it to the one before?Each record is chained to the previous one on that node. pistra audit verify reads a trail, in any order and with anything interleaved, and reports every record that was altered, removed from the middle, moved or forged, by sequence number.
  3. Which party, besides the store the records sit in, has to be honest for that check to hold?A quorum of your own cluster. A chain cannot show it was not cut at the end, so each node offers its signed head to the raft cluster about once a minute, and pistra audit verify -heads reports a trail that stops short of a witnessed head. Raft holds the heads and never the records; the records go to your collector, in your account. That answer assumes a quorum, so what it takes to have one, and what stops when it goes, is written down.What a cluster survives

Two limits belong beside that answer. A key used by somebody other than the node is not something a trail can show. It proves what the key signed, and keeping the key where only the node reaches it is the deployment's job. And admitted requests are absent from the trail, on purpose, because the record is bounded and says so.

As of 28 August 2026

The grid is the part of the argument kept current. A post describes the day it was written. The reasoning behind each position is a post of its own in Where control lives, eleven of them, starting at Where AI governance came from and ending with Comparing the six positions. The whole series is on the blog.

Govern your first providerWhat an AI enforcement layer is