PASETO Proof Tokens for AI Agents

How cryptographic proof tokens create verifiable accountability for autonomous AI agent actions — and why PASETO is a better choice than JWT.

What Are Proof Tokens?

When an AI agent acts on behalf of its owner — making a purchase, booking an appointment, or calling an external API — the counterparty (the service receiving the request) needs to know: was this agent actually authorized to do this?

A proof token answers that question cryptographically. It's a signed document that contains the authorization decision, the action details, and a timestamp. The counterparty can verify the token independently using the owner's public key, without contacting the authorization server. This is the foundation of verifiable agent accountability.

Why PASETO Over JWT?

JSON Web Tokens (JWT) are the most widely used token format, but they carry well-documented security pitfalls that make them a poor choice for high-stakes authorization proof:

  • Algorithm confusion attacks — JWT allows the token to specify its own signing algorithm in the header. Attackers have exploited this to forge tokens by switching from asymmetric (RS256) to symmetric (HS256) verification, using the public key as the HMAC secret.
  • The "none" algorithm — JWT supports an alg: "none" header that disables signature verification entirely. Libraries that don't explicitly reject this accept unsigned tokens as valid.
  • Key confusion — JWT's flexibility in algorithm selection creates a class of vulnerabilities where the wrong key type is used for verification.

PASETO (Platform-Agnostic Security Tokens) eliminates these issues by design:

  • No algorithm negotiation — The token version and purpose determine the cryptographic suite. There is no header field to override.
  • No "none" algorithm — Every PASETO token is cryptographically signed or encrypted. Unsigned tokens are not representable in the format.
  • Versioned protocols — Each PASETO version (v1–v4) locks in a specific set of algorithms. v4.public uses Ed25519 signatures exclusively.

PASETO v4.public — The Token Format

OpenLeash uses PASETO v4.public tokens for all proof issuance. The v4.public purpose means the token is signed (not encrypted) with an Ed25519 key, making it readable by anyone but only creatable by the key holder.

A v4.public token has this structure:

  • Header — Always v4.public., identifying the version and purpose.
  • Payload — JSON claims including the action type, agent ID, decision, timestamp, and expiration.
  • Signature — Ed25519 signature over the header, payload, and optional footer.
  • Footer (optional) — Unencrypted metadata like the key ID (kid) used for key rotation.

What's Inside a Proof Token

When OpenLeash issues a proof token after an ALLOW decision, the token claims include:

  • action_id — Unique identifier for this specific action.
  • action_type — What the agent did (e.g., purchase, book_appointment).
  • agent_id — Which agent performed the action.
  • decision — The authorization decision (ALLOW).
  • iat — When the token was issued.
  • exp — When the token expires.
  • payload — Action-specific data (cost, vendor, resource details).

These claims give the counterparty full context about what was authorized, by whom, and when — all cryptographically bound to the owner's key.

Offline Verification

One of PASETO's key advantages for AI agent authorization is offline verification. A counterparty only needs the owner's public key to verify a proof token. There's no callback to OpenLeash, no network dependency, and no centralized verification service.

This matters for several reasons:

  • Resilience — Verification works even when the authorization server is unreachable.
  • Privacy — The authorization server doesn't learn which counterparties the agent interacts with.
  • Performance — No additional network round-trip for verification.
  • Decentralization — Any party with the public key can independently verify. No trust in a central authority is required.

OpenLeash also supports online verification via POST /v1/verify-proof for counterparties that prefer server-side validation or don't have access to the public key.

Multi-Language SDK Support

Proof token verification is available in all three OpenLeash SDKs:

  • TypeScript — verifyProofOffline() and verifyProofOnline()
  • Python — verify_proof_offline() and verify_proof_online()
  • Go — VerifyProofOffline() and VerifyProofOnline()

All three SDKs handle the Ed25519 signature verification, claim parsing, and expiration checking. The counterparty integration is typically a few lines of code.

Read more about how AI agent authorization works, or explore the SDK documentation to start verifying proof tokens.