When a human checks out online, there is at least a moment of friction: a confirmation page, a face ID prompt, a typed CVV. That friction is a security checkpoint. It forces a pause.
AI agents skip it entirely. They execute the checkout flow programmatically, with no confirmation screen and no human reviewing each step. The credential handling, the PII submission, the transaction authorization all happen inside an automated pipeline at machine speed.
That changes the threat model. The right response is not to slow agents down. It is to understand what "encrypted checkout" actually means in an agentic context, and to build credential models that are safe by construction.
What Checkout Looks Like for an Agent
A human checkout flow relies on the browser holding credentials briefly and submitting them over TLS. The card details are scoped to that session. The human closes the tab. Credentials disappear from the active environment.
Agent checkout does not work this way. The agent either calls a stored credential, receives card details through an API, or navigates a browser-based checkout with credentials supplied by its orchestrator. In any of these paths, the credentials exist somewhere in the agent's execution environment: its context window, its tool call arguments, its memory store, or its logs.
That exposure window is the core problem. Traditional encrypted checkout was designed for browsers and servers. Agents add a new surface: the inference environment itself.
Why Raw Card Data and Agents Do Not Mix
Raw card data, meaning the 16-digit PAN, the CVV, and the expiry, has specific legal handling requirements under PCI DSS. The CVV can never be stored post-authorization. The PAN requires strict access controls and encryption at rest.
LLM context windows satisfy none of those requirements. When an agent receives a raw PAN in a tool response or a user message:
- ▸The PAN exists in plaintext in the context window for the duration of the session.
- ▸It is likely logged by the inference provider.
- ▸It may appear in eval traces, debugging sessions, or fine-tuning datasets.
- ▸It persists in conversation history accessible to anyone with account access.
There is no practical way to make an LLM runtime PCI-compliant for raw PAN storage. The architecture that solves this keeps raw credentials out of the agent environment entirely. The agent sees only an identifier. The issuing infrastructure holds the actual data.
Network Tokenization: What It Does and What It Doesn't
Network tokenization is the practice of replacing a PAN with a network-issued surrogate value, a token, that the card network resolves to the original PAN at transaction time. Visa, Mastercard, and American Express all operate token service providers (TSPs) that manage this mapping.
The security benefit is real. A network token leaked from a merchant's system cannot be used at a different merchant without the TSP re-validating the token against the original PAN. Token-domain binding and cryptographic validation make stolen tokens significantly less useful than stolen PANs.
But network tokenization has a specific limitation that matters for agent systems: it does not isolate funding.
A network token still draws from the underlying account. If an agent is given a token that maps to a credit card with a $20,000 limit, a compromised agent can potentially transact up to that limit. The token protects the PAN from raw exposure. It does not protect the credit line from an agent that has gone off-script.
| Property | Raw PAN | Network Token | Per-Agent Virtual Card |
|---|---|---|---|
| Credential exposure | Full PAN in the clear | PAN hidden, token transmitted | PAN stays in issuing infra |
| Funding isolation | No | No | Yes |
| Blast radius on compromise | Entire credit line | Entire credit line | Card balance only |
| Merchant restriction | None | Configurable, not enforced by default | Network-enforced at issuance |
| Audit trail per agent | No | Partial (token-level) | Full, per-card |
| PCI scope for agent runtime | Full | Reduced | Minimal |
Tokenization is hygiene. Funding isolation is architecture. Both matter. Only one prevents a single bad agent action from touching your entire credit line.
Shared Card-on-File: The Specific Risk for Agent Systems
The standard SaaS model for payment credentials is card-on-file: a customer saves a card once, and subsequent purchases charge against it. For human users this is convenient. For agent systems, it creates a systemic risk.
When multiple agents or workflows share a single card-on-file, they share the same blast radius. A bug in one agent, a successful prompt injection, or a misinterpreted instruction can result in unauthorized charges against the same account every other agent and your own spending relies on.
This is not hypothetical. Agent workflows retry failed transactions. They operate continuously. They can execute dozens of authorization attempts in seconds. A shared card-on-file, combined with a retry loop that fails to detect duplicate charges, can accumulate significant spend before any monitoring catches it.
Shared credentials also destroy audit clarity. When multiple agents transact on the same card, isolating which transaction came from which agent requires external logging that was maintained correctly throughout. If that logging lapses, or if the agent's context was cleared, the trail is gone.
The correct model for production agent systems is one credential per agent or per workflow. Not because shared cards cannot have limits set on them, but because those limits are software guardrails that can fail. Funding isolation is a hardware guarantee that cannot fail silently.
Token Scoping: The Protocol-Level Controls That Actually Constrain Agents
Beyond the funding question, encrypted checkout for agents requires that credentials be scoped at the protocol level. A scoped credential carries its constraints with it, enforced by the issuing infrastructure and the card network, not by the agent's own logic.
The key scope dimensions for agent credentials:
Merchant binding. A credential restricted to a specific merchant ID or domain can only authorize at that merchant. The network declines any other authorization attempt. The agent cannot override this.
MCC restriction. Merchant Category Codes classify businesses into categories. A card restricted to MCC 7372 (prepackaged software) cannot transact at a gift card retailer (MCC 5999) or a cryptocurrency exchange (MCC 6051), regardless of what the agent attempts.
Amount ceiling. A hard limit on total authorization amount, enforced at the network level, means the agent cannot request an authorization above a configured threshold. Policy logic does not need to catch it. The network rejects it.
Validity window. Credentials that expire after a short interval, minutes or hours rather than days, limit the exposure window if credentials are ever leaked or the agent's behavior deviates from intent.
Single-use flag. A credential configured for one transaction becomes inert after it is used. If an agent logs the credential, reuses it in a retry, or exposes it in an error message, the second attempt is declined at the network level.
These controls do not require the agent to behave correctly. They are enforced outside the agent's execution environment, at the issuing bank and card network level. This is the meaningful distinction between encrypted checkout and policy-based controls: policy can be misconfigured, delayed, or bypassed by a compromised agent. Network-level enforcement cannot.
What Encrypted Checkout Actually Means at the Protocol Level
Putting the pieces together, encrypted checkout for AI agents has four components:
1. Credential isolation. The agent never sees the raw PAN or CVV. It receives a card identifier, a masked PAN, or a short-lived token. The actual credential lives in PCI-compliant issuing infrastructure. Even if the agent's context is logged or exfiltrated, the data is not usable.
2. Scoped authorization. The credential the agent holds can only authorize within defined constraints: specific merchants, MCCs, amounts, and time windows. These constraints are enforced at the network level, not by the agent's own logic.
3. Intent declaration. Before credentials are released, the agent declares its intent: the merchant, the expected amount, the purpose. That declaration is logged server-side, creating an immutable record that predates the transaction. When the transaction settles, it is matched against the declaration. Mismatches trigger alerts.
4. Funding isolation. The credential draws from an isolated balance, not from a shared credit line. The agent's maximum blast radius is bounded by design, not by a policy rule that might fail.
Any implementation that skips one of these components has a gap. Credential isolation without scoping means a compromised token can be used at any merchant. Scoping without funding isolation protects the PAN but not the account. Intent declaration without credential isolation means the agent is logging a plan while holding raw card data.
The Risks Agents Actually Face at Checkout
It is worth being precise about the threats, because different threats require different defenses.
Prompt injection. A malicious merchant page or API response can embed instructions that redirect the agent's behavior. An agent processing a product listing might receive instructions telling it to add 100 units, ship to an alternate address, or charge a different payment method. MCC locks and merchant binding stop the payment from completing at an unauthorized merchant. Spending limits cap the damage if the injection succeeds within an authorized merchant.
Context window leakage. If raw credentials are in the agent's context, they are in the logs. Every tool call, every error trace, every eval run that captures the context also captures the card data. The defense is keeping raw credentials out of the context entirely.
Retry amplification. Agents that retry failed transactions without idempotency checks can generate duplicate charges. A single-use credential or a per-intent card that is deactivated after the transaction closes completes prevents retry loops from compounding charges.
Token reuse across sessions. If an agent stores a credential between sessions, that credential is potentially accessible to future sessions, different agent instances, or log readers. Short-lived credentials with explicit validity windows expire before they can be reused inappropriately.
Blast radius on card compromise. If a credential is exposed, the damage should be bounded. A per-agent virtual card with a $500 balance is a fundamentally different outcome than a shared credit line with a $25,000 limit.
Why Per-Agent Virtual Cards Are the Right Credential for Checkout
We designed Signets cards to be safe to hand to an agent. Not safe in the sense of hoping the agent behaves, but safe in the sense that the credential's own properties bound the damage if the agent does not.
Each Signets card is:
Scoped at issuance. Merchant locks, MCC restrictions, and spending limits are configured when the card is created. They are enforced at the network level. The agent cannot negotiate wider access by requesting different token parameters.
Isolated in funding. Each card draws from its own balance. A Signets card cannot overdraw into a shared credit line. The worst case is the card's balance.
Invisible to the agent's context. The agent interacts with card identifiers and masked PANs through the MCP server. Sensitive credentials are retrieved from PCI-compliant infrastructure only at the moment of checkout, not stored in the agent's context or returned in logs.
Tied to a declared intent. Before a card is used, the agent submits an intent object capturing the merchant, expected amount, and purpose. That record exists before the transaction. If the transaction deviates from the intent, the system flags it. The agent cannot retroactively explain an unexpected charge.
Disposable. Cards can be configured as single-use. After the transaction completes, the card is inert. A leaked card number from a receipt, a log, or a merchant's database is useless.
We also support x402 payments and stablecoin wallets for merchant contexts that accept them, and bank rails including ACH, Wire, FPS, and SEPA for cases where card infrastructure is not the right fit. The card is the backbone of encrypted checkout, but it does not have to be the only rail.
The question operators should ask before deploying an agent into a checkout flow is: if this credential is exposed, what is the maximum damage? For a raw PAN shared across workflows, the answer is uncomfortable. For a single-use, merchant-locked, balance-isolated Signets card, the answer is bounded by design.
Signets issues programmable virtual Visa cards for AI agents, with hard spend limits, merchant locks, MCC controls, approval workflows, and audit trails built in. If you are building agent checkout flows and want credentials that are safe by construction, we should talk.