A customer's payment agent initiates a USDC payout to a supplier. It settles. Everything works.
Agent authorization · New
A settlement record shows the money moved.
It does not show that the program moving it was allowed to. Where software initiates payments for a principal, Proof Rail records the mandate it acted under, and what was actually checked about that mandate.
The moment it matters
The customer disputes it: we never authorised that. Now somebody has to establish what the agent was permitted to do, weeks after the fact.
Your settlement record proves the money moved. The instruction the agent acted on lives in your own database, which is precisely the evidence a disputing counterparty will not accept, because you control it.
An illustration of the failure mode, not a customer incident. Proof Rail does not publish customer disputes.
What the record says
Before the agent acts, the principal signs a mandate: this agent, this act, this limit, this session. Proof Rail checks that signature against a public key the principal registered with us, and issues a record stating what was checked and when.
Six fields are covered by the signature: principal,
agent_id, act, scope,
session_id and valid_until. Change any one of them and the
signature stops verifying, so the record cannot display a mandate other than the one
that was actually signed.
The key must be registered before the mandate was granted
This is the rule the whole thing rests on, and it is the one most schemes leave out. A signature verifies just as happily against a key minted afterwards. Without an ordering check, a principal could produce a key and a signature for any authorization it later wished it had granted, and the record would look identical to an honest one.
So Proof Rail compares the key's registration time against the time the mandate was granted. A key that came second is refused. When no time is stated, the mandate is held to the moment Proof Rail first saw it, and the record says which basis was used rather than implying a stronger one.
An authorization stays self-reported unless a real mandate is attached
A mandate is not public. Nobody can visit a URL and confirm that a principal authorised an act, which is why a source name and a date cannot lift an agent authorization above self-reported the way they can for a company registry check.
The only thing that can be independently checked is the signature. So an authorization is recorded at Self-Reported by default, and reaches Source Checked only when a signed mandate verifies against a properly registered key. The level is earned, not requested: a caller may ask for the higher level and still be recorded at the lower one. Read the verification standard →
Rotating a key is not the same as losing one
Keys change. A rotated key was retired on purpose, so records it verified while it was active remain exactly as good as they were: the certificate reports the rotation and names the successor, without casting doubt.
A withdrawn key is different: if the private key may be in someone else's hands, anyone holding it could have signed anything, and the certificate says so plainly. A withdrawn key cannot be rotated: its standing cannot pass to a successor. Collapsing both events into one status would either alarm readers about routine hygiene or reassure them about a breach.
Anyone can repeat the check
The certificate names the key its mandate was verified against. That key is public
at /keys/:key_id, alongside its algorithm, its registration time and its
current standing. A counterparty does not have to take Proof Rail's word for
anything: they can fetch the key and verify the signature themselves.
Proof Rail never receives a private key. Requests carrying one are refused rather than stored.
Issuing one
Same API, same records bucket, no separate subscription. Register the public key once, then attach the signed mandate to the record.
POST /api/v1/mandate-keys
{"key_id": "treasury-2026", "public_key": "<base64url Ed25519>"}
POST /api/v1/records
{
"subject": "Payout agent",
"claim_type": "agent_authorization",
"evidence_level": "source_verified",
"evidence": {
"principal": "Example Payments Ltd",
"agent_id": "payout-bot-v1",
"act": "usdc_payout",
"scope": "single settlement, up to 5,000 USDC",
"session_id": "sess-4471",
"principal_key_id": "treasury-2026",
"mandate_hash": "sha256:...",
"mandate_signature": "<base64url>"
}
}
What this is not
Proof Rail records what was checked, against which source, at which time. It does not certify legal compliance, decide whether an act was wise, hold client assets, or replace your identity and access management. A record is evidence for a relying party to weigh, not a permission system, and not an endorsement.