AI Agent Governance: What It Takes to Run an Agent Estate

The first hard question about AI governance rarely comes from a regulator. It comes from an internal auditor, and it sounds like this: show me what this agent did on 14 March, what data it read, and who said it could.

Most enterprises cannot answer. Not because they were careless, but because agents arrived through a door that governance had never needed to watch. Software used to be procured, reviewed and deployed by people whose job was to procure, review and deploy software. Agents get built by a business analyst on a Thursday afternoon.

That is the shift governance has to catch up with, and it is now on a clock. Gartner published its first Magic Quadrant for AI Governance Platforms in June 2026 — more than 100 vendors were marketing governance capability and 13 qualified. Magic Quadrants appear when a market stops being experimental. The regulatory calendar is moving in parallel: the EU AI Act's transparency obligations under Article 50 apply from 2 August 2026, the date the European Commission also gains enforcement powers, while the high-risk obligations covering systems that touch employment and finance were pushed out to 2 December 2027 under the Digital Omnibus agreed in June 2026.

The extra runway applies to conformity assessment, not to the design work. Documented human oversight, record-keeping and logging have to be built into how agents operate, and those are architectural decisions that get expensive to retrofit.

A second question is arriving behind the first. Agents have started calling other agents: agent-to-agent protocols and MCP gateways exist precisely so a change agent can ask a CMDB agent for an impact assessment without a person in the middle. That makes authorisation harder than it looks. How does the receiving agent know the requesting agent is entitled to ask, and under whose authority the request is being made? Identity systems answer this for people, with roles and tokens tied to an employee. Cross-agent delegation has no equivalent that most enterprises have actually deployed, so a request tends to be honoured because it arrived rather than because the requester was verified.

Few organisations are running that at scale today, which makes it the rare governance problem you can get ahead of instead of remediating.

Governance is not a document

Most organisations respond to this by writing a policy. The policy is usually sound, and it usually changes nothing, because a policy that isn't enforced at a specific moment in an agent's life is a statement of intent.

What works is gates. Four of them, each attached to a point where an agent's status actually changes.

Gate 1: Admission

Nothing runs without an owner.

Before an agent is switched on, four things need to exist: a named human owner, a stated purpose written as an outcome rather than a capability, the scope of systems and data it may touch, and a classification of the most sensitive data within that scope.

This gate does most of the work, and it is the one people skip because it feels like bureaucracy at the exact moment the thing finally works. But an agent admitted without an owner never acquires one later. It simply runs until someone notices it, which in practice means until it does something wrong.

A useful test for whether this gate is real: can someone build an agent that reaches a production system without a second person knowing? If yes, you don't have an admission gate. You have a form.

Gate 2: Authority

An agent needs its own identity, not a borrowed one.

The common failure is an agent acting under the credentials of whoever built it. It inherits their access, which was scoped for a person doing a job, not for a process running continuously. When that person changes role, the agent keeps the old permissions and nobody revokes them, because revocation follows people, not the software they left behind.

Authority means: a distinct identity per agent, explicit scopes rather than inherited ones, credentials that expire, a revocation path that works without finding the original builder, and a defined boundary between what the agent may do alone and what requires a human. That last line is the one to write down carefully. It is the difference between an agent that raises a change request and an agent that implements one.

This gate is also where cross-agent delegation will be governed as it arrives. An agent receiving a request from another agent has to establish not only which agent is asking but whose authority it is acting under, and that check needs recording like any other. Building agent identity properly now is what makes that tractable later.

Gate 3: Observation

Policy operates before execution. Observation operates during it, and it is the gate most programmes don't have at all.

Three things need watching. Behaviour: is the agent doing what it was admitted to do, or has its use drifted into territory nobody assessed? Quality: agents degrade as the content beneath them ages, so a knowledge source that goes stale quietly turns a reliable agent into a confidently wrong one. And cost: consumption is invisible until it isn't, and an agent nobody is watching is an agent nobody is costing.

Observation is also where you find out which agents are actually being used. In most estates that number is far smaller than the number built, and knowing it is the difference between an inventory and a portfolio.

Gate 4: Evidence

An audit trail is not a log of outputs.

To answer the auditor's question, the record has to reconstruct a decision: who authorised this agent to operate, what context it had in front of it at the time, what it decided, what it then did, and whether that was consistent with the policy in force that day. Four of those five are usually missing.

The reason to build this before you need it is that evidence cannot be reconstructed retrospectively. If the context an agent used in March wasn't captured in March, no amount of investigation in September will recover it.

Evidence is also what makes retirement possible. An agent with a complete record can be switched off with confidence, because you can see what depended on it. An agent without one gets left running, because nobody is willing to be the person who broke something invisible.

You have run this discipline before

Here is the part that makes this less daunting than it sounds. Enterprise IT already has a mature practice for controlling changes to production systems made by people with good intentions and incomplete visibility. It is called change enablement, and it consists of exactly these gates: a request with an owner, an assessment of scope and risk, an approval boundary, execution, and a record.

Agent governance is not a new discipline that needs a new committee. It is an existing discipline that needs to be extended to a new kind of actor. Organisations that treat it that way move considerably faster than those that stand up an AI council and start from a blank page, because the muscle, the tooling and the cultural expectation already exist.

The extension is not free. Agents differ from changes in three ways that matter: they act repeatedly rather than once, they carry their own memory and context, and they can be created by people who have never filed a change request in their lives. Your existing process will need to account for all three. But it is an adaptation, not an invention.

Where the gates live

Governance capability is not evenly distributed across the places agents get built, which is why placement and governance are the same decision viewed from two angles.

Some environments give you admission and evidence by default, because agents are scoped and defined by the product rather than created ad hoc. Others give you powerful controls that must be deliberately configured, and creation so frictionless that ownership has to be imposed rather than assumed. Others give you a strong model layer and leave the entire service-level record for you to build.

None of these is wrong. But an organisation that puts agents somewhere with weak default gates has taken on the obligation to build those gates itself, and that cost belongs in the decision rather than in next year's remediation programme.

The reason to do this

Compliance is the obvious argument and the weakest one.

The stronger argument is that ungoverned agents get switched off. Not by regulators — by the CIO, after an incident, in a decision that takes ten minutes and removes eighteen months of work. Every enterprise agent programme that has been paused was paused by someone internal who could not answer a question about what the agents were doing.

Governance is what lets you keep going. It is the difference between a pilot that expands and a pilot that gets quietly wound down, and it is worth building before you have three hundred agents rather than after.