Status
The guarantee
When enabled, a card number is revealed only after the code requesting it has proven, with a hardware-signed attestation, that it is an approved image running in a confidential enclave with debugging disabled. If that proof cannot be made, no card is revealed.The problem it addresses
On the standard path, the card number is revealed inside the proxy and typed into the merchant page. The proxy is Agent Vault infrastructure, so at that instant an operator with sufficient access to the running proxy could in principle observe the number. Attested detokenization narrows where that reveal can happen: only inside an enclave whose identity is cryptographically proven, running an image whose digest is on an allow-list, with debugging disabled and no command or environment overrides.How it works
Attestation check
The in-proxy verifier is a defence-in-depth re-check. The authoritative
control sits outside the application: the vault credential is released only to
an attested, approved image.
The application never fabricates a passing attestation. A valid attestation token
is issued only by the enclave’s launcher to a workload running inside a
provisioned enclave. Outside an enclave, no such token exists.
Attested checkout
Separately from the gate above, the SDK exposesattestedCheckout(plan). It hands
a whole card checkout, described as a declarative plan, to the enclave. The
enclave reveals the card and types it in its own browser, so the card number is
never in the proxy process. You get back last4 and, where one was recorded, the
transactionId.
The plan
Step types:goto, click, fill, fillSecret, waitFor and wait.
screenshot steps are refused: they would write a caller-named file inside the
enclave. Use page.screenshot() on your own session instead.
The shape rule
fillSecret must be followed by exactly one state-changing action, and it
must be a click on the merchant’s pay button. Only wait and waitFor may
follow that click.
A malformed plan is refused with
invalid_plan before any transaction is
recorded.
What this does not protect against
The interactive fill path
The interactive fill path
Enabling attested checkout does not change the standard interactive path. A card
token filled on your own session’s page is still revealed in the proxy.
Cards with a spending cap
Cards with a spending cap
The page renders in the enclave, so the proxy cannot read the authoritative order
total, and an enforced cap refuses an unknown amount. Use the standard fill for
capped cards. Any
amount you pass is recorded for audit only and is not trusted.Hosted card fields
Hosted card fields
The plan has no frame-targeting step, and the enclave fills the top-level page. A
card field inside a hosted payment iframe cannot be filled this way.
Anything after submission
Anything after submission
A 3-D Secure step, one-time code or CAPTCHA raised after the pay click belongs to
the enclave’s browser. Neither the agent nor a
challenge handoff can reach it.
Merchants that require a CVV
Merchants that require a CVV
The plan carries one secret, the card number. A live CVV is typed into your own
session’s page, not the enclave’s, so these checkouts must use the standard fill.
Tunnelled sessions
Tunnelled sessions
Where the deployment relays the enclave’s traffic, an attested checkout in a
tunnel-required session (
tunnel: true) leaves through your tunnel like any other
session. Where it cannot relay the enclave, that session is refused with
attested_checkout_unavailable and nothing is recorded: open a session that does not
require the tunnel, or fill the card token on your own page. See
Tunnelling and attested checkout.A dropped connection
A dropped connection
If your connection closes after the plan is submitted, the call fails on your side
while the enclave continues. There is no idempotency key for a retry to join the
run. Do not resend the plan until you have checked the merchant’s order state or
the session on the dashboard.
Agent Vault's own infrastructure outside the enclave
Agent Vault's own infrastructure outside the enclave
The enclave narrows where the card number is revealed. The authorization
decision, the vault token id and the merchant page are unchanged, and the merchant
still receives a real card number.
How to verify
1
Call attestedCheckout on your deployment
Pass a test card token and a valid plan from an untunnelled session.
2
Read the result
Where no enclave is configured, the call fails up front with
attested_checkout_unavailable and nothing is recorded. Where the gate is on
and attestation cannot be proven, reveals fail with attestation_required.
Both confirm the path fails closed.3
Check the record
On a deployment where the path is live, a successful run returns the card’s
last4, and the session normally appears in Activity
like any other checkout. Activity recording is best effort, so the returned
last4 is the proof, not the entry.Error codes
Retry guidance differs sharply between these codes. The full table is in the error reference.What it requires
Attested checkout works only on a deployment that runs an attested enclave and has turned the feature on. That is set up per deployment. There is nothing to enable from the SDK, the MCP server or the dashboard. To tell whether it is on for you, make the call described in How to verify. A refusal withattested_checkout_unavailable
before anything is recorded means it is not available on your deployment. This
page does not yet document any other indicator.
Related
Card storage
The standard reveal path, which is on today.
Security model
What this narrows, and what it does not.