Skip to content

Overview

The problem

AI agents now write a growing share of the code that ships. But the signal that a change is correct still comes from the same system that produced it: a green check from the platform that wrote the diff, a log you have to take on faith.

That is fine until it isn't — an auditor asks you to prove a change passed its checks six months ago; a customer asks why they should trust code an agent wrote; a regulator asks for evidence, not a screenshot. "The dashboard was green" is not an answer you can hand to someone who wasn't there.

The missing piece is an independent, re-verifiable proof: not that the agent says it passed, but proof you can re-check yourself, without trusting the agent, the platform, or us.

The solution

auths-curve is a neutral referee that sits between "the agent wrote it" and "it merged." For every change it produces a small, self-contained evidence bundle:

  1. A gate re-runs the correctness checks — RED-first, so each check is proven able to fail before it is allowed to pass.
  2. An agent identity signs the verdict — a machine actor with a verifiable identity, not a borrowed developer key.
  3. An independent witness counter-signs it — a second, distinct key, so the referee cannot bless its own work.
  4. The verdict is anchored in a transparency log with an offline inclusion proof, and bound to the change it describes.
  5. Anyone can re-verify the whole bundle offline, from a clone, with only a public key.

Then a CI merge-gate turns that proof into policy: a change doesn't merge unless a valid, re-verified bundle exists for it.

flowchart LR
    A[agent writes<br/>a change] --> G[gate re-runs<br/>checks · RED-first]
    G --> S[agent signs<br/>the verdict]
    S --> W[witness<br/>cosigns]
    W --> T[anchored in a<br/>transparency log]
    T --> V{re-verify<br/>offline}
    V -- valid --> M[merge allowed]
    V -- invalid --> B[merge blocked]

What you are trusting

The point of the design is how little you have to trust:

You trust You do not have to trust
A public key you pin in the repository Any server, API, or account being up or honest
The math (standard signatures + a Merkle log) The agent's own claim that it passed
That a witness key is independent of the signer A single party marking its own homework

There is no phone-home: verification reads only the public key and the files in the repository. The repository is the root of trust. If the evidence is edited, the signatures and the hash-chain stop verifying — loudly.

Why "RED-first" matters

A check that has never been seen to fail proves nothing — it might be inert. Every check here keeps a counterexample (a trap) it must reject. Before a check is allowed to certify a change GREEN, the referee confirms it goes RED against its counterexample. So a weakened or vacuous check is caught mechanically, not trusted.

Where it fits

auths-curve rides the standards the supply-chain world already consumes — DSSE in-toto attestations, an RFC-6962 transparency log, OTEL trace context — so the proof drops into existing pipelines rather than replacing them. It is a referee, not a build system: it decides whether a change is provably correct and makes that decision re-checkable, then gets out of the way.

Ready to see it? The Quickstart runs the whole chain in one command; How it works opens up the architecture.