Auths

Auths lets an AI agent act only with authority you can check. An action goes through only if it matches exactly what the right people approved and stays within the agent's own limits. A gateway holds the provider credential, so the agent never sees it. Afterwards, an auditor can re-verify each action offline.

This repository is prelaunch and has not had an independent security review. See Status.

See it work

Your agent may refund a Stripe payment only when two of your three managers approve that exact refund, and only up to 50.00 per refund and two refunds a day. The Stripe key lives only in the gateway, and an auditor checks every refund offline. You need Python 3.9+, Rust, and a checkout of this repository.

cd examples/stripe-refund-approval
python3 -m venv .venv && . .venv/bin/activate
pip install maturin
maturin build --profile python-extension --manifest-path ../../bindings/python/Cargo.toml --out dist
pip install dist/auths-*.whl
cargo install --locked --path ../../product/runtime/auths-gateway --features loopback-provider
python journey.py --gateway "$(command -v auths-gateway)"

The first build takes a few minutes. The journey then runs in a few seconds against a local Stripe double, and never calls Stripe. It checks each of these:

Attempt	Result	Stripe calls
A 15.00 refund approved by managers A and B, and a 40.00 refund approved by B and C	submitted	2
A 90.00 refund, above the agent's 50.00 limit	refused	0
A refund only manager A approved	refused	0
A third refund on the same day	refused	0
Four tampered audit bundles: a flipped proof byte, a swapped action, a replayed outcome, and replaced trust	the offline audit flags each	none

Each refusal happens before the gateway touches the Stripe key. CI runs the same journey from the packaged wheel.

The example's README walks through the run in 10 steps, and shows how to run it against Stripe test mode with your own test key.

What you get

• Approval of the exact action. Approvers sign the exact request (this refund, this amount, this payment), not a permission scope. A plan can require K of N approvers.
• Limits per agent. The agent's grant carries its limits, such as a maximum refund and a number per day, and the gateway enforces them. Delegation can narrow authority but never widen it.
• The credential stays in the gateway. The gateway verifies the proof and checks the limits before it uses the provider credential. The agent never holds the credential.
• Offline audit. auths-gateway audit re-verifies each action in an exported bundle, with no network, and flags tampering. It cannot show that no action was left out of the bundle.
• Checked independently. A Rust verifier and independent Go and TypeScript verifiers agree on a shared corpus of test vectors. Lean proofs cover the delegation ordering and the K-of-N approval algebra, not the whole verifier.

What it does not claim yet

• The example uses development keys and a Stripe double. No provider route is qualified for production; the Stripe test-mode run is one you do yourself.
• No independent security review has been done.
• The gateway's default store is single-host. A PostgreSQL store lets several gateways share state, but its production review is not finished.

The claim ledger states what each part establishes and what it does not.

Other ways in

To…	Start with
Require approvals from K of N people	Approval quorum
Verify a proof or authenticate an identity from Python or TypeScript	Recipes
Put another HTTP API behind the gateway	The example's recipe.json and the gateway specification
Derive gateway operations from an OpenAPI document	OpenAPI-derived operations
Protect one action in your own application, without a gateway	Application-owned adapter
Write a profile for a new provider	Profile authoring
Use the typed application SDK through a local agent (no live provider route is promoted yet)	SDK contract, then the local-agent guide
Sign Git commits under any principal method, or run the gateway with production trust	Git object signing and the trust and signing runbook

Package documentation: Python and TypeScript.

How it fits together

This is one monorepo in five layers. A layer may depend only on itself and the layers above it in this table; architecture.toml enforces that.

Layer	Holds
core/	The offline verification kernel: protocol model, canonical encoding, signatures, delegation, verification, and the canonical test corpus
exchange/	Moving proofs between parties: formats and transports
product/	The gateway, SDK runtimes, stores, custody, and provider integrations
bindings/	Python, TypeScript, WASM, and Go surfaces, and the independent verifiers
demos/	Demos, test kits, and benchmarks

The kernel checks a proof in fixed stages, and VerifiedAction has no public constructor:

untrusted bytes
  -> DecodedProof
  -> ResolvedProof
  -> ControlVerifiedProof
  -> VerifiedAuthority
  -> VerifiedAction

The language-neutral entry point is verify_v1(proof_cbor, canonical_action_cbor, trusted_context_cbor) -> verification_result_cbor. The kernel reads no clock, environment variable, network, filesystem, or key. Every trust anchor, evaluation time, status snapshot, policy, and limit is an explicit input. To try it, run cargo run -p auths-proof-offline-example.

Identity packets and Iroh transport also work without any authorization layer: run cargo run -p auths-identity-iroh-demo, then open http://localhost:8080.

Develop

Read AGENTS.md, the repository contract, before changing code, then CONTRIBUTING.md. The program board shows current status and what is next.

cargo xtask arch          # layer and dependency rules
cargo xtask wire          # the canonical corpus is byte-stable
cargo xtask conformance
cargo xtask fuzz-smoke
cargo xtask ci            # the authoritative gate

Canonical .cbor fixtures change only through cargo xtask wire --update, for an intentional, reviewed protocol change.

Status

Prelaunch: there are no external users yet, and no independent security review has been done. Passing the corpus, fuzz, and WASM-equivalence checks is not such a review. Report suspected vulnerabilities privately, as described in SECURITY.md.

License

MIT or Apache-2.0, at your option.