All glossary terms
A Governance Operating model

Agent governance

A review board that meets monthly cannot govern something a team creates on a Tuesday afternoon. Agent governance has to run at the speed of the thing it governs, which means it is built as controls rather than written as a process.

Definition

Agent governance is the operational layer that keeps a population of agents accountable: what exists, what each one is permitted to do, and what each one actually did. It differs from AI governance in unit and cadence, governing individual running agents continuously rather than approving systems at a point in time.

What is agent governance?

This is the layer that keeps an individual running AI agent accountable for what it does. It works underneath the bigger rules set by the organization; it doesn't replace them. The organization's policies still decide what is allowed and who is allowed to do it. This layer is the machinery that makes sure each individual agent follows those rules and can show proof that it did.

The distinction from the wider discipline comes down to two things, and both matter operationally.

AI governance and agent governance compared by unit and cadence
Question AI governance Agent governance
The unit A system or a use case, assessed and approved One agent instance, of which there are many and more each week
The cadence Periodic. Assessment, sign-off, review Continuous. The agent is acting while you are reading this
The artefact A register of decisions, risk classifications and standards mapping A live inventory, scoped permissions, and a trace of every action
The failure A system deployed without appropriate assessment An agent nobody registered, doing something nobody authorised

Neither replaces the other and confusing them is expensive in a specific way. An organisation can hold a mature governance programme, correctly mapped to the standards, and still have no idea how many agents are running. The frameworks, the regulatory timeline and the decision-rights question are covered at AI governance. This page is the operational layer beneath it.

Why does the Agent population break the approval model?

Approval works fine when new things show up now and then. Building an AI model used to be a big project, needing a team, months of work, real budget. So, it made sense to check every model carefully before launch.

Agents are different. Making one does not take a big project anymore. Any skilled engineer can build a working agent over a given afternoon.

So, a process built to check a few big, rare things now has to deal with a flood of small, easy ones. The approval process was not built to handle that many, which is why it breaks down. You cannot check every agent as carefully as you once checked a full model.

The arithmetic is what breaks, not the intent.

A timeline over twelve months comparing two rates. Agents are created continuously by many teams, shown as a rising line reaching several dozen. Governance approvals happen at a monthly board, shown as twelve discrete points reaching twelve. The widening space between the two lines is labelled as agents running without individual assessment, and a caption notes that the gap is a function of cadence rather than of anybody behaving badly.
  • Creation is decentralised, approval is not. Many teams can create; one body approves. That asymmetry compounds every month rather than settling.
  • The reasonable response makes it worse. Tightening approval slows delivery, so teams route around it, and the agents you least know about become the ones with the least oversight. This is the mechanism described at agent sprawl.
  • Agents change after approval. A model assessed in March is the same model in September. An agent given a new tool in September is a different agent, and nothing in a point-in-time assessment notices.
  • Most agents are small. Individually they do not merit a committee, and collectively they hold real reach. Governance sized for the consequential ones ignores the population that actually carries the risk.

Which leads to the conclusion that shapes everything else on this page. You cannot govern a growing population through a process that runs on a calendar. The controls have to be in the path the agent takes, applied automatically, with human judgment reserved for the cases that genuinely need it.

What are the three questions it has to answer?

What exists, what may each one do, and what did each one actually do. Every agent governance conversation reduces to those three, and an organisation that cannot answer all three for any given agent does not have agent governance regardless of what its policy documents say.

Each maps onto a different control, and they are usually built in this order because each depends on the one before it.

Three questions shown as a stack, each mapped to the control that answers it. What exists maps to an inventory with an owner against every entry, described as the prerequisite for the other two. What may it do maps to scoped permissions, credentials and approval gates on irreversible actions. What did it do maps to a per-step trace recording the agent, the model, the user and the cost. A note states that an organisation unable to answer all three for a given agent does not have agent governance whatever its policy says.
  1. 01
    What existsA live inventory with an owner against every entry, discovered rather than self-declared. Why it comes first: the other two controls can only be applied to agents you know about, so this is the prerequisite rather than the paperwork. See agent registry.
  2. 02
    What may it doScoped tools and data, its own credential, a spend ceiling, and approval required on anything irreversible. Why it matters more than accuracy work: it bounds the worst case rather than shifting its probability. See AI guardrails and agent identity.
  3. 03
    What did it doEvery model and tool call recorded with the agent, the model, the human it acted for, and the cost. Why the human matters: without it you can show what happened and not on whose authority. See AI audit trail.

