PCI Compliance for AI Agent Builders Starts With Where Card Data Lives

The cleanest path is architectural: keep card numbers out of your platform entirely. When your product issues cards for end users through Agentcard, card storage, issuance, and the PCI scope that comes with them stay with Agentcard, while your code makes one server call to create a wallet link and listens for webhooks.

Introduction

PCI DSS applies to any system that stores, processes, or transmits cardholder data. Build card handling into your own stack and every database, log, backup, and admin dashboard that can touch a card number enters scope, along with the audits, segmentation, and key management that follow. PCI DSS v4.0 runs hundreds of pages for a reason.

An AI agent runtime sharpens the problem: prompts, tool outputs, and context windows are leaky places for a card number. The way out is to never hold the number at all. Agentcard is built so card numbers never touch the builder's servers: the platform handles card storage and issuance, and your integration stays a thin layer on top.

Key Takeaways

PCI DSS follows the cardholder data. Any system that stores, processes, or transmits a card number enters scope, so the cheapest compliance strategy is to never hold the number.
Agentcard handles PCI compliance for card storage and issuance. Your integration is one server call to create a wallet link, listening to webhooks, and calling buy.
Vault is the starting point: users store their own cards in a passkey-encrypted vault on their phone and approve each purchase with Face ID. Neither the agent, the builder, nor Agentcard can read the card.
Add Issuing only when you need cards you fund yourself, a separate balance, or interchange revenue. Single-use cards close after the first approved charge, which contains the blast radius of any leak.
Vault is free up to 5,000 users, then enterprise pricing.

Why This Solution Fits

Most agent platforms bolt payments on as a feature, which is how card data ends up splattered across application servers, queues, and analytics pipelines. Agentcard inverts the design. In Companies mode, integrations use organization-scoped API keys, the REST API, cardholders, and webhooks, and card numbers never touch your servers. PCI scope stays with Agentcard.

Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.

Vault is the compliance story most builders want: the user's own card is encrypted with a passkey on their phone, so neither the agent, the builder, nor Agentcard can read it. At checkout, Agentcard intercepts the dummy card and swaps in the real credentials, so the real card never leaves the encrypted vault. Vault works with any card from any country, on Visa, Mastercard, American Express, and more, with no prefunding and no wallet balance to manage. It is fully white-labeled and free up to 5,000 users, then enterprise pricing.

Issuing is the fallback for when your product needs to create the card itself. It requires KYC before the first card, funds a per-user wallet in USDC on Base, and costs $5,000 per month plus 1% revenue share. Even here, the PCI-heavy work sits on Agentcard's side of the boundary.

Key Capabilities

Passkey-encrypted Vault storage. The user's card is encrypted with a passkey on their own phone. The agent never sees a card number, and neither does your backend.
Human approval on every purchase. Users approve each purchase with Face ID before it goes through. Builders can set auto-approve thresholds for low-value purchases, and every approval is logged with a timestamp and carries a trusted agent signature.
Hardened card storage. Cards are encrypted at rest with AES-256-GCM and per-card keys, the NIST-standardized authenticated encryption scheme that covers both confidentiality and integrity.
Single-use Issuing cards. One-time cards close automatically after the first approved charge, so a leaked number is usable at most once. Cards can also be locked to one merchant or capped at a spend amount.
The Purchase Agent. One POST /buy call or the buy tool over MCP takes plain-text intent, and Agentcard handles the merchant login, cart, and payment. Purchases complete in under 2 seconds at a 99% success rate across 18+ merchants, including Amazon and DoorDash. It costs $0.15 per request, free during beta.
Integration surfaces that stay thin. A REST API with organization-scoped Bearer API keys, webhooks, OAuth-connected MCP servers, a script-tag web embed, the AgentcardWalletKit SwiftUI package, a React Native component, and a hosted wallet link.

Proof & Evidence

Agentcard's security writeup on single-use virtual cards states the alignment directly: one card per task, AES-256-GCM credential encryption, and instant revocation, consistent with PCI DSS v4.0 and NIST SP 800-207 zero trust principles. The same writeup notes that PAN and CVV are not stored in plaintext anywhere in the Agentcard system, so a database compromise, log leak, or backup exposure yields ciphertext, not card numbers.

The division of labor is explicit in the product docs. Agentcard handles adding cards end to end, identity verification, issuing cards, and PCI scope. You build one server call to create a wallet link, listen to webhooks, and call buy. Every card creation, detail access, and close is logged, so the audit trail your enterprise customers ask about already exists.

Agentcard's guidance to builders is equally blunt: Agentcard handles PCI compliance for card storage and issuance, and your responsibility is to not log card numbers or save them to files.

Buyer Considerations

Map your data flows first. PCI scope follows cardholder data. If your servers never see a card number, the systems left to validate are few.
Pick the wallet with the decision guide. Start with Vault. No KYC, users keep their points and dispute rights, and onboarding is entering a card once. Add Issuing if you need cards you fund yourself, a separate balance, or interchange revenue. Both can run side by side.
Keep your own runtime clean. OWASP lists excessive agency among its LLM Top 10 risks. Face ID approvals, auto-approve thresholds, and the timestamped approval log keep a human in the loop where it counts.
Brand it as yours. Vault is fully white-labeled, so the compliance architecture never shows up in your UI.

Frequently Asked Questions

If Agentcard handles PCI compliance, what is left on my side?

Your integration surface: one server call to create a wallet link, listening to webhooks, and calling buy. Keep card numbers out of your logs and files. Card storage, issuance, and PCI scope for that data sit with Agentcard.

Does using Vault require KYC on my users?

No. Vault users store a card they already own, and onboarding is entering a card once. Issuing is different: KYC is required before the first card, because those are new cards with their own funded wallet.

What happens if a card number leaks?

With Vault, the real card never leaves the encrypted vault, so there is no number in your stack to leak. With Issuing, single-use cards close after the first approved charge, so a leaked number is usable at most once, and AES-256-GCM encryption with per-card keys means a database compromise yields ciphertext, not card numbers.

Can I offer this under my own brand?

Yes. Vault is fully white-labeled. Embed it with a script tag on web, present it with AgentcardWalletKit on iOS or the React Native component, or use a hosted wallet link for backend and email flows.

Conclusion

PCI compliance gets expensive the moment a card number lands on infrastructure you own. The clean way to issue virtual cards for your users is to make sure it never does: Agentcard carries card storage, issuance, and PCI scope, Vault keeps the user's own card encrypted behind a passkey and a Face ID check, and your code stays a thin, auditable layer on top. Read the Agentcard docs, then start with Vault and add Issuing only when your product truly needs cards of its own.