The Accounts Nobody Owned: Machine Identity Is the Attack Surface You Forgot to Inventory

The dramatic part of a breach gets the camera. The war room, the legal counsel on the line, the forensics team, the call to retire a compromised control before the next login. I have written about that call already — the legacy-MFA cutover that came out of the 2022 incident, made on the record with the C-suite and Legal in the room. This is about the other half. The half that started after the room emptied, ran for weeks, and never made a slide.

We had to find the owners of more than two thousand service accounts.

Not the accounts — those we could enumerate. The owners. The human being who, if you walked up to any given non-human login and asked “should this exist, what does it touch, and is it still needed,” could answer. For a meaningful share of those accounts, the honest answer to “who owns this” was a shrug. In the shape that incident was taking, a service account nobody owned was a candidate for the open door.

The accounts you can list, the owners you cannot

Here is the distinction the whole story turns on, and the one a generalist write-up of this breach would miss.

You can list your service accounts. They are in the directory. Run the query, get the rows. What you cannot list — what no enterprise I have ever seen could produce on demand — is the owner of each one: the person accountable for why it exists, what privilege it carries, and whether it should still be alive. That second list does not sit in a system. It has to be reconstructed, account by account, by going and asking.

We went and asked. More than two thousand accounts. Roughly a thousand owners surfaced by the time the exercise closed, every team leaning in, tracing each non-human login back to a human who would answer for it. Hold those two numbers next to each other: two thousand-plus accounts, about a thousand named owners. That distance is the finding, and it has a name — the owner-of-record gap, the difference between the machine identities you can enumerate and the ones you can attach a human to. A large share of the machine logins running inside a workforce of thousands had no clean line to a person. They had been minted for a migration, a vendor integration, a project that shipped two reorgs ago — then kept their privileges and outlived everyone who remembered why.

That is an inventory problem wearing a security incident’s clothes. No password policy reaches an account no human is watching.

Why nobody had the register

It is tempting to read that as negligence. It was the default state of every enterprise of that era, and largely still is.

Human identity has an owner by construction. A person is hired, a record is created in the HR system, that record drives the directory, and when the person leaves, the same system tears the access back down. Joiner, mover, leaver. The lifecycle is built in because there is always a human at the center of it, and an HR event to hang each change on.

A service account has none of that. It is born from a ticket, a script, an engineer who needed something to work by Friday. There is no hiring event, no manager, no termination date. It is convenient precisely because it skips the human ceremony, and that convenience is the whole problem. The thing that made it fast to create is the thing that made it impossible to find the owner of two years later. Identity governance, the discipline that runs joiner-mover-leaver for people, had no equivalent ceremony for the non-human population. So that population grew in the dark, un-owned by design, until an incident forced a flashlight onto it.

Across that same stretch my team was carrying other programs that did not slow for the incident — a global MDM onboarding from a recent acquisition, a chatbot platform migration, ordinary roadmap work that has no off switch. The service-account sweep was not the only fire. It was the one that taught me the most, because it exposed a category of risk that had been sitting in plain sight, fully enumerable and completely un-inventoried, the entire time.

What the sweep actually was

Strip the drama out and the work was unglamorous in the extreme. For each of two thousand-plus accounts: who owns this, what does it authenticate to, what privilege does it hold, is it still needed. Then a decision — rotate the credential, revoke it, re-scope it down, or verify and keep it — executed alongside the remediation the forensics team had recommended. Thousands of small determinations, each one boring on its own, dangerous only in aggregate.

I want the credit lines clean here, because they matter. An experienced CISO ran the security and forensics response; the investigation and the strategy were his, and engaging the outside forensics firm was his call, not mine. My lane was enterprise IT and identity: directing the team that found the accounts, found the owners, closed the gaps, and carried out the remediation in our lane. The accountability for getting it done was mine. Naming that split honestly is not modesty — in an incident, the fastest way to slow the whole room down is to blur who owns what.

