What is AI agent governance?

What does agent governance actually mean?

An AI agent is software that takes actions on your systems, often on behalf of a person. It reads data, calls tools and changes records. Governance is how you decide which of those actions are acceptable, who is answerable for them and how you prove it afterwards.

Most organisations already govern people. They know who works there, what each person can access and who approved that access. Agents break this model in three ways. They are created quickly, often by individuals rather than a central team. They act at machine speed, so a mistake repeats thousands of times before anyone notices. And they act for someone, which blurs the line between the agent's permissions and the person's.

Agent governance closes those gaps. It is not one product or one setting. It is a set of controls that together answer five questions. Which agents exist? Who owns each one? What may each one do? Who approves the risky things? And what record shows it all happened as intended?

How is it different from identity and access management?

Identity and access management, or IAM, answers who you are and what you may reach. Your identity provider signs people in, applies conditional access and runs access reviews. Okta and Microsoft Entra now extend some of this to agents, with agent registration, owners and sponsors.

Governance adds the layer that IAM was not built for: the individual action. An agent with valid access to a finance system might still try to approve a payment it should not. Sign-in checks happened an hour ago. What matters is the call happening now.

That is why the register scores per-action policy and human approval as their own areas. A governance layer runs alongside your identity provider, never instead of it. The identity provider keeps employee sign-in. The governance layer watches what agents do with the access they already have.

Which controls make governance real?

The register tracks 24 controls, grouped into seven areas. You do not need all of them on day one, but each area answers a different question an auditor or board member will ask.

• Inventory: a current list of every agent, including the ones nobody registered (GOV-01, GOV-16).
• Ownership: a named accountable owner and a purpose statement for each agent (GOV-02, GOV-03).
• Policy: a check on every action, with tools outside the allow-list hidden (GOV-06, GOV-10).
• Approval: a named human approver for high-risk actions, with no self-approval (GOV-07, GOV-08).
• Audit evidence: a per-action log tied to a person, exported to the SIEM (GOV-13, GOV-14).
• Lifecycle: short-lived credentials, a kill switch and decommissioning at task end (GOV-05, GOV-11, GOV-12).
• Buying clarity: whether you can understand the price and procurement path.

The weights in the register reflect where governance programmes tend to fail. Ownership and policy carry the most weight. An agent with no owner and no per-action check is the most common gap we see in vendor material.

Why does ownership matter so much?

Every other control depends on someone answering for the agent. Access reviews need an owner to confirm each permission. Approvals need an owner to define what counts as risky. Incidents need an owner to decide whether the agent comes back.

An owner must be a named person, not a team or a shared inbox. When that person leaves, the owner role moves to their manager until someone new takes it. This sounds administrative, but it is where many programmes break. Agents outlive projects, and the person who built one is often gone a year later.

What does per-action policy look like?

A per-action policy is a rule checked at the moment an agent tries to do something. The check uses the agent, the person behind it, the tool and the data. The outcome is one of three: allow, ask or deny.

Allow lets routine work flow. Deny blocks what should never happen and records the attempt. Ask is the important middle. It pauses the action and sends it to a named human approver, who confirms or refuses before anything changes.

Good policy engines let you test a rule before it goes live. Policy replay runs a new rule against recorded sessions and shows what it would have allowed, sent for approval or blocked. Without that test, a strict rule breaks legitimate work and a loose one lets risky calls through.

Where does human oversight come in?

Regulators increasingly expect people to be able to oversee AI systems. The EU AI Act requires human oversight for high-risk systems. Article 14 says the people assigned oversight must be able to override or reverse outputs and stop the system safely.

For agents, oversight has three practical parts. A named approver for high-risk actions. A readable audit trail that shows what happened and why. And a kill switch that cuts an agent off from tools in minutes, not days.

An agent should never approve its own action. That sounds obvious, but few vendors state it. In the register, only NewCore documents this rule explicitly.

What evidence will an auditor ask for?

Auditors will ask for the inventory first, then a sample. For each sampled agent they want the owner, the purpose statement, the permissions and the last access review. Then they pick an action and trace it.

A useful audit log answers that trace in one place. It names the agent, the person it acted for, the tool, the policy decision and the time. It includes denied and approved actions as well as allowed ones. It reaches your SIEM so security can correlate it with other events. And it is kept long enough. For high-risk systems the EU AI Act sets at least six months for automatically generated logs.

How do you start?

Start with the inventory. Run discovery across identity providers, clouds, SaaS and code. Register what you find, and give every agent an owner before anything else.

Next, pick the five actions that would hurt most if an agent did them wrongly. Put those behind human approval. Then replace static keys with short-lived credentials, starting with agents that touch production data.

Finally, schedule the first quarterly access review and the first board one-pager. Both create a rhythm. Governance that only happens during an audit is not governance. It is a scramble.

Where to go next

The register compares ten platforms on these controls, with a reason and a source for every score. The templates give you a policy, an approval matrix and a review worksheet you can adopt. The other guides go deeper on inventory, ownership, approval rules, audit evidence and working alongside Okta or Entra.