Security model
What you have to trust. And what you don’t.
The claim behind Auths is that a stranger can check your agent’s receipts without trusting you. That only means something if we are precise about what a verifier checks, what it never sees, and where the limits are.
What a verifier checks.
Authenticity
proof-unauthenticEvery receipt is signed. The signature must verify against the agent’s delegated key — resolved from its key history as it stood at signing time, so a later rotation can’t orphan an old receipt.
Scope
outside-agent-scopeAn agent’s scope is fixed at issue time and can only ever narrow what its root delegated. A call for a capability the grant never gave is refused.
Budget
usage-cap-exceededThe spend is not an operator claim — it re-derives from the signed cost on each receipt. A call that would cross the cap is refused before the downstream tool runs.
Expiry
agent-expiredThe delegation carries a TTL. Past it, nothing the agent signs passes.
Revocation
revokedA revocation is a signed event in the root’s key history. Once recorded, every verifier refuses the agent’s calls — no distribution to wait on.
# re-derive the spend from the signed receipts alone
$ auths-mcp-gateway verify-spend --log spend.jsonl \
$ --registry ./registry --agent <agent> --root <root>
✓ consistent — 2 call(s), $12.00 re-derived from signed costs
# flip one byte of a signed proof and re-run
$ auths-mcp-gateway verify-spend --log tampered.jsonl …
✗ tampered-proof — 51017ad1… failed verification (exit 1)
Every check fails closed: on any verdict but allowed, the downstream tool is never invoked.
What verification never depends on.
Verification runs where the verifier runs — a laptop, a CI job, an auditor’s machine. There is no account to create, no server to call, and nothing that phones home. The receipts and the key history they verify against are files you can copy, archive, and check years later.
A key carries its own rotation history, so the receipt verifies against the key that was valid at signing time — there is no trust-root snapshot to refresh and no window where a rotated key silently invalidates old evidence.
If auths.dev disappears tomorrow, every receipt still verifies.
The honest limits.
Authorized is not the same as wise
The gate proves a call was within its bounds — it does not judge whether the call was a good idea. A bounded agent can still spend its whole budget badly. Bounds cap the blast radius; they don’t supply judgment.
The root key is the root
Whoever holds your root key can delegate new agents. Keep it in hardware, and if it is compromised, rotate it — the rotation is itself a signed, verifiable event in the key history.
Concurrent devices can fork a history
Two devices rotating the same identity at the same moment can produce divergent histories. Verifiers surface the divergence instead of silently picking a side; you resolve it by removing the offending device.
No independent audit yet
The cryptography rests on standard curves (P-256 by default, Ed25519 supported) and every verification path is open source — but the implementation has not yet had an independent cryptographic audit. When it has, the report will be linked here.
Check our work.
The gateway, the verifier, and the CLI are open source — the audit path is code you can read, not a policy you take on faith.
Found a security issue? Email security@auths.dev with a detailed description. We follow coordinated disclosure.