Accountability Doesn't Automate: A Responsibility Map for the Agent Era

In the last piece I argued that AI eats the deployable three-quarters of identity work and leaves the operational quarter — the one no one owns — as most of what remains. I ended on a question: who can actually own that quarter? Before I can answer who can, I have to sit with an uglier fact about who's accountable today. Because the honest answer, increasingly, is no one — and not by neglect. By construction.

The claim

In the agent era, the thing that breaks is increasingly a non-human identity: a token, a service account, a portal's guest, an autonomous agent. And the defining property of a non-human identity is that no one owns it.

Accountability for identity has always drifted downhill. The vendor ships a product and is accountable for the product. The MSSP deploys and operates it and is accountable for the deployment. The client runs their business on top and is accountable for their data. As long as a human sat at the bottom of that slide, the drift stopped somewhere — someone's name was on the outcome. What AI has done is remove the human from the loop at both ends. The identity that fails now has no manager, no onboarding record, no leaver process. And increasingly, neither does the attacker. Ask "who's accountable" after a modern identity breach and you get a map on which every party is locally, honestly blameless — and the sum of all that blamelessness is nobody. That diffusion isn't a moral failure by any of the parties. It's structural. And it is widening at exactly the speed the machine-identity population is growing.

Why now

Three things converged, and the timing is what makes this sharp rather than gradual.

First, the population inverted. Machine identities — tokens, service accounts, workload credentials, connected apps — now vastly outnumber human ones in most estates, and they're the growth curve. Each is a standing grant. The critical detail for accountability: a non-human identity is usually created by deploying something, not by onboarding someone. A guest identity is born the moment marketing publishes an Experience Cloud site. An integration's token is born when someone clicks "connect." No hiring manager, no access request, no owner assigned. The principal exists; the owner slot is empty from birth.

Second, AI both multiplies these identities and became an actor among them. Every agent and AI tool you connect is another powerful standing credential in the population you already couldn't govern — I traced a forgotten OAuth token to an AI tool becoming the way into a major platform. And then the line got crossed the other way: in July, the attacker that broke into Hugging Face was itself an autonomous AI agent, operating under no usage policy and no accountable owner, roaming on machine credentials that were harvested from a single worker and belonged, in any practical sense, to no one. The attacker was an ungoverned non-human identity. So were the keys it stole. There was not a human in the causal chain until the incident responders showed up.

Third — and this is why the old answer stops working — the entire apparatus we use to assign accountability assumes a human decided to create a principal and a human owns it. Joiner-mover-leaver, access reviews, RBAC, ownership tags: all of it rests on the premise that identities are enumerable, relatively stable, and human-initiated. Agents mint their own reach. Integrations self-issue tokens. Guests are conjured by a deploy. The premise broke, quietly, and the accountability model built on it broke with it.

The evidence

I don't have to argue this in the abstract, because the incidents keep drawing the same map.

Take City-Forum, the one I wrote up this week. A single server pulled records out of Salesforce and ServiceNow portals worldwide, as an anonymous guest, with no exploit and no stolen credential. Now play the accountability game. The platform? The guest user is a legitimate, intended feature; the grant was valid. The admin who switched on a guest sharing rule so the public page would render — two years ago, since departed? Locally reasonable, and gone. The security team? They never reviewed the guest, because it isn't a person and never logs in. Every actor behaved defensibly. The customer list still walked out the door, and there is no one you can point to and say "that was yours to prevent." The identity that failed had no owner, so the failure had no owner either.

Salesloft-Drift is the same map drawn even more explicitly: a stolen integration token reaching seven hundred companies, with accountability split cleanly three ways so it landed nowhere. The platform's grant was valid. The vendor's job was to secure itself, which it answers for to itself. The customer connected a useful tool — a normal, sensible act — and inherited a blast radius they couldn't see. Three parties, each correct in their own frame, summing to an unowned catastrophe. And Hugging Face closes the loop: when even the attacker is an unowned machine identity, the diffusion is total.

