Your AI Agents Outnumber Your Employees. Who Owns Their Credentials?

A CISO asked her team a simple question in a meeting I was in: how many AI agents do we have running, and what can each of them reach?

Nobody could answer either half. Not because the team was careless. Because the answer lives in a dozen places, half of them outside the systems the security team watches, and because the agents were mostly deployed by product teams doing exactly what they were asked to do.

This is not an unusual position. Depending on whose survey you read, non-human identities outnumber human ones in enterprises by 45 to 1 at the low end and 100 to 1 at the high. Fewer than 6% of organisations report full visibility into their service accounts. Microsoft's Copilot Studio users have collectively built over a million agents. Nothing about that population was planned.

The interesting part is that this is not really a new problem. Service accounts, API keys, and machine credentials have been sprawling for twenty years. What changed is that the machines now improvise.

Why an agent identity is different from a service account

A traditional service account does one thing. The nightly batch job pulls from the warehouse and writes to a reporting table, forever, and if it ever tried to do something else that would be a bug.

An agent has a goal and a toolbox. Its behaviour is a function of the goal, the tools, and whatever it reads along the way. That last term is the one that breaks the old model, because what it reads can be influenced by someone who is not you.

Two consequences follow, and both are the whole security story in miniature.

The first is that the blast radius of an agent is the union of everything its credential can touch, not the set of things it was designed to do. An agent given read access to a shared data store because that was easiest can be talked into reading all of it. Intent is not a boundary. Permissions are.

The second is that agents call other agents. When a supervisor delegates to a subagent, which delegates to a tool, which hits an internal API, the question of who authorised the final action has three plausible answers and most systems record none of them. When something goes wrong you get a log line saying the platform service account did it, which is technically true and completely useless.

How the over-permissioning happens

I want to be specific about the mechanism, because it is not negligence and telling people to be more careful does not fix it.

A team is building an agent. They need it to read from Salesforce, the data warehouse, and a document store. Getting three properly scoped credentials provisioned takes two to three weeks in a normal enterprise, and there is a demo on Thursday. Somebody has an existing integration account with broad access. They use it, note it as a to-do, ship the demo, and the demo goes well enough to become the pilot, and the pilot becomes production.

Nobody ever decides to over-permission an agent. It happens because the fast path and the safe path have different latencies, and demos have dates.

The fix is not a policy telling people to use the safe path. It is making the safe path fast. Teams that get this right build an internal path where a new agent gets its own identity, with a declared scope, in an afternoon. Once that exists, nobody borrows a credential, because borrowing is no longer faster.

The evidence that this is a live problem rather than a theoretical one is fairly stark: 24 million non-human identity credentials were found leaked on GitHub in 2025, and around 70% of the ones from 2022 were still valid. Long-lived credentials do not expire on their own, and a credential in a repo is a credential in someone else's hands.

The delegation problem nobody scoped

Here is the question that catches even mature teams.

An agent does something on behalf of a user. Say it books travel, or approves an expense, or issues a refund. Whose authority did it use?

Three models exist in the wild. The agent has its own broad credential and acts with its own authority, which means a junior employee can ask it to do something they could not do themselves. Or the agent impersonates the user, which is closer to correct but means the agent inherits everything that user can do, including the things nobody meant to delegate. Or the agent gets a narrowly scoped, short-lived token minted for this specific task on behalf of this specific user, which is the right answer and is more work.

The third one is where the industry is heading, and it maps onto the machinery that is being built for agent payments, where a signed mandate carries cryptographic proof of what the user actually authorised. The same idea generalises well beyond payments: the agent carries a token that says what it may do, for whom, and for how long, and every downstream system can check it.

Most organisations are on model one or two. If you cannot answer "on whose authority" for your production agents, that is the gap.

What a workable control set looks like

I am going to keep this concrete, because agent identity discussions have a tendency to float off into architecture diagrams.

Give every agent its own identity. Not per team, not per platform. Per agent. If the invoice agent and the support agent share a credential, an incident in one is an incident in both, and you will not be able to tell them apart in the logs.

Make the tokens short-lived and scoped to the task. Minutes, not months. A stolen token that expires in fifteen minutes is a much smaller event than a static key that has been valid since March. This is the single highest-leverage change available and it is mostly a plumbing exercise.

Separate read from write, and gate the writes. Reads are cheap to grant and rarely catastrophic. Writes, deletions, payments, and anything that touches a customer are where the incidents live. Every irreversible action should either require human approval or be constrained by a hard limit the agent cannot argue its way past. A refund agent with a per-transaction ceiling and a daily total is a fundamentally different risk than one without.

Register the agents somewhere. A list, with an owner, a purpose, a scope, and an expiry. This sounds bureaucratic and it is the thing that lets you answer the CISO's question. Agents accumulate; some of them outlive their purpose and keep their access. Without a registry with expiry dates, nothing ever gets decommissioned.

Log the chain, not the endpoint. When agent A delegates to agent B which calls tool C, the record should let you reconstruct that. If your audit trail shows only the final call, you have an audit trail that cannot answer the question anyone will actually ask.

Watch for behavioural anomalies as a distinct category. Agent traffic does not look like human traffic and it does not look like batch traffic. A support agent that suddenly reads two thousand customer records in four minutes has not necessarily been compromised, but it has certainly done something worth a look. Most identity threat detection is tuned for humans and will not flag it.

The organisational question

The technical controls are the easy half. The harder question is who owns this.

Security teams usually do not know what agents exist, because they get deployed by product and data teams. Product teams do not think of themselves as provisioning identities, because from their side it is a config value. Identity and access management teams are set up around joiners, movers and leavers for humans, and an agent is none of those.

The pattern that works, in the organisations I have seen handle it well, is that the identity team owns the issuing mechanism and the registry, and the team that builds an agent owns its scope and is named as its owner. Central control of how identities are made, local ownership of what each one may do. Neither side can do it alone: central teams do not know what an invoice agent needs, and product teams will not build a token minting service.

The forcing function that usually makes this happen is a specific person being told to answer the question "list every agent and its access" for an auditor or a board. It works better if you decide to answer it before someone makes you.

Where to start if you are behind

Start with discovery, and expect it to be worse than you think. Find every credential being used by an AI system: platform accounts, API keys in repos and secret stores, OAuth grants against SaaS tools, anything in the MCP servers your developers have connected. Write down what each one can reach.

Then rank by write access. Anything with the ability to modify records, move money, message customers, or delete things goes at the top of the list regardless of how well behaved the agent has been so far.

Then fix the top of that list first: scope it down, shorten the lifetime, add an approval gate on the irreversible operations. You will not get through the whole inventory this quarter and you do not need to. You need the tail risk gone.

And build the fast path, because if provisioning a properly scoped agent identity still takes three weeks, everything you just cleaned up will drift back within two quarters.

None of this is exotic security work. It is the same least-privilege discipline that has applied to service accounts forever, applied to a population that is growing faster than the governance around it and that, unlike a batch job, can be persuaded to change its mind.

If you are working through agent permissions and delegation and want someone who has designed a few of these to look at yours, that is a conversation we are glad to have.