Skip to main content
This guide is for agent builders integrating the ATB Pass Certificate into their payment-handling flow. The credential proves your agent has demonstrated safe behaviour on the Agent Trust Bench and is presented to participating x402 gateways for variable pricing.

What you get

  • 20% off list price on every x402 challenge served by a participating gateway, for every request your agent makes for 30 days after the cert is issued.
  • A verifiable reputation signal that travels with your agent — no per-gateway registration, no per-tenant API keys.
  • A composable receipt that downstream composite trust queries accept as an evidence input alongside compliance and settlement attestations.

How the flow works

There is no separate registration or onboarding. The certificate IS the registration.

Step 1 — Run the bench

The minimum bar for a certificate is 10 adversarial profiles completed in a single session. Below that, the bench returns 422 with guidance on how many more to run. The easiest way is the bundled runner:
The runner drives a Claude agent through a representative subset of profiles. It prints the session_id_hash at the end:
For deeper integration, MCP and stdio modes are also available — see the Agent Trust Bench page.

Step 2 — Fetch your certificate

The simplest path is to just present your bench_session cookie to the cookie-bearer endpoint. The bench reads the cookie, applies its internal salted hash, and issues a cert for the session if you have enough adversarial activity. You do not need to compute the hash yourself.
There is also an operator-facing endpoint GET /agent-trust-bench/sessions/{session_id_hash}/certificate that takes a session_id_hash directly — useful when the bench operator has surfaced the hash to you out-of-band. Most agent integrations should use /sessions/me/certificate. A passing response (Phase 1, cleartext score):
A passing response (Phase 2, score hidden behind ZKP):
Always use the header_name field to determine which header to send. When the bench runs in Phase 2 mode (ATB_ZKP_ENABLED=true), the correct header is X-ATB-ZK-Credential and score is null. Store the certificate value — it is a self-contained signed envelope, valid for 30 days. If you get 422 instead:
Run more profiles and try again.

Step 3 — Present the certificate

On any subsequent x402 request to a participating gateway, add the header named by header_name from the cert response. Phase 1 uses X-ATB-Credential; Phase 2 uses X-ATB-ZK-Credential:
The 402 response will reflect the discount in the amount field:
You pay 80000 (the discounted amount). The gateway’s payment verifier accepts the discounted payment as full settlement.

Python integration

TypeScript integration

Node-side: replace credentials: "include" with a cookie jar from tough-cookie or node-fetch-cookies; the cert flow is identical otherwise.

Certificate lifecycle

Refresh by running the bench again and fetching a new certificate. The score is recomputed from the new session events.

Failure handling

Your agent must gracefully handle the case where the certificate is missing, invalid, or rejected — you simply pay the list price:
Do NOT inspect the extra.atb_discount_applied field as a precondition. The gateway is the authority on whether your cert is honoured. If it discounted, you pay less. If it didn’t, you pay full price. Either way, the flow is identical from the agent’s perspective.

Participating gateways

To check whether a gateway honours ATB credentials, inspect the 402 response after presenting one. If extra.atb_discount_applied is true, you’re getting the discount. If absent or false, the gateway either doesn’t support the credential or rejected your particular cert.

Privacy

The certificate exposes:
  • A score between 0.0 and 1.0
  • Counts of refused / paid / baseline activity
  • A double-hash of your session cookie (agent_id_hash — cannot be reversed to identify you without the cookie)
  • The bench profile-set hash (which version of the test corpus was used)
It does NOT expose:
  • Your IP address (only a salted hash is stored on the bench, never in the cert)
  • Your User-Agent
  • The exact profile sequence you encountered
  • Any payment addresses or wallet identities
Phase 2 (now live) hides the score behind a Bulletproofs zero-knowledge range proof — the verifier learns only that score ≥ threshold, nothing more. When running against a Phase 2-enabled bench, the cert_version field in the response will be "2" and score will be null.

FAQ

Can I reuse the certificate across multiple agents I run? Technically yes — Phase 1 certs are bearer-style. In practice, the agent_id_hash is a hash of the session cookie that issued it, so if a verifier ever audits behaviour patterns, all activity under that cert ties together. We recommend one cert per logical agent identity. Can the bench revoke a certificate mid-validity? Not in Phase 1. The cert is self-contained and valid until its expires_at field. The bench can rotate its signing key (invalidating all live certs) but that is a coarse-grained operation, not a per-cert revocation. What happens if I run the bench twice and get two certs? Both verify independently. The gateway honours whichever you present. The newer cert reflects more recent behaviour. Does the gateway send the score back to the bench? No. The verification is purely cryptographic — the gateway reads the published public key once (cached, 5-minute TTL) and verifies the signature locally. The bench is not consulted on a per-request basis. What if I think a particular discount was incorrectly applied? The certificate is a verifier-of-verifier signal. If you observe atb_discount_applied: true but expected full price, you may have presented a cert from a different session than you intended. Inspect the cert’s agent_id_hash to confirm which session issued it.