The provider's own ledger checks yours.

the second ledger

the provider's own admin usage API

the cadence

a round every hour, a day judged 48 hours after it closes

a breach needs both

2% of the larger side, and 10,000 tokens

the alert

kirto_gate_reconcile_judged_day_seconds going stale

The audit of AI you know about

The category beside this one sells discovery: AI nobody approved, a consumer chat tool in a browser, a vendor procurement never saw, a SaaS product with a model behind it. That is a different product. This audit reads the provider organisations you hold an admin credential for. It sees nothing in a browser, nothing at another vendor and nothing in an organisation you did not name.

What it answers is narrower and checkable: on the account you already govern, did every request go through Gate. Discovery finds the accounts nobody told you about. This says whether the one you did name is whole, which is the claim a control depends on and the one no ledger can make about itself.

The answer is a number you can defend: how far Gate's day and the provider's day diverged, per token class, against a threshold agreed in advance.

How a day is judged

A round runs every hour. A day is judged 48 hours after it closes, because the usage APIs trail and restate recent buckets. Four token classes are compared per day. A class breaches when it disagrees by both a ratio, 2% of the larger side by default, and a floor, 10,000 tokens by default. A ratio alone pages someone over a quiet Sunday, and a floor alone never fires on a busy account, so a breach needs both. The classes follow the provider's own convention on both sides, so the ledgers compare within a provider and never across one.

Set api_key_ids when you can. Scoped to the keys Gate routes through, drift in either direction is a hard signal. Unscoped, the query covers the whole organisation, and drift above what was metered may be a colleague's notebook on the same account: a real finding the first time and noise every time after. See Audit your metering against the provider.

Which way a breach runs

Which ledger is larger is the first thing a breach says. Metered above provider is Gate believing it sent more than the provider billed. That is double counting, and it is rare enough to deserve a bug report. Provider above metered is Gate having missed spend, and that is the direction this page exists for.

Even then the cause is usually a measurement gap. A usage field the scanner does not read, a stream that settled against an estimate, a WebSocket session whose frame decoder desynced and disabled itself: each leaves the same shape in the same direction. Audit your metering ranks the four causes in the order to check them, with what distinguishes one from another.

The alert is staleness

A stuck poller reports a drift of zero forever, and a drift gauge alone would call that healthy. The gauge to alert on is the most recently judged day going stale past the maturity lag plus the interval. The drift is read once that day is fresh. The three metrics and what each one says are in the metrics reference.

Every node answers

In a cluster every node meters and only the raft leader polls, and the result of polling is replicated. Every node recomputes the verdicts from the two replicated ledgers with the arithmetic the poller judged with, so each node gives the same answer and the answer survives a leadership change. The last failed round is written to the replicated state. Kept in the leader's memory, it would be lost to the failover a broken admin credential tends to cause. Before anything is configured the endpoint answers 501, so "not set up" and "set up and quiet" never look alike.

Threat model

The asset is the claim that every request on a provider account went through Gate. Nobody has to attack it. A colleague with the same API key in a notebook, a key minted in the same organisation and called directly, a scanner that missed a usage field: each leaves Gate's ledger short without leaving a trace in it. The control is a second ledger, built from the provider's admin usage API, compared with Gate's own per day and per token class, with a verdict when they disagree by more than you said you would tolerate. The limit is the provider. The audit reads an organisation you hold an admin credential for, on a provider that publishes a usage API. Most OpenAI-compatible vendors publish none.

This expands one entry of Threats and limits, which lists the others beside it.

• Two ledgers and a verdict. Gate meters from what the provider reported on the wire, and the provider's own admin usage API gives the second ledger. The claim that every request went through Gate gets a verdict instead of a promise.
• Two thresholds, so the signal survives a quiet week. A class breaches on both a ratio and a floor. A ratio alone pages somebody over a quiet Sunday, and a floor alone never fires on a busy account.
• The sign of a breach is the first fact it reports. Provider above metered is spend Gate missed. Metered above provider is double counting, and rare enough to deserve a bug report.
• Scoped to the keys you route. Set api_key_ids and drift in either direction is a hard signal instead of a colleague's notebook on the same account.
• Restatement is waited out. A day is judged 48 hours after it closes, because the usage APIs trail and restate recent buckets.

Start with Audit your metering, and read Metering for why the wire ledger is the one to bill from.