Who is accountable when an AI agent makes a decision? Ask the products shipping this autumn and the answer comes back in layers. The agent has an identity. The identity sits in a registry. Somebody administers the agent, and at Microsoft somebody on the business side has to sponsor it. What none of the documentation I read asks for is a named person who answers for what the agent is allowed to commit, and how much money it may commit before anyone looks.
On October 8, Google announced a Gemini agent that works as a coworker. Each agent gets its own identity, which Google describes as cryptographically attested and governed like an employee, its own email address on a company domain, and a place in the audit trail where its actions are attributed to the agent rather than to a person. I want to say first that this is good engineering. Knowing which agent did a thing, and what it was permitted to touch, is the hard half of security, and the vendors have taken it seriously. I am not arguing with any of it.
The announcement post is also candid about its scope, which I appreciate. It says permissions are approved by the organisation's security administrators, and it does not say who is accountable for an agent's actions or outcomes. It does not say how the person who handed the agent a task is recorded in the trail either. Google's identity documentation says that when an agent acts on a user's behalf, the logs show both the agent and the user. A coworker agent acting under its own identity rather than yours is a different case, and I could not find the equivalent sentence for it.
I do have a stake in what happens next, because I made a prediction. In June I wrote in Who Owns the Decision? that an agent can be fully compliant and fully logged in an agent registry and still be an unpriced decision, and I imagined a governance veteran answering that they already had a registry with an owner on every entry. A registry has now shipped as a product, with documentation. That means the claim can be tested against fields instead of against my imagination, which is a better position to argue from.
Three objects that get called one thing
An identity tells you who acted. It is a principal that an authorisation system can reason about, so that "this agent may read that table and nothing else" is a sentence the system can enforce. A registry entry tells you what exists: which agents, which tools, which endpoints, so that nobody has to guess what is running. The third object is the one I care about, and it has no product category yet. It is the person who signed for the dollars.
By that I mean a human being who can say, of one class of decision the agent makes, what it is worth to get it right, how much the agent may spend or commit while making it, and what would make them pull it. That is the decision class and its owner, and it is the only one of the three that a CFO would recognise. Identity and registry answer questions an engineer asks at three in the morning. The owner answers the question a finance partner asks at the quarterly review, and the two almost never get asked by the same person.
What the documents say
I read Google's Gemini Enterprise Agent Platform governance documentation and Microsoft's Entra Agent ID documentation on October 10, looking for the same four things in each: a named human, what that human is accountable for, a purpose, and a budget.
| What I looked for | Google, Agent Identity and Agent Registry | Microsoft, Entra Agent ID |
|---|---|---|
| The agent has its own identity | Yes, a SPIFFE-format ID | Yes, an agent identity |
| A named human is required | Not documented | Yes, at least one sponsor |
| What that human answers for | Not documented | The agent's purpose and lifecycle decisions: renew, extend, remove |
| A purpose field | Not documented | No dedicated field; described in prose |
| A budget or dollar bound | Not documented | No dedicated field |
Google first. Agent Identity is a SPIFFE-format ID that serves as a granular alternative to shared service accounts. Agent Registry is described as a central catalog of agents, tools, MCP servers and endpoints, and the agents overview says it captures versions, frameworks and capabilities such as tool names. Across the governance overview, the registry page and the identity overview, which carries an October 7 update date, I found no owner, no responsible person, no purpose and no budget. Gateway policies can be set to dry run or enforced, which is an enforcement switch and says nothing about money. I could not open the page on registering agents, and it may list fields the overview pages do not, so take this as a statement about where I looked.
Microsoft's documentation is more interesting, and it cuts against my headline a little. It defines three relationships. Owners are technical administrators, and the role is optional. Managers are individual users in the reporting hierarchy. Sponsors are business representatives accountable for the agent's purpose and lifecycle decisions, and at least one is required for every agent identity. The page I read shows a July 21 update date. A required field is the best thing in either set of documents, because it means somebody had to make a decision at the moment the agent was created, and that is exactly the instinct this argument asks for.
Look at what the sponsor decides, though. Renewal, extension, removal, and whether behaviour during an incident was expected. The same page says there is no dedicated field for a budget, a cost centre or a formal purpose statement; those live in prose. So the person the product forces you to name is accountable for whether the agent lives. Nobody is forced to name the person accountable for what each of its decisions is worth.
Why lifecycle is not the decision
It sounds like a technicality until you look at one agent. Suppose a single agent shifts daily budget between campaigns, adjusts targets, and rewrites ad copy. That is three decision classes. Being wrong about budget shifts costs money within the day. Being wrong about targets costs money more slowly and is harder to see. Being wrong about copy costs a different thing again, and may cost nothing you can count for a month. A sponsor renewing the agent in January is renewing all three with one signature, and has been asked to price none of them.
Run it the other way and the problem gets worse. Ten agents can sit inside one decision class, each properly identified, each properly registered, each sponsored, and nobody holds the cost of the class they are all part of. That is the unpriced decision in its natural habitat. It passes every review because every review asks about the agent, and the cost lives in the decision. This is why Cost Per Decision needs an owner by name before it can be computed at all.
Anyone who has run paid media will recognise the older version of this, which predates anything called an agent. A bidding setup gets a name, a login and an account manager, and the account manager can tell you everything about how it is configured. Ask who decided that a large swing in daily budget was acceptable, and there is a pause. The answer is usually a person who left, or a default that shipped with the product and was never revisited. The difference now is speed. A human-run process that nobody priced drifted over quarters. An agent that nobody priced can make the same drift in an afternoon, and it will have identified itself correctly the whole time.
Two people who would push back
The first is a product lead at one of these platforms, and I would expect them to say that a registry entry can hold anything. If the registry accepts free-form labels, and I could not confirm that it does, a company can write all four fields into it today. I would concede that in a second. My claim is about what the product asks for. A field you must fill is a decision somebody made on a Tuesday afternoon. A label you may add is a suggestion, and optional fields have a way of staying empty, which is how a default owner gets made: whoever wrote the schema first decides what the record contains.
The second is a security lead, who would say that identity and access is the right layer and that accountability is a policy, not a schema. Agreed on both counts. Identity and access management solves what an agent can touch, and I have no quarrel with it. The trouble is that nothing in the products I read asks for the policy to exist. Microsoft is the exception that proves the point, because requiring a sponsor is a policy turned into a required field, and it took a required field to get one.
A decision with no owner, due on Monday
There is a live example this week. From October 12, according to the notice Google emailed to advertisers and as reported by PPC Land and Search Engine Roundtable, Google Ads will start pulling discount offers off an advertiser's own website and attaching them to Search and Performance Max campaigns as promotion assets. An account-level setting turns it off. Nothing I have read says who funds a discount a crawler found.
Notice the vocabulary. The controls call it an automated asset, and the audit trail will attribute it to the system. It is a price. Somebody decided to show a customer a price on behalf of a business, and the records will say that a system did it. The mechanics belong in a practitioner brief. The shape is the point here: a decision that moves money, made by a system, recorded under the system's name, with no field anywhere for the person who was supposed to have signed for it.
The Monday move: four fields
None of this needs a vendor. It needs a row. For every agent in your registry, add four fields: the decision class, the dollar bound per period, the named human who signs for it, and what would force it out, with the person who holds that lever. The last one is the column I proposed for seller numbers in the compelled-evidence essay, applied here to your own agents, and it is the same question as setting a kill condition.
| Agent | Decision class | Dollar bound per period | Named human who signs | What would force it out, and who holds that lever |
|---|---|---|---|---|
| Budget-shifting agent | Daily budget moves between campaigns | A figure, agreed with finance | One person, by name | Cost per decision above threshold two cycles running; finance holds the lever |
| Ad-copy agent | Customer-facing claims and offers | Nobody set one | The team, which is nobody | Nothing named |
If your registry has no place for these, a spreadsheet next to it will do. What matters is that the row exists before the agent is switched on, which is the only moment it is cheap to fill. After that it is an archaeology project, and the person who ought to have signed has usually moved teams.
This site argues more than it claims, and an argument cannot be scored later, so here is one with a date. As of October 10, 2026, the Google pages I read document no owner, purpose or budget for an agent, and Microsoft's documentation requires a business sponsor but defines no budget field.
On February 28, 2027, no field or required step in Google's Agent Registry or Agent Identity documentation will name a decision class or a dollar bound on what an agent may commit. Google may well have added an owner or contact by then. If it does, it will describe the agent or its runtime, not the decision. Check it against the public documentation on that date, and check Microsoft's sponsor page for the same two things.
I do not think anyone is hiding this. The vendors built what a security team asked for, and a security team asks about agents. A finance team would have asked about decisions, and nobody has sold them a registry. The practical result is that a company can pass its governance review this quarter with every agent identified, catalogued and sponsored, and still hold a growing set of decisions that nobody priced and nobody can switch off on a stated condition. The review will say compliant. The P&L will say otherwise, later, and it will not say which agent.