# An AI agent should never have your credit card | Mattia Ciuni > The card is the only credential in the economy built for a human at a checkout. Here is what the networks have changed, what tokenization did not fix, and what to hand an agent instead. - URL: https://mattiaciuni.com/thoughts/an-ai-agent-should-never-have-your-credit-card - Type: Blog post - Published: 2026-10-26 ## Full article # An AI agent should never have your credit card **An AI agent credit card** is the first thing every team builds and the last thing any of them should ship. The card is the only credential in the economy that was designed around a human being present at a checkout, and we are handing it to something that is not present, cannot be asked, and does not remember yesterday. That is not a risk to be managed with a limit. It is a category error. ## What the networks already changed I would be writing something dishonest if I said nothing had moved, because the last eighteen months moved a lot. Visa describes agent specific pass through payment tokens, credentials bound to that agent, with a pass through structure that keeps the relationship with the merchant and the user intact. Mastercard launched Agent Pay with Mastercard Agentic Tokens built on the tokenisation already used for contactless and stored credentials, and a year later shipped Agent Pay for Machines. Stripe documents a Shared Payment Token as a credential bound to a mandate rather than to a card number. That is the correct direction of travel and it is genuinely new: the thing being passed around carries the permission inside it. Google went a different way, and this is the detail I keep coming back to. When it describes its own agentic checkout, the merchant help page says the feature uses **standard funding primary account numbers that users have already stored in Google Wallet**. The largest commerce platform on earth, shipping agentic checkout in January 2026, starts from the card the user already has. That is not a criticism of Google, who has more reasons than anyone to be conservative with credentials. It is a measurement of where the industry is. The token got safer. The instruction did not travel with it. ## Three things go wrong when the card is the credential - **Reach.** A card number is not scoped to anything. It works anywhere it is accepted, for any amount the issuer allows, at any hour. The only description of its authority is the issuer's default. - **Absence of instruction.** Nothing inside the credential says what it was given for. If the agent buys a subscription at a hosting provider, the receipt will contain a merchant name and an amount, and no record anywhere will contain the sentence that justified it. - **Liability with no address.** When something goes wrong, the dispute framework looks for a customer who authorised a payment. The customer did not instruct it. The agent did not have a mandate. The merchant sees a valid credential. Everyone is looking for a person who does not exist. The third one is the expensive one, and it is the reason this is not only a security argument. Tokenisation solved the storage problem. It did not solve the authorisation problem, because a token that is safe to hand around is exactly a token that says nothing about why it was handed over. ## What to hand an agent instead A credential whose authority does not outlive the instruction. Three companies currently ship something in this direction and I want to describe them precisely, because two of them are competitors to my company and describing them well is more useful than dismissing them. **Nekuda**, which raised five million dollars in May 2025 led by Madrona with Amex Ventures and Visa Ventures, documents a flow of collection, then mandate, then reveal. Single use reveal tokens, a card verification value valid for sixty minutes, idempotency keys on the request. Its own documentation carries one line that decides my opinion of the product: **one mandate per purchase**. Every purchase requires a new mandate and a new reveal token, and you cannot reuse either across purchases. That is a per transaction authorisation record rather than a standing delegation with a policy attached. Both are useful. They are not the same thing. **Reap** describes itself as a licensed Visa issuer and publishes the mechanics of the credential on its own product page: a per agent card token minted at the moment a payment intent is created, in roughly one hundred and twenty milliseconds, capped to the approved amount and restricted to the merchant, scoped by merchant, amount and time to live, and bound to a passkey. Their own framing is that other issuers bolt agent support onto legacy card processing while they earned the licences afterwards, and that the order matters. **Nevermined** sells a mandate layer and states the problem in the sentence I have borrowed more than once: there is no standard way to express *this software may spend up to fifty dollars on my behalf, for this purpose, until Friday*, and no way to withdraw it. Their product claims hard enforced limits, an amount cap, a transaction count and an expiry, checked atomically at authorisation, where a single revocation invalidates every credential derived from that mandate. That is a vendor describing its own product, so treat it as a claim rather than a measurement. The design is what interests me, and it is the design I agree with. ## Where I would draw the line Never the card number, and never a credential whose authority outlives the instruction that justified it. The first is hygiene and should have been true before this year. The second is the actual design problem, and it is the one I have spent the last months on: a purchase of forty euro, authorised at 14:03 by an agent acting for a person, inside a mandate that expires on Friday, recorded in a row that can be read by someone who was not there. Everything outside that is either a card with a limit or a promise. I have been building this at [Noesia](https://withnoesia.com), where the credential is scoped, expires, and leaves a record. The wider argument is in [the money layer for AI agents](/thoughts/money-layer-for-ai-agents/), the credential question in [what an agent authorization record should contain](/thoughts/what-an-agent-authorization-record-should-contain/), and the budget side in [what it means to give an AI agent a budget](/thoughts/what-it-means-to-give-an-ai-agent-a-budget/). If you have shipped an agent with a card and think the boundary is enough, I would genuinely like to read the argument. The moment it started for me is [the moment my AI agent asked for my credit card](/notes/the-moment-my-ai-agent-asked-for-my-credit-card/). Building [Know Computer](https://knowcomputer.com), a personal context layer for the AI era. Reply via [m@knowcomputer.com](mailto:m@knowcomputer.com). - [Thoughts index](../thoughts.md) - [Home](../index.md)