Who owns AI agent governance

Agent governance fails most often because no single role owns it. It sits between security, compliance, model risk and platform engineering — and in that gap, each assumes another is handling it. The first governance decision is naming the owner.

Get an Agent Trust Gap Brief

The gap that produces incidents

Ask five people in an organisation who owns the behaviour of an agent that can send email and move money, and you will usually get four different answers and one shrug. Nobody is being negligent — agent governance genuinely spans four established functions, none of which has historically owned software that acts on its own.

Role	Owns today	Gap for agents
CISO / Security	Identity, access, incident response	Non-human identity at scale, and agents that authenticate as services but behave as users
Chief AI Officer	AI strategy, model selection, policy	Often has the mandate without the runtime enforcement or the budget for it
Model risk	Inventory, validation, monitoring	Agents rarely reach the inventory, because they are procured as tools rather than models
Compliance / Legal	Regulatory mapping, obligations	Depends on evidence they do not control and often cannot specify
Platform engineering	Runtime, deployment, integrations	Enforces what it is told to enforce, and is rarely told
Internal audit	Assurance	Asked to assure a thing with no evidence layer to audit

A workable division

The separation that holds under pressure is the one where recommending, executing, scoring and certifying are never the same party. If one function decides an action is safe and also performs it, the control is decorative.

One accountable owner, named. Not a committee. In DIFC this is close to a formal requirement; everywhere else it is simply how things get fixed.
Security owns agent identity. Non-human identity, credential lifetime, and revocation belong where identity already lives.
Compliance specifies the evidence. They should define what a receipt must contain, because they are the ones who will have to produce it.
Platform enforces at the effect boundary. Controls live in the component that sends, pays or writes — never in the agent asking politely.
Model risk inventories agents. In supervised institutions this is not optional; the examiner will build the inventory if you have not.
Audit gets an evidence layer, not a promise. If internal audit cannot verify without asking engineering to run a query, it is not assurance.

The question that settles it

Pick your highest-risk agent. Ask: if it takes a wrong action at 2am on a Sunday, whose phone rings, and what can they see?

If there is no clear answer to the first half, ownership is unassigned. If there is no clear answer to the second, you have an owner with no instrumentation — which in practice is the same problem wearing a name badge.

Common questions

Who should own AI agent governance?

One named accountable person, with security owning identity, compliance specifying evidence, and platform enforcing at the effect boundary. Committees diffuse accountability precisely when it needs to concentrate.

Should the Chief AI Officer own it?

They often hold the mandate, but mandate without runtime enforcement does not stop an action. Ownership needs to come with the ability to change what the effect boundary permits.

Do AI agents belong in the model inventory?

In supervised financial institutions, expect yes. Regimes like OSFI E-23 use broad model definitions, and assuming exclusion because the system is called an agent is not defensible.

What is the separation-of-duties principle here?

Recommending, executing, scoring and certifying should never be the same party. A system that approves its own actions has no control, regardless of how the approval is described.

What is the fastest way to find the gap?

Ask who gets paged when your highest-risk agent misbehaves at 2am, and what they can see when they open their laptop. The silence is the finding.