Who Owns It: Agentic Identity and the Accountable Owner 

This is installment five of seven in our AI risk management series. Previously: you can prove the running system still matches its design. This installment: that proof is only defensible if every action ties back to someone. 

When an AI system does something it should not have, the first question is never technical. It is “who owned this?”

I have watched capable organizations answer that question with a shrug, or worse, with a meeting to figure out whose problem it is. Every control in this series has been building toward the moment an examiner, or a board member, or a plaintiff’s lawyer asks it in five words: who is responsible for this?

If your evidence cannot resolve to a name, you do not have evidence. You have an anecdote. 

You already govern a workforce 

Here is the reassuring part (and I mean it): You already know how to do this. You have spent decades governing a workforce. You onboard people, you give them the least access they need, you hold them accountable for what they do with it, and you offboard them when they leave.  

That discipline is exactly what agentic AI needs.  

What’s changed? Now your workforce is hybrid. It includes humans, the non-human identities your systems have always had, and a fast-growing population of agents that act on their own initiative. In most shops the non-human identities already outnumber the people, and agents compound the count faster than any hiring plan ever could.

Extend the discipline you already have to the new kind of worker and most of this is familiar. Refuse to and you’re running a workforce where a meaningful share of the workers have no manager, no badge, and no record. 

The identities you must be able to name 

Agentic AI breaks a quiet assumption in most identity programs: that an action has one actor. In an agentic workflow, it rarely does. To govern one action, you have to be able to name four things: 

1. The human who started it, the invoking user 

2. The agent or non-human identity that actually executed it 

3. The human product owner who is accountable for that agent, whether or not they were in the room 

4. Lastly, the one everybody forgets until it burns them: when agent A hands off to agent B, who authorized B to act, and under whose authority?  

That last one, the invocation or delegation chain, is where identity programs built for humans quietly fail, because a human does not usually act on behalf of another human three hops down a chain in milliseconds.

Agents do it constantly.

If you cannot reconstruct that chain, you cannot answer “who is responsible,” because the honest answer is “a sequence of things, and we are not sure which.”  

Reconstruction is only possible if something threads the chain end-to-end: a trace that follows the task through every handoff, not just the logs that each agent keeps about itself. 

Governance that travels with the workflow 

The instinct from network security is to draw a boundary and watch what crosses it. Agentic systems do not respect the boundary. The workflow is now the perimeter. An agent picks up a task, calls a tool, hands off to another agent, touches a data source, and returns, and the whole path may never cross a network line you are watching. Identity and policy have to travel with the workflow, not sit at a gate it walks around.

The authorization that applied when the invoking user kicked things off has to still apply when agent B, two hops later, reaches for a credential. If it does not, you have a workflow that launders authority: it starts with a person who was allowed to do a small thing and ends with an agent doing a large thing that nobody approved. 

One owner, across the seams 

The anchor article of this series made a point I want to make again. Large enterprises often run multiple governance, risk, and compliance tools, and agentic AI falls into the seams between them. Identity is how you close the seam.  

Every agent gets one accountable human of record, assigned when the agent is created, not reconstructed later when someone needs a name for the incident report. The org has to decide how to run this, centralized in one governance function or federated to the business lines with a shared standard. There are good arguments for each depending on your size and regulatory surface. What is not optional is the rule underneath both models: nothing runs in production without an owner.  

The workforce discipline has one more piece that has to come along: offboarding. Agents get retired, superseded, and orphaned by owners who leave, so ownership must transfer the way direct reports do: on the way out the door, not by archaeology after an incident. A stale agent with live credentials is the new stale account, except this one acts on its own initiative. 

Where the standards put this 

This is not a preference. The standards do not use the language of agentic identity, but they point in the same direction: roles, responsibilities, traceability, monitoring, and human oversight.  

NIST’s Govern function assigns roles and responsibilities, and its Manage function expects you to be able to trace an action and respond to it.  

ISO/IEC 42001 puts leadership and organizational roles in Clause 5 and carries resource and life-cycle controls through Annex A.  

The EU AI Act, for high-risk systems, requires record-keeping and traceability over the system’s life (Article 12) and places specific obligations on the deployer who puts the system to use (Article 26). Read together, they describe the same thing an incident does: a chain of actions that must resolve to an accountable identity. 

Here is what that looks like as an exhibit: the identity and ownership control, the requirement it answers, and the test that produces it. 

Exhibit: from identity and ownership to standard. 

The objection, again, and who it answers 

The builder reads “assign an owner to every agent” and hears a manual chore that does not scale, a person clicking through a form for every new agent while the backlog grows. That is the wrong version of this.  

Ownership and identity assigned by hand do not scale, which is exactly why they have to be a property of the platform: the agent gets its identity, its provenance, and its accountable owner at the moment it is created, and its credentials are scoped, short-lived, and revocable without anyone touching code.  

Do it that way and the security leader gets the runtime control plane and the kill switch she has been asking for and the builder gets self-service instead of a ticket queue. Privacy can trace any output to an owner and a purpose, and the executive finally has a real answer to “who is responsible” before the board asks. 

The loop closes 

Attribution is the least glamorous capability in a governance program and the first one you will wish you had.  

Every other control in this series produces evidence. Identity is what makes that evidence mean something, because an action nobody owns is not governed. It is just something that happened.  

Get this right and the whole loop closes: you can see the system, you approved its design, you proved it ran inside that design, and now you can say, without a meeting, exactly who stands behind every move it made. 

Next installment: a well-owned program still has to be affordable, and its cost has to have an owner too. Next, the economics of AI risk.