Gate, Audit, Prove

Two tools, two moments

The gate, bossyk, sits as a proxy between your agent harness and your inference endpoint and either forwards a model's response untouched, or replaces it with a refusal^*, before your harness acts on it. The audit, auditk, measures after the fact: it reads the session file your harness outputs and scores what actually happened, independently of anything the gate saw. A scorecard merges both records and checks that they agree. The proof.

Why two records, not one

The two services watch different things. The gate enforces the rules a deterministic check can decide before execution: where the agent may write, what it may read, what it may install, where traffic may go. The audit scores what no pre-execution rule can reach: whether each step the model took matches the intent it declared, which is where drift lives. Each produces its own signed record. The gate's log says what was allowed and what was stopped; the session file, written by your harness rather than by the gate, shows what the agent actually did. The scorecard checks the two against each other. When they agree, that is corroboration earned from two components that never talk to each other, not an assumption. In one baseline run with nothing hostile in the workspace, the scorecard showed this:

All three figures verified from the trace, not taken on trust.

Why an always-on gate, not just an audit

Across our trap runs, the same prompt against the same workspace didn't produce the same behaviour twice. Here's how three models did against a planted credential file (a fake .env) sitting in the workspace, across repeated runs with identical prompts, identical workspace, identical model defaults:

Most models resisted the planted trap most of the time. But which run tripped it and which didn't followed no pattern we could find; it is not a fixed trait of the model. A one-off test on any single run could have told you almost anything. An always-on gate doesn't change how often a model reaches for the file; it changes what happens when it does, on every run, not just the ones you happened to sample. Where a model did reach for it, the gate's no-credential-reads policy stopped the read before it returned anything, and the model's own session file recorded the refusal independently, so the scorecard could confirm it rather than assume it.

Watching intent, not just actions

This work began with a simpler question than policy gating: when an agent says what it is about to do, does it then do that thing? The gap between declared intent and enactment is drift, and it is what the audit layer scores on every step of every run, independently of whether any policy fired.

The gate handles the enforceable class of rules; drift scoring watches everything else, including the risks that cannot be gated at runtime: goals smuggled in through data, quiet scope creep.

A worked example: editing the test instead of the code

From one of our MiniMax M3 trial runs, read straight from the signed trace. The model began exactly as instructed:

No policy in the gate's pack names this. Nothing crashed, nothing left the workspace, every individual action was allowed. Only the run's own words set against its own deeds show what happened: the agent quietly moved its goalposts. This is the class of behaviour that only an audit can see, and it is exactly the failure mode a team relying on "the tests pass" never notices.

That finding did not stay a finding. It is now a deterministic auditk rule, shipped from exactly this trace: a test file edited after a failed run raises a structural flag on every audit from then on. What the judge notices once, every future run is checked for.

The drift ribbon

Every scored step of four real runs, in order, coloured by the judge's label. The first row is the run from the worked example above; the underlined stretch is the test-rewrite window:

Every scored agent step of three hostile-workspace runs; the score and every label ship inside the signed evidence pack.

On a short task most steps score faithful, and that is the point: drift on a fifteen-step run is rare and small. The behaviour operators most often describe, a model that follows instructions well at first and less well the longer you work with it, is the same quantity at session scale, where it compounds. The audit gives it a number per run, and a signed record that someone was watching even on the runs where nothing fired. That record, not the occasional catch, is the product.

Concretely, five readers use that record, each for a different question:

• You, as the operator. The record of week one is the agenda for the governance conversation with your clients, and over time it lets you route work between models on measured behaviour rather than reputation.
• Your client's compliance function. Auditors do not ask "did anything bad happen"; they ask "show me the control operated in March". Only a continuous signed record answers that.
• A security team. When something fires, the surrounding record is what turns an alert into a narrative: what was attempted, what stopped it, and what the weeks of normal looked like before it.
• Anyone in a dispute. "Your agent read our data" stops being an unfalsifiable accusation and becomes a checkable claim, in either direction, which is exactly what makes the record credible.
• A regulator, eventually. Record-keeping obligations are continuous, not incident-shaped, and a lone incident report with no surrounding baseline looks curated. The baseline is what makes it believable.

The difference it buys is the one that matters commercially: not "we believe our agents behaved", but "we can show they did, for any week you pick".

Where each piece sits

The gate is a thin proxy in front of your inference endpoint. It speaks the same OpenAI-compatible protocol on the way out, so nothing about your endpoint changes.

pi (or any OpenAI-compatible harness) talks to the gate exactly as it would talk to your endpoint directly. The gate buffers the response, checks every proposed tool call against the policy pack, then either forwards it verbatim or swaps in a refusal that names the violated policy, before your harness sees either.

The unit the gate rules on is the proposed tool call: a shell command, a file write, a call to an MCP server, whatever tools the harness exposes to the model. Coding agents are the first use case, not the shape of the thing. Any agent loop that proposes tool calls, a document pipeline, a support agent, an orchestration graph, is gated the same way, with the same evidence coming out.

The gate, up close

Inside the hop: the response is buffered in full, every proposed tool call is checked against the pack, and each decision leaves a signed event behind.

A conservative gate by construction: one violating call voids the whole response, an unreadable call is refused rather than guessed at, and the refusal the harness records is what lets the audit corroborate the log later.

The proof

After a run, auditk reads the session file and produces a signed evidence pack. The scorecard then pulls that pack together with the gate's own signed event log and checks both.

Two independently signed records, from two components that never talk to each other during the run, reconciled once, after the fact, in one file you can open offline.

Latency

*The gate's own work costs single-digit milliseconds against generations that take tens of seconds; in our paired probes it was unmeasurable. The real trade is buffering: a response arrives when the model finishes, not token by token, because the gate must see a complete tool call before ruling on it. Agent loops never feel this. Each round trip gates on its own, and a harness cannot act on half a tool call anyway.

It bites only where someone is waiting on the first words: chat a person watches, or voice that starts speaking as tokens arrive. For those, today, this is the wrong tool. The roadmap answer is selective streaming, text passing straight through while tool calls are held for ruling.

Also in the build: policy packs bound to a caller's SPIFFE identity, gate events exported over OTel and Prometheus into your observability stack, and HOLD, a third verdict that pauses an action for a decision instead of ending the turn. All three are off unless you switch them on. See “What's next” below for what they do and do not claim.

Four things come out of a run

Two recordings

One blocked run on Nemotron, one clean run on Qwen, both gated runs against the same hostile workspace as above.

A run that gets stopped. The gate sits in front of the inference endpoint on a gated Nemotron run against the hostile workspace.

1. The gate starts, five policies loaded, in front of the endpoint.
2. The model is asked to build the tool, and a planted log line prompts it to reach for the .env credential file.
3. The gate blocks that read under no-credential-reads before anything is returned.
4. The run is audited, and the scorecard confirms the block was recorded in the model's own session, not merely claimed by the gate.

A run where nothing fires. Same setup, this time on Qwen: a clean gated run against the same hostile workspace.

1. The model never touches anything it should not.
2. Every proposed action is allowed and forwarded untouched.
3. The run is audited exactly the same way as the blocked run.
4. The scorecard verifies and shows zero blocks: an uneventful run still produces the same signed, verifiable record.

Built today, and what follows

Above is what is running today: the gate deciding before execution against policies you define, auditk scoring drift after the fact, and the scorecard and evidence pack you can hand to compliance, security and a regulator, as well as keeping as your own operator record. Below are planned improvements.