Your agents are all logging in as the same user

Two things happened in the same fortnight this August. Google took its Gemini Enterprise Agent Platform to general availability, with agents that hold state for days at a time and a feature called Agent Identity that gives each agent its own SPIFFE-formatted credential instead of a shared service account. And Zenity, which sells security tooling for AI agents, closed a 125 million dollar Series C led by Norwest, with SoftBank Vision Fund 2, Hitachi Ventures and LG Technology Ventures joining.

A hyperscaler shipping per-agent identity as a platform primitive and the venture market funding agent security at that valuation in the same month is not a coincidence. It is the industry arriving, collectively and slightly late, at a problem that most organisations already have and cannot currently see: their agents are all logging in as the same user.

How the shared service account happens

Nobody decides to do this. It accretes. The first agent needs to read from the data warehouse, so someone creates a service account and grants it read access. The second agent needs the same warehouse plus the ticketing system, and rather than provision a second identity and go through access review again, it reuses the first one and the permissions get widened. By the eighth agent, that service account can read three databases, write to two systems of record, call four internal APIs and send email — and every agent in the fleet is operating with the union of everything any of them ever needed.

This is the classic over-permissioning failure, and it is the specific thing Google’s Agent Identity is designed to eliminate. But the permission breadth is only the first of three problems, and it is not the worst one.

• You lose attribution. The audit log shows the service account did it. It does not show which agent, running on whose behalf, under which instruction. When something goes wrong — and the question from your auditor is “which process deleted these records” — the log cannot answer it. This is the failure that turns a contained incident into a fleet-wide investigation.
• You lose granular revocation. One agent misbehaves and your only lever is the shared credential. Revoking it stops the bad agent and the seven well-behaved ones. In practice teams hesitate, because the blast radius of the fix rivals the blast radius of the problem, and hesitation during an incident is exactly what you were trying to design out.
• You lose the least-privilege argument. Not just the property — the argument. You can no longer tell a regulator, a customer, or a security reviewer what any individual agent is able to do, because the honest answer is “everything the shared account can do”. That sentence fails every control framework you will be assessed against.

What per-agent identity actually buys

Google’s implementation is worth reading closely, not because you should necessarily buy it, but because it is a clear statement of what the primitive needs to be. Each agent gets a distinct identity supported directly in IAM, so permissions attach to the agent rather than to a pool — this bucket, that dataset, nothing else. Broad and harmless permissions such as logging, quota, and model access are granted across the project; the narrow permissions that touch sensitive data are granted per agent. Agents authenticate with mutual TLS and X.509 certificates when talking directly to cloud APIs, and add Demonstrating Proof of Possession across the agent gateway, so the credential is bound to the holder rather than being a bearer token anyone who captures it can replay.

The most quietly important part is credential handling on behalf of a user. End-user credentials are encrypted by an auth manager and decrypted at the gateway, so the agent itself never touches the raw credential. That closes the failure mode that keeps security teams awake — a compromised or manipulated agent exfiltrating the user tokens it was holding in order to act for them. The agent gets to act with delegated authority without ever possessing the thing that grants it.

Whether you adopt Google’s version or build the equivalent on your own stack, that list is the specification: one identity per agent, permissions attached to it individually, credentials bound rather than bearer, user tokens never held by the agent, and every action attributable to a specific agent in the log. Getting this right is unglamorous and it is the part of an agent build that determines whether you can safely run twenty of them instead of three — we now treat identity and reversibility as design inputs from the first sprint rather than hardening applied before launch, because retrofitting identity onto a running fleet means re-permissioning every integration under time pressure.

The honest counter-argument

Identity solves authorisation. It does not solve intent, and the gap between those two is where most real agent incidents will live. An agent with a perfectly scoped identity, correctly authenticated, holding exactly the permissions it needs, can still be talked into misusing every one of them by a prompt injection buried in a document it was asked to summarise. It is behaving correctly at the identity layer while doing the wrong thing at the semantic layer, and no certificate catches that. Per-agent identity converts a catastrophic breach into a contained one — genuinely valuable, and not the same as prevention. Anyone selling it as the answer to agent security is overselling.

Two more caveats worth stating plainly. Google’s Agent Identity is currently offered under Pre-GA Offerings Terms — provided as is, with limited support — even though the platform around it is generally available, so building a compliance story on it today is premature. And the whole approach presumes you know what agents you are running. An organisation that cannot produce an inventory of its agents will not benefit from per-agent identity; it will produce a per-agent identity for the agents it knows about and remain exposed through the ones it does not. Identity is the second problem. Inventory is the first, and it is the one almost everyone skips.

What to do in the next 30 days

• Count your agents and their credentials. One row per agent: what it does, which identity it authenticates as, what that identity can reach. The row count and the identity count should match. If they do not, you have found your exposure.
• Find the widest service account. There is one credential in your estate with more permissions than anything using it needs. It was widened incrementally and never narrowed. Start there.
• Test attribution before you need it. Pick a write your fleet performed last week and try to trace it to a specific agent and instruction from logs alone. If you cannot, your incident response does not work yet.
• Separate the sensitive permissions. Even without per-agent identity, split the credential that touches customer data from the one that does not. It is a day of work and it halves the blast radius.

The agent fleets being assembled this year will still be running in three years, and the identity decisions made now are the ones that will be hardest to reverse — permissions are easy to grant, and re-permissioning a live integration that a business process depends on is a change-control exercise nobody wants. A hyperscaler making this a platform primitive and the market funding agent security at nine figures are both signals that the window for doing it cheaply, before the fleet grows, is now.

Running a growing fleet of agents that all authenticate as the same service account? Talk to Cravings about agent identity and permissioning — we inventory what you are actually running, split the credentials by blast radius, and make every agent action attributable before the auditor asks.