Here is something worth sitting with for a moment.
When you order food on Door Dash, the driver who picks up your order does not reach into their wallet and pay for it out of their own pocket. They also do not have access to your bank account. What actually happens is that Door Dash issues the driver a single-use virtual card, scoped to that specific order, at that specific merchant, for that specific amount, within a specific time window.
The driver can only buy your salad at Sweetgreen. They cannot buy shoes. They cannot spend more than the order amount. They cannot come back tomorrow and use the same card again. The card exists for the duration of that one task and then it evaporates.
That driver is, in the most precise sense of the word, your agent. Acting on your behalf. With a financial instrument that is controlled, scoped, auditable, and time-limited. You did not hand them your card. You did not give them access to your account. You gave them exactly the financial authority they needed to complete exactly the task you asked them to complete. Nothing more.
Now ask yourself: why are most businesses giving their AI agents the company credit card?
The Thing Everyone Is Doing and Nobody Is Talking About
Walk into any serious technology company right now and ask the engineering team how their AI agents handle payments. You will get one of four answers.
The first: we gave it the company card. The second: we built a manual approval flow, but honestly people just rubber stamp it. The third: we have no real visibility into what it is spending, it all just goes into one line on the statement. The fourth, usually said quietly: we had an incident.
None of these are good answers. All of them are common.
The reason this is happening is not incompetence. The people building these systems are talented and thoughtful. The reason is that the infrastructure to do it properly simply does not exist yet. When you need your agent to pay for an API subscription, book travel, manage vendor invoices, or procure software, you reach for the tools that exist. And the tools that exist were built for humans, not agents.
So you patch it together. You share a card. You build a workaround. You cross your fingers and move fast because there are bigger problems to solve today.
But the bigger problems are accumulating quietly in the background. And at some point, one of them is going to become very loud and very expensive.
What Actually Happens When You Give an Agent Your Company Card
Let us be specific about what you are actually doing when you hand a company card to an AI agent, because most people have not thought it through completely.
You are giving software that makes probabilistic decisions unrestricted access to a payment instrument with no native controls, no audit trail tied to agent actions, no scope limitations, and no automatic expiry. You are trusting that the agent will only spend what you intended, only at merchants you would approve, only in amounts that make sense, only for purposes that align with what you asked it to do.
You are, in effect, giving a new employee your company card on their first day and telling them to get on with it.
Except this employee does not sleep. It can execute transactions at machine speed. It may be running as multiple instances simultaneously. It has no intuitive sense of when something feels wrong. And when something does go wrong, your ability to reconstruct what happened, why it happened, and who authorised it is almost entirely dependent on whether you thought to build logging before the incident rather than after.
The exposure here is not hypothetical. It compounds in three directions.
Financial exposure. Unauthorised or unintended spend that is difficult to trace, dispute, or recover. Subscription creep across dozens of services. Duplicate purchases across agent instances that do not know about each other.
Security exposure. A shared card credential flowing through agent systems is a credential that can be compromised. The more systems it touches, the more attack surface you create. A card that belongs to everyone effectively belongs to no one in terms of accountability.
Operational exposure. When your finance team asks which agent spent what, for which purpose, authorised by whom, you have no clean answer. When an auditor asks for a complete record of autonomous financial actions taken on behalf of the business, you do not have one. When a vendor disputes a charge and you need to demonstrate authorisation, you cannot.
These are not edge cases. They are the default outcome of the current approach at scale.
The Door Dash Principle, Applied Properly
Emily Glasberg Sense, Head of Information at Stripe, made a point recently that cuts right to the heart of this.
She said that agents have actually been buying on our behalf for years. They were just human agents. The Door Dash driver is your agent. The travel agent booking your flights is your agent. The procurement assistant ordering office supplies is your agent.
And the financial infrastructure for human agents is actually quite well designed. You do not give the Door Dash driver your card. You issue a scoped, single-use, time-limited credential for one specific task. The controls are built into the financial instrument itself, not bolted on as an afterthought.
The question is why this principle, which we apply instinctively to human agents, has not been applied to AI agents.
Part of the answer is speed. The AI agent revolution has moved faster than the infrastructure to support it. Part of the answer is availability. The tools to do this properly have not existed. Part of the answer is habit. We reached for what was familiar when something new was needed.
But the principle is clear and it is the same whether the agent is human or artificial. If you would not give a contractor unrestricted access to your company bank account, you should not give your AI agent unrestricted access to your company card.
What Dedicated Agent Finance Actually Looks Like
Here is what the right infrastructure looks like and why each element matters.
A dedicated account per agent. Not a shared pool. Not a slice of a company account. An account that belongs to that agent, reflects that agent's financial activity, and creates a clean separation between what the agent does and what the humans in the organisation do. This is not bureaucracy. This is the same reason you have separate cost centres for different departments. Visibility, accountability, and the ability to understand what is actually happening.
Scoped virtual cards. Issued per task, per campaign, per workflow, per vendor relationship. A travel booking agent gets a card that works for travel. A SaaS procurement agent gets a card with a category restriction and a monthly limit. A one-time vendor payment gets a single-use card that expires on completion. The financial instrument matches the scope of the mandate. Always.
Owner-defined rules before money moves. Not controls applied after the fact. Rules that are structural. The agent cannot exceed this amount. The agent cannot transact with this category of merchant. The agent requires approval above this threshold. These rules are not suggestions. They are architecture. They cannot be overridden by the agent because they do not live in the agent. They live in the financial layer beneath it.
A complete audit trail. Not just a payment record. An execution trace. Every request the agent made, every approval it sought or received, every transaction it completed, every rule it triggered, every action it took with money. Not a log that tells you what was spent. A record that tells you why, under what authorisation, by which agent, for which purpose. This is what you need when the finance team asks questions. It is what you need when something goes wrong. It is what regulators will eventually require. Build it now.
Verified agent identity before any of the above. This is the piece that most people are not thinking about yet and it is the piece that everything else depends on. Before an agent gets an account, before it gets a card, before it moves a single penny, you need to know who owns it, what it does, what tools it connects to, what it has been authorised to spend, and what its risk profile looks like. This is KYA. Know Your Agent. And it is the foundation on which trustworthy agent finance is built.
The Argument We Have Not Heard Enough
Here is where we want to add something to this conversation that we do not think is being said clearly enough.
Most of the discourse around AI agents and money focuses on the risk of agents going rogue. The runaway agent. The unauthorised purchase. The fraud scenario. And those risks are real and worth taking seriously.
But the more important and more immediate problem is not the dramatic failure. It is the slow accumulation of invisible exposure from a hundred small decisions made in the absence of proper infrastructure.
Every company card shared with an agent is a credential that cannot be properly audited. Every manual approval flow is a bottleneck that will either be bypassed or will strangle the agent's usefulness. Every shared wallet is a forensic nightmare waiting to happen. Every missing audit trail is a gap in the governance record that will matter enormously at exactly the moment you most need it.
The problem is not that AI agents are dangerous. The problem is that businesses are deploying economically consequential software on financial infrastructure that was never designed for it.
And here is the thing about that kind of slow, invisible exposure. It does not announce itself. It compounds quietly until the moment it does not. And by then, the question is not how to prevent it. The question is how bad it got and who is accountable.
We believe the answer to this is not more controls on top of broken infrastructure. It is infrastructure that is built correctly from the start. Dedicated accounts. Scoped cards. Owner-defined rules. Complete audit trails. Verified agent identity. Not as add-ons. As foundations.
What Agent Float Changes
There is one concept in agent finance that we think deserves more attention than it currently gets. Agent float.
The idea is simple. Instead of giving an agent access to your main financial resources and trusting it to spend appropriately, you pre-fund the agent with exactly the amount it needs to complete a defined piece of work. The agent operates within that float. When the float is exhausted or the task is complete, the card or wallet expires. If the agent needs more, it requests more. If it does not spend it all, it returns it.
This is not just a security mechanism. It is a fundamentally different way of thinking about agent finance.
It means the maximum possible exposure from any agent action is bounded by the float, not by the limit on your company card. It means the financial scope of agent autonomy is defined before the agent acts, not reconstructed after. It means the relationship between what you authorised and what the agent spent is always visible and always clean.
Combined with spend expiration, merchant memory for trusted recurring vendors, and reusable playbooks for standard workflows, agent float turns agent finance from a question mark into something you can actually govern.
This is not a distant vision. It is what proper agent banking infrastructure enables today.
The Bigger Picture
We are at an early and genuinely important moment in the development of the agentic economy.
The agents being deployed right now are relatively simple. They manage subscriptions, process invoices, book travel, procure software, handle routine purchasing workflows. The financial stakes are real but manageable.
The agents coming in the next two to three years will be considerably more capable and considerably more financially consequential. They will manage supplier relationships. They will negotiate contracts. They will handle treasury operations. They will make procurement decisions at a scale and speed that no human team could match.
When that happens, the question of whether your agent finance infrastructure is built correctly will not be a nice-to-have. It will be a fundamental governance question with material implications for your business.
The time to build that infrastructure correctly is before you need it, not after you have learned why you needed it.
The Door Dash driver has a scoped card because someone at some point decided that giving contractors unrestricted access to company funds was not a reasonable way to operate. That decision was not made after a disaster. It was made as a matter of basic operational sense.
Your AI agent deserves the same thinking. Not a company card and a prayer. Its own account, its own card, its own rules, its own identity, and an audit trail that tells the complete story of every financial action it ever took.
That is not caution. That is architecture.
Roving Is Building This Layer
This is precisely the infrastructure gap Roving was built to fill.
Every agent on the Roving platform gets its own verified financial identity through KYA, its own dedicated account, its own scoped virtual cards, owner-defined spending rules that cannot be overridden, and a complete execution trace for every financial action it takes. Before the agent moves a single penny, Roving knows who owns it, what it does, and what it is authorised to spend.
This is not a workaround. It is the financial operating system the agentic economy actually needs.
Get early access at roving.money and give your agents the financial infrastructure they deserve.
If this piece resonated, drop a comment below. We especially want to hear from the people who have quietly been handing their AI agents the company card and wondering if there is a better way. There is.
Stay in the loop:
Follow us on LinkedIn for product updates, founder notes and sharp ideas on the agentic economy
Join our Discord community and be part of the conversation shaping the future of agent finance
Share this with anyone building or deploying AI agents who has not yet thought seriously about what happens when one of them goes to spend money
