Stripe has made the best case yet that an agent does not need to see your card number to shop for you. Link can issue a single-use credential for an approved purchase, and consumer agents including Instinct, Grok Bot, and Meta's Muse are putting that model into production. That is real progress. It also makes the next architectural question clearer: does the agent have permission to use your wallet one purchase at a time, or does it operate from a bounded account of its own?
Delegation got much better
Link's wallet for agents is not a raw card handed to a model. A consumer connects Link to an agent through OAuth, reviews the purchase request, and approves the total before Link releases a credential. At businesses that accept Link, the agent can use the consumer's preferred saved payment method. Elsewhere, Link issues a single-use virtual card scoped to the approved purchase. The agent never sees the underlying payment details.
That design closes the most obvious credential-theft hole, gives the user a clear approval moment, and works across ordinary ecommerce today. Meta's Muse now uses it to shop across the internet, following integrations with Instinct and Grok Bot. Stripe has paired good security architecture with something just as important: distribution through a consumer wallet with about 300 million users, by Stripe's count.
The question moved up the stack
Once every approved purchase gets a scoped credential, the interesting distinction is no longer safe card versus unsafe card. It is delegated wallet access versus a financial account designed for autonomous work. Link's current consumer flow asks a person to review each spend request. Stripe says configurable spending limits and purchases without additional approval are planned. That is a strong fit for personal assistants shopping on behalf of a human.
Long-running agents create a different requirement. A procurement agent, operations agent, or software agent paying for APIs needs standing authority that is narrow, observable, and revocable without turning every transaction into a human checkout. The owner should be able to fund a bounded account, attach policy to the agent and workflow, define an exception path, and let compliant transactions run while everything else stops.
A prompt is a suggestion.
A spend limit is a fact. Agents need to live inside facts.
Retry loops meet the circuit breaker
Agents retry failed operations; that is correct engineering. With payments, it is also how duplicate charges happen: an ambiguous checkout response, a retry, and now two charges, then six. Run agents continuously across workflows and the spending accumulates at machine speed, faster than any human review cycle.
A Link credential scoped to one approved purchase sharply limits this risk, which is exactly what good delegation should do. A funded agent account adds a second boundary for autonomous workflows: even if an approval rule, merchant control, or retry detector is wrong, the workflow cannot spend more than the balance assigned to it. Once those funds are exhausted, the agent can retry forever and collect declines.
A credential is not an account
Single-use cards and Shared Payment Tokens make transactions safer and easier to attribute, but the underlying money still belongs to the consumer wallet. That is the right abstraction when the user is present. It becomes awkward when several agents share an operating budget, collect revenue as well as spend it, move money over different rails, or need a finance team to reconcile authority and outcomes by workflow.
An agent account creates a durable boundary around that activity. It can hold a bounded balance, identify the owner and acting agent, retain the policy and approval that authorized each transaction, and keep agent activity separate from the human's everyday statement. The credential becomes one short-lived instrument issued by the account, not the agent's financial identity.
When Link is the right answer
For a personal assistant making occasional purchases with a person present, Link is a compelling answer. The user brings an existing wallet, approves an exact total, and gets broad merchant reach without exposing a reusable card. Building a separate funded account for that interaction may add more setup than safety. The test is whether the agent is completing a consumer purchase or operating an ongoing financial workflow.
What good looks like
Give each autonomous agent or workflow its own account boundary, then issue credentials from it just in time. Scope each instrument to the merchant, amount, rail, and task. Keep the balance bounded, route exceptions to the owner, and close the instrument when the purchase settles. The rules move out of the prompt and into financial infrastructure, so a confused agent gets declined instead of doing harm.
This is the architecture Signets ships as an account, not a card drawer: a Signet funds once and issues scoped credentials per purchase, with the same policy layer governing bank transfers, stablecoin settlement, and metered API spend that cards never see. Build for the failure case and the success case takes care of itself. Tell us what you are building and we will get you sandbox access.
FAQ
Should I let an AI agent use my personal credit card?
Do not expose the raw credential. For supervised consumer shopping, a wallet such as Link can issue a single-use card or Shared Payment Token only after you approve the purchase. For autonomous or continuous workflows, use a separate funded account with its own policies and limits.
What is the difference between token delegation and dedicated agent credentials?
A delegated credential lets an agent use value from a consumer wallet or existing funding source without seeing the underlying card. A dedicated agent account holds a bounded balance and owns the policies, approvals, instruments, and records for an ongoing workflow. Both can issue safe, scoped credentials. Only the account creates a durable financial boundary for the agent.
Who is liable when an AI agent makes a wrong purchase?
The rules are unsettled. Because you delegated authority to the agent, current frameworks would likely treat its purchases as authorized, and whether agent error counts as unauthorized use under consumer protection law is untested. American Express began covering registered-agent errors in April 2026, which it calls an industry first; until protections like that are universal, funding isolation is your practical defense.
When is sharing a card with an agent acceptable?
It is a strong fit for supervised consumer shopping where a person reviews the exact purchase before it executes. Move to a dedicated, funded account when the agent operates autonomously, runs continuously, shares a business budget, collects revenue, or transacts across multiple rails.
