What you can prove, and what you can start from.

the check

kirto-gate audit verify

what a record names

the decision, the rule, the controls it cited, the actor

what it never contains

the prompt and the response

control packs

4 shipped, and a format you write your own in

What makes it evidence

A log is a record a system keeps about itself, in a store that system controls, and reading one means trusting both. Every decision Gate makes is signed by the node that made it with an ed25519 key and chained to the record before it on that node, so a trail carries its own proof.

kirto-gate audit verify reads an exported trail on a machine that trusts neither the gateway nor the store it came from. It takes the records in any order, with anything else interleaved, and reports every one that was altered, removed from the middle, moved or forged, by sequence number. Given the heads the cluster witnessed, it also reports a trail cut short. Exit status is 0 when every chain verified.

Somebody who trusts neither can check it. Put the same question to anything else that holds evidence on your behalf, this included.

What an assessor asks for

The question is always some form of show me what happened, and the answer is a record. Every access and guardrail decision is written to a signed record: the key that made the request, the rule that decided, the controls that rule named, and for a redaction, the entity types each rule rewrote and how many spans. Asked the other way round, what enforces this control is the same field read backwards.

Who can change a rule

The admin API denies by default, so anything a policy does not permit is refused. The policy is Cedar, and the admin API serves its own schema, so cedar validate and an editor check a policy file before it ships.

The caller is a person or a workload your identity provider vouched for, with roles from a claim it sets. There is no shared admin secret, so a change to a rule is attributed to whoever made it, never to a string in a config file. The break-glass path is recorded as loopback on an issuerless listener bound to the host, which claims only that the caller reached it.

A change lands in the same signed trail as the decisions that rule goes on to make, so who weakened a control and what it then allowed are one query against one trail. Configuration objects are addressable on their own, so a team can own its profiles without owning the deployment's authentication.

The data plane holds the same shape without the admin API. Deployment-wide access rules are the mandatory layer, and a team's own profile can narrow one and never loosen it, so a permissive profile cannot undo an org-wide refusal. Agents covers what a rule reads at each hop.

What the record never contains

The prompt and the response stay out of it. A redaction record names the entity types it found and counts them, and the matched text is neither in the record nor recoverable from it, so a trail exported for an assessor is no second copy of your traffic for them to assess.

Admitted requests are absent on purpose. The trail is decisions, and it says it is bounded instead of leaving a reader to infer that from a gap.

• Every decision under one control. The identifiers a rule cites are a field on the record, so the trail answers which decisions served a control without anybody parsing bodies to find out.
• Signed where it was decided. Each record is signed by the node that made it with an ed25519 key, and chained to the record before it.
• kirto-gate audit verify checks every chain: each record hashes to its entry, each entry links to the one before, each is signed by the key its chain started with, and no sequence number is missing.
• It runs where you are. The check reads an exported trail and trusts neither the gateway nor the store it came from. Exit status is 0 when every chain verified.
• A trail cut short is a finding. Give verify the heads the cluster witnessed and it reports a trail that stops before them.
• The rules were proved before they shipped. Each pack carries a suite run against its own rules, so what a rule decides is a test result.

Control packs, and writing your own

A pack is one reading of a regime, published as data: rules that cite the regime's controls, a suite that proves what those rules decide, and a page naming what it does not cover. kirto-gate pack add copies the rules into your deployment document, and after that the document is yours. Nothing reads a pack while a request is being decided.

Writing one is the same four files, added the way a shipped one is and held to the same checks before anything merges: every rule cites a control the pack declares with a citation, the fragment compiles the way the gateway compiles it, and the suite passes. A pack can name another in depends and attach its own identifiers to rules that pack already carries, so one rule decides once and the record names both regimes.

Which taxonomy a pack carries is yours. A control identifier is an opaque string the gateway never reads, so your governance platform's own identifiers ride on your own rules today with no pack, and a regime nobody has published a pack for is a pack you write.

A pack exists for a regime once somebody has read the text and written the rules, so this list grows and is never the measure of what the mechanism can carry. Today it is 4 packs citing 27 controls, adding 11 rules and pointing 12 controls at the mechanism that addresses them where no rule can. Each pack's page lists every control it cites, every rule that cites one, and what the pack leaves to you.

The packs are licensed under the Apache License 2.0, and the rest of Gate is not. A reading of a law is more useful to everyone when anyone can take it, correct it and publish the correction.