The useful property of this framing is that it is testable rather than aspirational. Pick an agent at random, ask all three questions, and time how long the answers take. A governance programme that cannot answer them in minutes will not answer them during an incident either, and an incident is when the questions actually get asked.

Why must Agent Governance run at runtime?

Because the thing being governed is acting continuously, and a control that only operates before deployment governs a snapshot. The shift is from assessing whether a system should be allowed to a position where permitted behaviour is enforced as the system runs.

Three consequences follow, and each replaces a familiar practice rather than supplementing it.

  • Assessment becomes a gate rather than the control. Pre-deployment review still matters and it stopped being sufficient once the output space became unbounded, which is the argument at generative AI. The control is what holds while the agent runs.
  • Policy has to compile into configuration. A rule stating that customer data may not leave the region is governance when it is a network constraint and a preference when it is a sentence in a document. If a policy cannot be expressed as a scope, a gate or an alert, it will not be enforced.
  • Evidence is produced rather than assembled. Gathering evidence after the fact is expensive and incomplete. A trace that already records agent, model, actor and cost turns an audit into a query.

Who owns an agent?

Someone in the business must be named responsible for the agent, not the engineering team that built it. This question usually goes unanswered.

Engineering can explain what an agent does but cannot own the consequences of what it decides. Those consequences land in a business process that engineering does not run.

Four roles, and the second is where programmes stall.

Four roles in agent governance and what each is accountable for
Role Accountable for
Builder What the agent does, how it is tested, what it is permitted to reach. Usually well defined already
Business owner The outcome of the actions it takes, and the decision to keep running it. The role most often vacant
Risk Whether the controls match the exposure, and what triggers escalation
Whoever can stop it Holding the authority and the access to halt it, on a weekend, without an engineering cycle

The two marked rows are the ones to fill first. An agent with no business owner is an agent nobody will retire, because retirement requires somebody to accept that the work it was doing now needs doing another way. That is the quiet reason agent estates only grow, and it is a governance failure rather than a technical one.

How do you start?

By finding what you already have, before writing anything. Most organisations discover more agents in use than anyone recorded, and the unrecorded ones hold the credentials nobody rotates. Policy written before that discovery describes an estate that does not exist.

Five steps, ordered by what each one makes possible.

  1. Discover, do not survey

    Ask the platforms rather than the people. Self-declaration misses exactly the agents you most want to find, because the ones nobody registered are the ones nobody will remember to mention.

  2. Put an owner against every entry, even a provisional one

    A name in a field is worth more than an accurate but empty register. Provisional owners get corrected quickly; absent owners stay absent.

  3. Bound before you assess

    Scope what each agent can reach and cap what it can spend, ahead of any quality or risk review. A bounded agent that is sometimes wrong is manageable; an unbounded one that is usually right is not.

  4. Turn three policies into controls as a test

    Take three rules from your existing AI policy and express each as a scope, a gate or an alert. The ones that will not compile are the ones that were never going to be enforced, and finding that out early is the point.

  5. Run the three questions as a drill

    Pick an agent at random each month and time how long it takes to answer what it is, what it may do and what it did last week. The trend in that number is the most honest governance metric available.

One note on sequencing that runs against how these programmes are usually sold. Standards conformance is a consequence of having the controls, not a route to them. A management system standard tells you which controls to hold and evidence; it does not build the inventory, scope the permissions or produce the trace. Teams that certify first and instrument second end up with documentation describing an estate they still cannot see.

Frequently asked questions about agent governance

If your question is not here, our team will answer it directly.


Talk to a Specialist →
What is agent governance?

The layer that makes an individual running agent accountable. It sits beneath the organisational discipline rather than replacing it: policy still states what is permitted and by whom, while this is the machinery making each specific agent conform and prove that it did. The difference comes down to unit and cadence, governing one agent instance continuously rather than approving a system at a point in time.

How is agent governance different from AI governance?

