Agent Cards Are Becoming Infrastructure: What the Lithic and Kernel Launches Tell Platforms to Build

Three launches on 10 November 2026 point to the same strategic shift: agent cards are becoming part of the infrastructure for letting software buy on someone’s behalf. Rain introduced Agent Vaults, Lithic unveiled Strata, and KERNEL described vaults that let browser agents use payment methods without exposing card details to the agent or developer.

These announcements address different parts of the payment journey. Rain puts a funded balance and controls around an agent. Lithic sets out ways to connect customer funding sources to network agent tokens and virtual cards. KERNEL focuses on protecting credentials as agents navigate existing merchant checkouts.

Together, they show that the question for platforms is no longer just how an agent gets a card number. It is how to give the agent limited authority, make a payment work across different checkouts and stop an out of policy transaction before it is authorised.

Why network agent tokens are not enough

Network agent tokens can carry information about an agent’s identity, the shopper’s intent and the mandate for a purchase. They can help keep the underlying card number out of the agent’s hands and give payment participants more context about why a transaction is taking place.

But a token is not a universal acceptance guarantee. Merchants and acquirers are adopting agent token capabilities at different speeds. Some merchants may decline a token because they do not yet support it, or because it does not look like the card credential their checkout expects.

For platforms, that creates a practical requirement: support network tokens, but plan for an alternative payment route when acceptance fails. Without a fallback, an agent can have customer approval and a valid mandate yet still be unable to complete checkout.

There is also a separate control question. A token and mandate can record what the agent was instructed to do. They do not, on their own, prevent a transaction that breaks the platform’s rules.

Two platform models for agent cards

The launches point to two practical models for platforms building agentic payments. Each can combine network tokenisation with virtual card issuing, but they start from a different relationship between the customer and the payment account.

1. The staged wallet

In the staged wallet model, a customer’s existing card is stored in a token vault, either operated by the platform or a third party. When the customer authorises a purchase, the platform converts that stored credential into a network agent token and attaches the mandate for the transaction.

If a merchant declines the network token, the platform can issue a single use virtual card for that purchase. The fallback gives the agent another way to pay at merchants that accept conventional card credentials, without requiring the merchant to support agent tokens.

This is a useful starting point for platforms that want to let customers use their own cards. It can also give teams room to learn how customers use AI agents shopping before moving to a dedicated issuing model. The trade off is that the platform depends on the customer’s underlying card and on the vault and token services needed to make it usable.

2. The dedicated agent card

In the dedicated model, the platform issues a debit or credit card for each customer’s agent spending. A debit card may draw on a prefunded balance or be linked to a bank account. A credit backed card can support a different funding and rewards proposition, but brings additional risk and operational responsibilities.

For each purchase, the platform provisions a single use network agent token and attaches a mandate that describes the authorised transaction. If the merchant declines the token, the platform can issue a single use virtual card against the same balance or credit line.

The customer has one dedicated source of funds for agent activity, even when the payment credential changes at checkout. This can give the platform a clearer basis for applying spend controls, managing rewards and tracking agent activity. It also asks the platform to take on more of the issuing programme and funding design.

Neither model is automatically right for every business. The staged wallet can suit platforms that want to use customers’ existing cards. A dedicated card can make sense when a platform wants a distinct agent spending account and more direct control over funding and policy.

Controls before disputes

A mandate can help explain what a customer approved. It is not a substitute for a decision at authorisation. If an agent attempts an unsuitable or suspicious purchase, the most useful protection is to decline or challenge it before the transaction proceeds, rather than relying on a dispute after the event.

That requires a real time rules engine able to evaluate the transaction against the platform’s policies. Controls can include merchant category, country, amount and risk score. Velocity limits can cap the number of transactions or total spend over a period. Irregular patterns can trigger a challenge or require customer approval.

Rules also need to apply at the right level. A platform may need a limit for one card, a broader rule for a customer account or a policy covering a tagged group of cards. Custom code rules can handle conditions that do not fit a fixed set of fields, such as a rule specific to a cardholder or type of agent.

The design principle is straightforward: record the mandate, but also evaluate the transaction. Tokens and mandates provide useful context. Authorisation controls determine whether the payment is allowed to happen.

For browser based agent experiences, credential protection matters too. KERNEL’s vault approach keeps raw card data away from the agent, developer application and browser context, while connecting the payment step to the existing checkout. This addresses exposure risk, but it does not remove the need for transaction controls and fallback routing.

A six point checklist for merchants and platforms

What Australian platforms should build for

Australian platforms building agentic checkout can choose between these two models without building issuer infrastructure themselves. The strategic task is to connect the right funding source, credential vault, token and fallback route to a policy layer that can make a decision before authorisation.

For merchants, the operational implication is that more agent initiated transactions may arrive through familiar looking card credentials, while being single use and mandate bound underneath. Merchants should prepare to handle those transactions through existing card acceptance flows, while reviewing how authorisation, customer support and dispute processes will interpret agent activity.

The broader lesson is that the card is only one component. Agent card infrastructure needs to combine secure credential handling, flexible virtual card issuing, transaction level spend controls and a clear record of customer authority. Platforms that treat those capabilities as one system will be better placed to support agentic payments as merchant acceptance expands.

For more on how these payment structures are developing, read our analysis of Rain’s agent vault model and why the card credential followed the shopper into agent checkout.

Frequently asked questions

What are agent cards?

Agent cards are payment credentials or card programmes designed to let AI agents make purchases under defined permissions. They can use network agent tokens, virtual cards or both, with controls that limit how and where the agent can spend.

What is the difference between a network agent token and a virtual card?

A network agent token can carry information about the agent and its purchase mandate while shielding the underlying card number. A virtual card is a separate card credential that can be issued for a transaction, including as a fallback when a merchant does not accept an agent token.

Do tokens and mandates prevent unauthorised transactions?

Not by themselves. They can record the customer’s intent and the agent’s mandate, but platforms also need real time authorisation rules to decline or challenge transactions that fall outside policy.

Sources