How it works

1. Grants. Each agent has grants: an audience (the service), methods, path patterns, a maximum body size and lifetime, and which actions need a person's approval. An unknown agent, audience or path is never granted.
2. Decide. A request to mint is DENY, REQUIRE_APPROVAL or ALLOW, deterministically. Paths servers interpret differently are denied first (path rules).
3. Mint. An ALLOW becomes a compact JWS: header {alg: EdDSA, typ: cain-action+jwt, kid}, claims iss, sub (agent), aud, iat, nbf, exp, jti and act {method, path, body_sha256}. A REQUIRE_APPROVAL becomes an ALLOW only with a CAIN-signed approval for exactly that action, and each approval works once.
4. Log. Every issuance is a SHA-256 chained, Ed25519-signed record holding the token's hash, never the token.
5. Use once. The service verifies signature, issuer, audience, time, method, exact path and exact body hash, then consumes the credential in a store shared by every instance. A second use fails, on any instance.

Two keys

The minting key is separate from CAIN-42's evidence key. It is a software key on the gateway host, labelled SOFTWARE_TEST in the published JWKS; a hardware-backed key is not implemented.

FIRME AI CORPORATION · CAIN-42 is a Byzantine trust fabric. Numbers marked "our own check" were run by us, not by an independent party. Nothing on these pages is a certification.