Non-Human Identity Sprawl: A CISO Guide to Service Accounts, API Keys, and AI Agents
Non-Human Identity Sprawl: A CISO Guide to Service Accounts, API Keys, and AI Agents
Non-Human Identity Sprawl: A CISO Guide to Service Accounts
Short answer: Your machine identities, service accounts, API keys, tokens, certificates, and now AI agents, almost certainly outnumber your people by something like 40 to 1, and most of them have no owner, no expiry date, and more privilege than any employee would ever be granted. The fix is not another product. It is a register that names a human owner for every non-human identity, a lifecycle that ends credentials on a schedule, and least privilege enforced at the moment of creation. In that order.
I have sat through identity reviews at organizations of every size, and the pattern never changes. The human side of the directory is reasonably clean: joiners get provisioned, leavers get disabled, and access reviews happen often enough to keep the auditors calm. Then someone asks about the service accounts, and the room goes quiet. Nobody set out to create this. A developer needed a service account to ship something on a Friday. A vendor integration needed an API key, and the fastest scope to grant was all of them. A scheduled job needed database access, and the person who created it left in 2021. Multiply that by every team and every year, and you have sprawl.
Run the census before you buy anything
The first honest step is a count. Pull every service account from Active Directory and Entra ID. Pull every access key from AWS, every service principal from Azure, every service account key from Google Cloud. Add the secrets sitting in your CI/CD pipelines, the tokens in your SaaS admin consoles, and whatever your vault teams will admit to. The number will embarrass you. That is fine. Every organization I have watched run this census for the first time found several times more machine identities than anyone expected, and the count is the cheapest part of the whole program.
Resist the urge to start remediating on day one. A census with no ownership data is just a longer list of things you cannot safely touch. For each identity, capture three fields: what it can reach, when its credential was last rotated, and who answers the phone if it breaks. That third field will be blank most of the time. That blank field is the actual problem, and everything else in this post is about filling it.
Why nobody owns a service account
Human identity works because it is anchored to employment. There is a start date, a manager, and ,critically, an end date. Machine identities have none of that. The account a contractor created for a data sync in 2019 is still running a nightly job, and the contractor is three employers away. When the job fails, someone re-enables the account and moves on. When it never fails, nobody looks at it for years. There is no leaver process for a cron job.
Ownership has to mean a named person, not a team alias. Aliases outlive the people on them and diffuse responsibility until nobody feels it. The working rule I hold teams to, and the one that anchors my IAM checklist, is simple: no identity without a named owner, and no owner without a review date. When the owner changes roles, the identity transfers or it dies. That single rule, enforced at creation, prevents most of the sprawl you would otherwise spend the next five years cleaning up.
AI agents are service accounts with initiative
Everything above was already true five years ago. What changed is that we started handing credentials to software that decides what to do next. A static API key in a config file is a passive risk: dangerous if leaked, inert otherwise. An AI agent holding that key is an active one. It chains calls, spawns sub-tasks, retries in ways nobody scripted, and does all of it at machine speed. When an agent misbehaves, through a prompt injection, a badly written tool description, or plain model error, it misbehaves with whatever privilege you gave it, and it does so in seconds, not quarters.
The governance question is not whether agents get identities. They must. Sharing one over-scoped key across a fleet of agents guarantees you will never attribute an action to an actor, which means your incident review ends at a shrug. Each agent gets its own identity, its own narrow scope, a credential lifetime measured in hours rather than years, and a human owner accountable for what it does. I keep the broader decision framework on my AI governance hub, because agent identity is one corner of a much larger accountability problem, but the identity corner is where I would start.
Ownership, lifecycle, least privilege, in that order
The order matters because each step makes the next one possible. Ownership first: until a person is on the hook, no expiry date is safe to enforce, because nobody can tell you what breaks when the credential dies. Lifecycle second: every credential gets a creation date, a rotation schedule, and an end date, and new credentials do not get issued without all three. Prefer short-lived credentials and workload identity federation over static keys wherever your platforms support it. A key that expires in an hour is a contained mistake. A key that has been valid since 2020 is a standing invitation.
Least privilege comes last, not because it matters least but because it is impossible without the first two. You cannot scope down an account nobody understands. Once an owner exists, the conversation turns concrete: what does this job actually read, what does it actually write, and why does it hold admin on anything? In my experience the answer to the third question is almost always some version of it was easier at the time.
One more parallel worth drawing. We spent the last decade moving humans toward stronger authentication, I wrote about that journey in From MFA to Phishing-Resistant Identity, and machines cannot follow the same path. There is no push notification a service account can approve, no passkey ceremony for a build pipeline. The compensating controls are short credential lifetimes, attestation of the workload requesting access, and monitoring that treats an out-of-pattern machine action as seriously as an impossible-travel alert on a human account.
The first ninety days
Weeks one through three: the census, from every source you can reach, with the three fields above. Weeks four through six: kill the dead. Any machine identity with no authentication activity in the last ninety days gets disabled, deliberately, in business hours, with a rollback plan and a broadcast to engineering. Some things will break. That is the point. A controlled failure at ten in the morning teaches you what an account actually does; the same discovery during an incident costs far more. Weeks seven through twelve: expiry becomes mandatory on every new credential, and every identity in your top privilege tier gets a named owner or gets disabled.
Then pick one metric and report it upward: the percentage of non-human identities with a named owner and a working expiry date. It is honest, it moves when you do the work, and it tells the board something true about a risk they have never seen on a slide before.
Frequently Asked Questions
What is non-human identity security?
It is the discipline of governing identities that belong to software rather than people, service accounts, API keys, tokens, certificates, and AI agents, with the same rigor we apply to human access: a named owner, a defined lifecycle, and least privilege from the moment of creation.
How do I find all of our service accounts and API keys?
Combine sources: your directories, cloud IAM across every provider, CI/CD secret stores, vaults, and SaaS admin consoles. No single tool sees everything. Treat the census as a recurring process rather than a one-time project, because new identities appear every week.
Should AI agents have their own identities?
Yes. Give each agent its own identity with a narrow scope, short-lived credentials, and a named human owner. A shared key across a fleet of agents destroys attribution, and without attribution your incident reviews cannot reach a conclusion.
What is the fastest win for reducing non-human identity risk?
Disable machine identities that show no authentication activity in the last ninety days, with a rollback plan in place. Then make expiry dates mandatory on every new credential so the backlog stops growing while you work through it.
AI in Cybersecurity: Future Threats
About Author
