Who owns an AI agent?

Why does ownership come before everything else?

Ownership is the highest-weighted area in the register, alongside policy. That is deliberate. Every other control needs a person to act. Reviews need someone to confirm access. Approval rules need someone to say what counts as risky. Incidents need someone to decide whether the agent returns.

Without an owner, those decisions fall to whoever is nearest. Usually that is the security team, which does not know what the agent is for. The result is either paralysis or guesswork.

The control is GOV-02: assign every agent a named person who answers for what it does, and record that owner in the inventory.

Who should the owner be?

The owner should be the person who benefits from the agent's work and understands its purpose. Often that is the business lead who asked for the agent, not the engineer who built it. The engineer knows how it works. The business lead knows what it should and should not do.

Three rules keep ownership meaningful.

• One person. A team name, distribution list or shared mailbox cannot answer a question at two in the morning.
• A current employee. Check owners against the HR system every quarter.
• Senior enough to decide. The owner must be able to accept or refuse risk for the agent's actions.

Some organisations add a technical contact as a second field. That is useful, but the technical contact is not the owner.

What does the owner actually do?

The owner has a short, recurring list of duties. Writing them down makes the role real.

• Write and maintain the purpose statement (GOV-03).
• Approve the agent's initial access, matched to that purpose (GOV-04).
• Define which of its actions need human approval, using the approval matrix (GOV-07).
• Act as approver, or name the approver, for those actions.
• Confirm or remove each permission in the quarterly access review (GOV-15).
• Approve changes to the agent's tools and permissions (GOV-20).
• Take part in incident response and decide on recovery (GOV-19).
• Ask for decommissioning when the task ends (GOV-12).

None of these take long when done on schedule. All of them take a long time when done during an audit.

How do Microsoft and Okta handle ownership?

Identity providers now record owners for agents. Microsoft Entra Agent ID assigns a sponsor to each agent. Okta for AI Agents lets you assign human owners. Both are useful foundations.

A governance layer builds on that record. NewCore links every agent to an accountable owner and logs each call against that owner. Silverfort binds each agent to a human owner. Astrix Security maps every agent and MCP server to its owner. Descope records a documented purpose and accountable owner for every approved agent.

Where the identity provider and the governance layer both hold an owner field, decide which is the source of truth and sync the other. Two owner records that disagree are worse than one.

What happens when an owner leaves?

People change roles and leave. Agents keep running. This is where ownership most often fails.

Set a default rule: when an owner leaves or moves, ownership passes to their manager until a new owner is named. Trigger the change from the HR system, not from memory. Then give the manager a deadline, such as 30 days, to confirm a permanent owner or decommission the agent.

Run a monthly report of agents whose owner is no longer active. It should be empty. When it is not, it is the clearest early sign that governance is slipping.

How does ownership connect to the audit trail?

An audit trail that names only the agent's service account cannot answer the question auditors care about: which person is accountable for this action? Two people matter for each action. The person the agent acted for, and the owner who answers for the agent.

Control GOV-13 asks for every action to be logged with the agent, the person it acted for, the tool, the decision and the time. Linking the agent ID to its owner in the inventory completes the chain. Cyera Identity describes this as chain of custody from the human to each action. Silverfort describes an immutable audit trail linking each action to the initiating person.

What about agents supplied by vendors?

Third-party agents still need an owner inside your organisation. The vendor is responsible for its product. You are responsible for what it does in your systems.

Onboard vendor agents like new suppliers (GOV-21). The internal owner sponsors the onboarding, writes the purpose statement and holds the same duties as for an internal agent. If no one inside will own it, it should not connect.

How do you roll out ownership across many agents?

Start from the inventory. Sort agents by risk tier and assign owners to the highest tier first. For each one, send the proposed owner a short note: what the agent is, what it can reach, and what owning it involves. Ask them to accept or name someone better placed.

Expect some agents to have no willing owner. Those are candidates for decommissioning. An agent nobody will answer for is an agent you do not need.

Track the share of agents with a confirmed owner every month. Report it on the board one-pager. In most programmes this number moves fastest in the first quarter and is the clearest proof of progress.

What mistakes should you avoid?

Three mistakes recur. Teams name the builder as owner, then find the builder has moved on. They let one person own dozens of agents, which makes reviews a rubber stamp. And they record owners in a spreadsheet that nobody links to the audit log. Keep each owner's portfolio small enough to review properly, and keep the owner field in the same system as the agent's policies and evidence.

Where to go next

The agent owner RACI template sets who is responsible, accountable, consulted and informed for each activity. The quarterly agent access review template gives owners a worksheet. The control page for GOV-02 shows which platforms in the register document owner mapping, with sources.