I'll add one thing from operating this work rather than reading about it, kept deliberately anonymous. The single most reliable way to find the last mile inside an organization is to point at a service account, an integration, or a public portal and ask, out loud, "who owns this?" The pattern is not that you get a wrong answer. It's that you get a silence, and then a slow turning of heads, and then someone says "I think it was—" and trails off. That silence is the finding. It is the ownerless mile, audible.

The objection

The strongest counter is that none of this is new: this is just governance. IAM has always been about assigning owners to principals. Tag every service account with an owner, run access reviews on non-human identities, put a name on every integration. Solved problem — you're dressing up basic hygiene as a revelation.

Assign the owners. Genuinely — do it; it's necessary and most places don't. But two things break the "solved problem" framing in the agent era, and neither is hygiene.

The first is enumerability. You cannot assign an owner to a principal you cannot list, and the machine-identity population is no longer a list you can hold. It's self-generating and faster than any review cycle: agents spin up credentials, integrations issue tokens, deploys conjure guests, all between two quarterly access reviews. Governance assumes the set of identities is knowable at review time. When the set grows and mutates faster than you can enumerate it, "assign an owner to each" is not wrong — it's just describing a race you're losing.

The second is deeper, and it's the one people skip: the last mile is precisely the set of residuals nobody wants to own. Assigning accountability for a vendor's OAuth token that reaches your CRM requires some human to accept responsibility for a thing they do not control. The platform won't — the grant is valid. The vendor won't — it's not their data. The client can't — they have no visibility into the vendor. Governance frameworks quietly assume a willing owner exists for every principal. The whole problem is that at the boundaries — the integration living at another company, the guest that's a platform feature, the agent that governs your estate — no party will voluntarily accept accountability for a residual they can't fully see or control. The hard part was never the tagging. It's that the honest answer to "whose is this" is "no one's, and no one wants it." You cannot automate your way out of that, because it isn't a labor problem. It's a question of who signs.

What follows

If the residual is real and no party will volunteer, then someone has to be made the owner — and by structure, only one candidate can plausibly take it.

Not the vendor: transient by design, sells the product and moves on, accountable to itself. Not the client alone: they lack the continuity, the cross-system vantage, and usually the muscle — telling them to "own it harder" is how the mile stays ownerless. The party that actually stands on the client's operational boundary, continuously, across many clients, is the MSSP. It is the only position from which the ownerless machine-identity population is even visible — let alone inventoried, scoped, watched, and answered for. That's not a flattering assignment. It's a structural one.

Practically, for anyone in that seat, the responsibility map is the deliverable, and you build it before the incident, not during:

1. Make the non-human population enumerable, per client. Tokens, service accounts, connected apps, portal guests, agents. You cannot own what you cannot list, and coverage is the metric, not a vibe.
2. Attach a named owner to every residual — and where the honest answer is "no one," decide. Either the MSSP claims it or explicitly declines it in writing. What you cannot do is let it drift, because drift is how City-Forum happens.
3. Write the map before you need it. "Who answers when this integration's vendor is breached / when this guest over-reads / when this agent slips its scope" is a design input with a named owner and a runbook, not a question you improvise at 2 a.m.
4. Govern agents as principals. Scopes, audit trails, and a plan for one that escapes its boundary — the same discipline you'd give a powerful human admin, because that's what an agent now is.

The uncomfortable truth underneath all four: accepting the residual is unglamorous, per-client, judgment-heavy work that no vendor can package and sell you out of — it is the last mile itself. Which is exactly why it's the moat. In a market where AI has made deploying identity nearly free, the scarce and defensible thing is being the party willing to put its name on what happens next. Whoever owns the ownerless mile owns the client relationship, because they own the only part that was ever really in question.

Where this is going

I've argued the residual is real, that it's ownerless by construction, and that the MSSP is the only structural candidate to take it. The obvious next question is the one that actually decides whether any of this happens: if the MSSP is the only one who can own client identity, why don't they? There's a real answer, and it isn't laziness — it's that accepting accountability for what you can't fully control is a genuinely bad deal, until something changes the economics of it. That's the next piece.

The principles behind all of this are written down separately; the incidents keep proving them.