Why PQSafe vs the alternatives.
Scope: cryptographic authorization for AI agent payments. We compare PQSafe AgentPay against five common stacks teams reach for first. Honest about where each one wins and where it falls short for autonomous-agent spend control.
Capability matrix
| Capability | PQSafe AgentPay | Raw JWT (HS/RS256) | Raw AP2 (Google) | Stripe Issuing | OAuth 2.0 scopes | Plain ECDSA mandates |
|---|---|---|---|---|---|---|
| Post-quantum signature (FIPS 204 / ML-DSA) | ✓ | ✗ | ✗ 1 | ✗ | ✗ | ✗ |
| Policy-bounded spend (amount cap + recipient allowlist) | ✓ | ✗ | ✓ | ✓ | ◐ scope-level | ◐ per-field |
| Replay protection (nonce registry) | ✓ on-chain + D1 | ◐ jti claim | ✓ | ✓ idempotency keys | ✗ | ◐ DIY |
| Cryptographic revocation | ✓ envelope + key | ✗ token blacklist | ◐ | ✓ via API | ◐ via auth server | ✗ |
| Audit-grade evidence chain (7yr retention) | ✓ | ✗ | ◐ | ✓ Stripe-native | ✗ | ◐ DIY |
| Multi-rail (cards + bank + USDC) | ✓ via Airwallex/Wise/Stripe/USDC | ✗ | ◐ rail-agnostic by spec | ◐ cards only | ✗ | ✗ |
| Open-source reference impl | ✓ Apache-2.0 | ✓ many libs | ✓ | ✗ proprietary | ✓ RFC 6749 | ✓ |
| Standards body filed | ✓ FIDO Payments TWG 2 | ✓ RFC 7519 | ◐ vendor spec | ✗ | ✓ RFC 6749 | ✗ |
| Runs in browser | ✓ /verify + /generate | ✓ | ◐ | ✗ server-only | ✓ | ✓ |
| Runs in Edge Worker (CF / Vercel) | ✓ live on CF | ✓ | ◐ | ◐ via REST | ✓ | ✓ |
| Designed for autonomous agents (vs humans) | ✓ | ✗ session-token model | ✓ | ◐ human-cardholder default | ✗ | ◐ DIY |
| License | Apache-2.0 | RFC / various | Apache-2.0 | Commercial | RFC | N/A (you write it) |
Where each one wins
Wins when you need a stateless session token, you don't care about replay (or you accept a short TTL), and your audit window is measured in days. Universal library support, near-zero learning curve.
Wins when your stack is already aligned with Google's Agent Payments Protocol and you have buy-in on its mandate envelope shape. PQSafe extends AP2 rather than replacing it — AP2-PQ adds the post-quantum profile.
Wins for managed virtual cards with no infra to run. Massive rail coverage, fraud detection, and dispute handling baked in. Trade-off: closed-source, US-anchored, and not designed for autonomous-agent spend control.
Wins for delegated human access to APIs. Mature ecosystem, every major platform supports it. Trade-off: scopes are coarse permissions, not transaction-bound spend authorizations; replay and audit are out of scope.
Wins when you fully understand cryptographic systems and want zero dependencies. You write the canonicalization, replay registry, revocation, audit trail, and key rotation yourself — equivalent to building PQSafe from scratch.
Wins when your agents are signing transactions today that must remain verifiable into the post-quantum era, when your regulator (HKMA, MAS, FCA, FFIEC) requires 7-year audit retention, and when you want a standards-track path instead of a proprietary lock-in.
Where PQSafe wins specifically
- Post-quantum from day one. FIPS 204 ML-DSA-65 dual-signed alongside ECDSA P-256. No migration ceremony in 2030 when CRQC becomes plausible — signatures issued today remain verifiable through 2033 and beyond.
- Cryptographic spend envelopes for autonomous agents. Mandates carry per-transaction amount caps, recipient allowlists, currency constraints, time windows, and replay nonces — all signed, all verified, all enforceable at any rail. JWT and OAuth model sessions, not bounded spend.
- Standards body engagement. First public post-quantum proposal to the FIDO Alliance Payments TWG (chaired by Mastercard and Visa). Open letter at /fido-pq-letter. Vendor-neutral path, not a proprietary moat.
Does post-quantum matter for your use case?
Quantum computers capable of breaking ECDSA / RSA are widely estimated to arrive in the early-to-mid 2030s. That only matters to you if signatures you issue today must remain valid into that window.
- Banking, payments, insurance, healthcare: yes. Regulators mandate 7-year audit retention. HKMA published the world's first Quantum Preparedness Index in February 2026.
- Ephemeral sessions, short-TTL tokens, throwaway IoT auth: no. Use JWT or OAuth.
- Anything in between: depends on liability tail. PQ migration costs more later than now.
What PQSafe is NOT
- Not a payment processor. We sign the authorization envelope; rails (Airwallex, Wise, Stripe, USDC) move the money.
- Not a hosted ledger.
ledger.pqsafe.xyzis in pilot for Jun 2026 launch. No live transaction data shown there yet. - Not a fraud-detection system. PQSafe enforces policy at the cryptographic layer; behavioral fraud detection is complementary, not replaced.
- Not a card issuer. We wrap card issuance through partners (Airwallex Borderless is the default rail).
Migration paths
PQSafe's AP2-PQ profile extends AP2 with a post-quantum signature option. Existing mandate shape is preserved; you add the FIPS 204 signature alongside (or replacing) ECDSA. See the AP2-PQ RFC.
Keep Stripe as your card rail. Wrap each charge with a PQSafe-signed envelope verified before the Stripe API call. PQSafe enforces the agent's spend policy; Stripe handles the card mechanics.
Replace the JWT's payload with a PQSafe SpendEnvelope. Both verify in your existing middleware path. The migration adds policy bounds + replay + audit at the same place you were doing JWT validation.
Hardest migration to do alone, easiest to adopt PQSafe for: your codebase already canonicalizes, signs, and verifies. PQSafe gives you the post-quantum layer, the policy DSL, the replay registry, and the audit chain — without re-inventing each one.