There is a moment coming for every technology leader, and most of them have not scheduled it. It is the first time a piece of software inside the company spends money on its own. Not a subscription someone approved last quarter. Not an auto-renewal. An AI agent, running a task, deciding that the fastest path to its goal is to buy a service from someone else's agent, and doing it.
I spent fifteen years in enterprise security and digital transformation, and I have watched this pattern before. A capability arrives at the edge of the organization, someone uses it because it works, and the governance conversation happens afterward, under pressure, with an auditor in the room. It happened with cloud accounts on corporate credit cards. It happened with unsanctioned collaboration tools. It will happen with agents that transact, and the leaders who think about it now will have a much better year than the ones who think about it later.
The question finance will ask
When the first agent purchase surfaces, and it will surface, usually in an expense review, the question will not be technical. It will be five words: who approved this transaction?
Today, every enterprise answer to that question ends at a human. A person raised the purchase order. A person clicked approve. A person owns the budget line. The entire apparatus of financial control, from delegation of authority to audit trails, assumes a human signature somewhere in the chain. An autonomous purchase breaks that assumption cleanly. The agent acted within a mandate, but the mandate was general and the purchase was specific, and nobody's name is on the specific part.
The wrong response is to prohibit it. Prohibition worked poorly for cloud and poorly for every useful capability since, because the business value is real and the workaround is always one personal card away. The right response is to answer the question before it is asked: define what an agent may buy, from whom, up to what amount, under what conditions, and make every one of those constraints checkable after the fact.
Mandates, not approvals
The mental shift is from approving transactions to approving mandates. A human cannot review each purchase an agent makes, because the volume and speed will make that as impractical as reviewing each packet a firewall passes. What a human can do is define the envelope: this agent, this category of outcome, this counterparty standard, this spending ceiling, this escalation path when something falls outside the lines.
Security teams already run this model. Nobody approves individual firewall decisions. They approve policy, they monitor conformance, and they investigate exceptions. The controls that matter are the ones that survive scale. Agent spending will need the same architecture: policy up front, evidence throughout, and an audit trail that shows not just what was bought but what the agent was authorized to buy at the moment it acted.
That last part matters more than it sounds. An audit trail that says "the agent spent forty dollars" is a record. An audit trail that says "the agent spent forty dollars, within a mandate that permitted it, for an outcome that was independently verified as delivered" is a defense. The first invites an argument. The second ends one.
Why this is a leadership question
It is tempting to file this under procurement plumbing and delegate it. I think that undersells what is happening. When software can spend, the boundary of the organization moves. Your company begins to have commercial relationships that no employee initiated and no employee will ever personally review. The counterparties are agents too, acting for organizations you may never have spoken with. That is not a plumbing change. It is a change in what a company is.
The leaders who handle it well will treat the first agent purchase the way good security leaders treat a first incident: not as a crisis, but as the moment the theoretical became operational, and the moment to build the discipline while the stakes are still small. Write the mandate policy now, while the amounts are trivial. Demand verifiable outcomes now, while a failed purchase costs lunch money. Get finance, security, and engineering into the same room now, while the conversation is still a workshop and not a postmortem.
The first time your software buys something should be unremarkable. That is the goal. Unremarkable takes preparation, and the preparation starts before the first transaction, not after it.