Permit Verification
When AtlaSent evaluates an action and returnsallow, it issues a permit token — a cryptographically signed, single-use token that proves the authorization happened.
The token must be verified before the action is considered complete. Verification confirms:
- The token was issued by AtlaSent (not forged)
- The token matches the action being performed (not replayed from a different request)
- The token hasn’t been used before (not replayed from the same request)
- The token hasn’t expired (1-hour TTL by default)
The verification call
outcome field):
There is no
verified/expired/consumed/invalid/error outcome vocabulary
on the wire — those distinctions live in verify_error_code under a deny
outcome. Only outcome: "allow" (valid: true) means the action is authorized.
Why single-use tokens
A permit token is single-use by design. Once verified, it’s consumed and cannot be re-used. This prevents two attack classes: Replay attacks: an attacker captures a valid permit token and uses it to authorize a different action (or the same action again). Single-use tokens make this impossible. Permit stockpiling: a system accumulates pre-approved permits for future use, bypassing the real-time authorization check. With single-use tokens, each permit authorizes only the specific action it was issued for.The withPermit pattern
The idiomatic SDK pattern binds evaluation, execution, and verification together in one call:
Offline verification
Permit tokens are part of the audit chain export. The entire export is Ed25519-signed with AtlaSent’s published signing key. To verify an export offline:What gets recorded
Every permit verification adds a record to the audit chain:
The chain is append-only. Verification records cannot be deleted.
Next steps
- Audit verification — export and verify the full audit chain offline
- Permit concept — full permit lifecycle reference
- The deploy gate step — the most common permit use case
- AI Agent Governance — using permits in agent workflows