There is a tradeoff worth admitting too. An all-hands manual sweep is the most expensive way imaginable to build a register, and it pulled people off planned work for weeks. We did it that way because there was no standing inventory to consult, so we built one by hand at the moment we could least afford to. The lesson is not “do heroic sweeps.” It is the opposite: the sweep is what you are forced into when the register does not already exist.

How to inventory machine identity before the agentic-AI wave

I would let all of this stay a 2022 war story, except the same gap is about to widen by an order of magnitude, and faster than any human process can track.

By every credible count, non-human identities already outnumber humans in most enterprises by a wide margin, and the curve is steepening. Agentic AI is the accelerant. An agent does not file a ticket and wait. It mints what it needs — a service account here, an API key there, a bot credential to call the next tool — at machine speed, spawning child processes that inherit privilege and act on their own across systems no single person is watching. Every one of those is a non-human identity with real access and, unless something deliberate intervenes, no owner. We are about to generate, automatically and continuously, exactly the category of un-owned credential that took an all-hands sweep to clean up the first time, when humans were still the ones creating them by hand.

The connection to the structural asymmetry I raised at the Gartner summit is direct. You cannot out-compute an attacker who finds an un-owned, over-privileged credential you did not know you had. That is not a fair fight you lose; it is a free win you handed over. No defensive budget reaches an account that is not on anyone’s list.

The register, before you need it

So here is the position I will sign, the one this incident earned: every non-human identity needs a human owner recorded at the moment of its birth, or it does not get to be born. Provenance is the control, not the paperwork you reconcile after the control fails. An identity created without a named, accountable owner is an incident with a delay timer on it.

In practice that is three disciplines, and none of them is exotic.

Govern the population you already have before you grow it. The machine identities are enumerable today; most enterprises have simply never run the query and then done the hard part, attaching an owner to every row. For the accounts that already have no owner, the answer is not the heroic sweep this piece argues against; it is inference. The probable owner is usually recoverable from signal you already hold: who last rotated the credential, which code repository’s CODEOWNERS calls the account, what network it originates from, the ticket that created it. Bind ownership where these identities are actually minted — the identity-governance layer and the secrets broker, the same SailPoint-and-Workday spine that already runs joiner-mover-leaver for people. Do the unglamorous reconciliation now, on an ordinary Tuesday, not during an incident.

Make the gate a control, not a guideline. The reason human identity is governable is the HR event at its center. Non-human identity needs the same enforced at provisioning: a required owner, a purpose, and an expiry, captured when the account is minted — including, especially, when an AI agent is the thing doing the minting. Deny-by-default — a required-owner policy in cloud IAM, a mandatory owner field the secrets broker will not write without — is what turns “every identity needs an owner” from a memo a busy engineer routes around by Friday into a wall they cannot. An identity with no owner-of-record should be as impossible to create as an employee with no hire date.

Default to expiry, and keep the register live. A credential that auto-expires can never quietly become the un-owned open door, so make short lifetimes the default: agent-minted credentials ephemeral, standing service accounts carrying a re-attestation date rather than living forever. And in an environment where agents spawn identities continuously, a once-a-year inventory is fiction the day after it is signed. The only register that survives is one that updates as the population does — event-driven, on every spawn, not annual.

This is the same lesson that runs under everything I have written about that incident, and the reason readiness was never a title. The cutover held because the playbooks existed before the fire. The service-account sweep was the exact opposite — the one piece of that response we had to invent on the spot, because the register did not exist when we reached for it. I never want to run that sweep again. The way you never run it again is to build the register when nothing is on fire, and to refuse, from now on, to create a single machine identity that no human will answer for.

The accounts were always listable. The owners were the work. In 2026, with agents minting credentials faster than any team can chase them by hand, closing the owner-of-record gap is the whole game.

Common questions