By what is governed and how often. AI governance assesses a system or use case periodically and produces a register of decisions, risk classifications and standards mapping. Agent governance governs one agent instance continuously and produces a live inventory, scoped permissions and a trace of every action. An organisation can hold a mature governance programme, correctly mapped to the standards, and still not know how many agents are running.

Why does approval stop working for agents?

Because approval was designed for things arriving occasionally. Building a model was a project, so assessment fitted its cadence. An agent can be created by a capable person in an afternoon, and most of your engineering organisation is now capable. Creation is decentralised while approval is not, so the gap compounds monthly. Tightening approval makes it worse, because teams route around it.

What are the three questions of agent governance?

Which agents are there, what is each one allowed to touch, and what has each one already done. Strip any conversation on this subject back far enough and those three are what remain. Cannot answer all three about a specific agent? Then whatever the policy binder says, the governance is not there. They are built in that order because each depends on the one before: you can only scope and trace agents you know about.

How do you test whether agent governance is working?

Pick an agent at random and time how long it takes to answer the three questions: what it is, what it may do, and what it did last week. That number is testable rather than aspirational, and its trend is the most honest governance metric available. A programme that cannot answer in minutes will not answer during an incident, which is when the questions actually get asked.

Why does agent governance have to run at runtime?

Because the thing being governed is acting continuously, so a control operating only before deployment governs a snapshot. Assessment becomes a gate rather than the control itself. Policy has to compile into configuration, since a rule about data not leaving a region is governance when it is a network constraint and a preference when it is a sentence. And evidence gets produced as the system runs rather than assembled afterwards.

Can runtime controls provide human oversight?

Not in the sense the word usually implies, and claiming otherwise sets an expectation you cannot meet. Agents decide in milliseconds while people operate in minutes, and nothing in runtime control closes that gap. What these controls do is bound the consequences of a decision nobody reviewed and shorten the interval before somebody can intervene. That is genuinely valuable and it is not the same thing as oversight.

Who should own an agent?

Somebody in the business, by name, rather than whoever wrote it. A build team can describe an agent's behaviour precisely and still has no standing to absorb the fallout from its decisions, since that fallout arrives inside a process they neither run nor answer for. Four roles matter: the builder, the business owner, risk, and whoever holds the authority and access to stop it on a weekend without an engineering cycle.

What happens if an agent has no business owner?

It never gets retired. Retirement requires somebody to accept that the work it was doing now needs doing another way, and with no owner nobody holds that decision. This is the quiet reason agent estates only ever grow, and it is a governance failure rather than a technical one. A provisional owner in a field is worth more than an accurate register with the column empty.

How do you turn AI policy into agent controls?

Take three rules from your existing policy and try to express each as a scope, a gate or an alert. The ones that compile become enforceable controls. The ones that will not compile are the rules that were never going to be enforced, and discovering which is which early is the point of the exercise. Policy that cannot be expressed in the runtime is a statement of intent.

Should you certify against a standard first?

Usually not, and this runs against how these programmes tend to be sold. Standards conformance is a consequence of holding the controls rather than a route to them: a management system standard tells you which controls to hold and evidence, and it does not build your inventory, scope your permissions or produce your trace. Teams that certify first and instrument second end up documenting an estate they still cannot see.

Where should you start?

By discovering what you already have, before writing anything. Ask the platforms rather than the people, because self-declaration misses exactly the agents you most want to find. Then put an owner against every entry even provisionally, bound what each can reach and spend before any quality review, and only then write policy. Policy written before discovery describes an estate that does not exist.

Keep reading

Terms that come up in the same conversation

Browse the full glossary
A

AI governance

The discipline above this one: decision rights, the frameworks, and the regulatory timeline.
A

Agent registry

The control that answers the first question, and why authority is set by what happens to an agent not in it.
A

Agent sprawl

What the cadence gap produces, and why it is a rate problem rather than a headcount problem.

What exists. What may it do. What did it do.
Pick an agent at random. How long do the three answers take?

SERAA Cortex holds every agent in one registry with auto-discovery and full version lineage, scopes prompts, keys and rules per tenant, gates promotion through Dev, QA and Production, and records every model and tool call with the agent, the model, the user and the cost.

Book a demo Explore SERAA Cortex