Prove permission.

Bind authority to an exact action. Verify it locally. Execute only what was proven.

Start with the mental model Verify your first proof

Authorization, proven

action: deploy sha256:a91e…
audience: release-service / prod
authority: root → team → release-agent
constraints: canary · before 14:32 UTC

Authentication says who. Auths proves what.

Auths packages the authority chain for an exact action into a proof the receiving service can verify for itself. Trust is explicit, delegation only narrows, and the verified action—not the caller’s original request—becomes the executable command.

Understand the model

Learn how trust roots, bounded grants, canonical actions, and three-way decisions fit together.

Read the concepts →

Build an integration

Start from the embedded Rust facade, the WebAssembly boundary, or the downstream application SDK.

Choose a surface →

Implement the protocol

Use the normative V1 specification, deterministic CDDL, stable result codes, and canonical corpus.

Open Protocol V1 →

Review the security boundary

Inspect trust assumptions, bounded verification, adapter assurance, fuzzing, and conformance gates.

Review security →

One platform, explicit boundaries

01 / Acquire

Gather live evidence

auths-proof-apps

02 / Exchange

Carry proof bytes

auths-proof-exchange

03 / Verify

Resolve authority

auths-proof

04 / Execute

Run sealed command

auths-proof-apps

The offline kernel never acquires evidence, opens a network connection, reads runtime state, or executes an application command. Those responsibilities are owned by the downstream repositories and remain explicit at integration time.