What is machine identity, and why is it a security risk? Machine identity — or non-human identity — covers the logins software uses rather than people: service accounts, API keys, RPA bots, CI/CD pipelines, and increasingly AI-agent credentials. They are a risk because, unlike human accounts, they are usually created with no recorded owner, manager, or expiry date, so they keep their privileges and outlive the project that created them. An over-privileged account no human is watching is a standing candidate for an attacker’s open door, and most enterprises cannot say on demand who owns each one.

Why couldn’t the company just list its service accounts during the 2022 breach? It could list the accounts — they sit in the directory, and a query returns the rows. What no enterprise could produce on demand was the owner of each account: the person accountable for why it exists, what it touches, and whether it should still be alive. That list lives in no system; it had to be reconstructed by hand. More than two thousand service accounts surfaced roughly a thousand named owners in an all-hands sweep — meaning a large share of the machine logins had no clean line to a human at all. That distance is the owner-of-record gap.

How is agentic AI going to make non-human identity harder to manage? An AI agent does not file a ticket and wait for an account to be provisioned. It mints what it needs at machine speed — a service account, an API key, a bot credential to call the next tool — and spawns child processes that inherit those privileges and act autonomously across systems no single person is watching. That generates, continuously and automatically, the exact category of un-owned credential that previously took an all-hands manual sweep to clean up, now far faster than any human governance process can track by hand.

What is the fix for the service-account ownership problem? Three disciplines. Govern the population you already have: the accounts are enumerable today, so run the query and attach an accountable owner to every row — inferring the probable owner from signal like the last rotation actor, the calling repository’s CODEOWNERS, or the ticket of origin rather than running a heroic sweep — in a quiet period rather than during an incident. Make the gate a control, not a guideline: require a named owner, a purpose, and an expiry at provisioning, denied by default at the IAM and secrets-broker layer, including when an AI agent is the thing minting the account. And keep the register live: default to short-lived credentials and event-driven reconciliation, because in an agent-driven environment a once-a-year inventory is out of date the day after it is signed.

Common questions

What is machine identity, and why is it a security risk?
Machine identity (or non-human identity) covers the logins software uses rather than people: service accounts, API keys, RPA bots, CI/CD pipelines, and increasingly AI-agent credentials. They are a risk because, unlike human accounts, they are usually created with no recorded owner, manager, or expiry date — so they keep their privileges and outlive the project that created them. An over-privileged account no human is watching is a standing candidate for an attacker’s open door, and most enterprises cannot say on demand who owns each one.

Why couldn’t the company just list its service accounts during the 2022 breach?
It could list the accounts — they sit in the directory, and a query returns the rows. What no enterprise could produce on demand was the owner of each account: the person accountable for why it exists, what it touches, and whether it should still be alive. That list does not live in any system; it had to be reconstructed by hand. In this case more than two thousand service accounts surfaced roughly a thousand named owners in an all-hands sweep — meaning a large share of the machine logins had no clean line to a human at all. That distance is the owner-of-record gap.

How is agentic AI going to make non-human identity harder to manage?
An AI agent does not file a ticket and wait for an account to be provisioned. It mints what it needs at machine speed — a service account, an API key, a bot credential to call the next tool — and spawns child processes that inherit those privileges and act autonomously across systems no single person is watching. That generates, continuously and automatically, the exact category of un-owned credential that previously took an all-hands manual sweep to clean up, except now far faster than any human governance process can track by hand.

What is the fix for the service-account ownership problem?
Three disciplines. First, govern the population you already have: the accounts are enumerable today, so run the query and attach an accountable owner to every row — for the un-owned ones, infer the probable owner from signal like the last rotation actor, the calling repository’s CODEOWNERS, or the ticket of origin rather than running a heroic sweep, in a quiet period rather than during an incident. Second, make the gate a control, not a guideline — require a named owner, a purpose, and an expiry at provisioning, denied by default at the IAM and secrets-broker layer, including when an AI agent is the thing minting the account. Third, keep the register live rather than a point-in-time audit: default to short-lived credentials and event-driven reconciliation, because in an agent-driven environment a once-a-year inventory is out of date the day after it is signed.