Agent governance is the program that decides who is accountable for an AI agent, what it is permitted to do, what must be approved before it reaches production, what gets reviewed while it runs, and what record exists of all of it. It is organizational rather than technical. Governance enforces nothing itself. It decides what the enforcement should say and who answers when it fails.
A team can have scoped credentials, supervision queues, and a complete action log and still have no governance, because nobody decided who may change the rules or who can stop an agent. The reverse is worse: a document describes a review board, and nothing in the running system matches it.
Key takeaways
- Governance is a set of decision rights: who owns an agent, who sets its limits, who approves the launch, and who can stop it. Each answer should name a person.
- The technical controls are downstream. Declared policy, enforcement, supervision, scoped permissions, and action records are how a governance decision becomes behavior.
- A pre-launch review is only useful if it asks for evidence rather than intentions, and if it can return the answer no.
- You cannot govern an inventory you do not have, and most programs fail first on not knowing which agents exist.
- Nothing here makes a system compliant or audit-ready. It makes questions answerable.
What governance actually decides
Strip away the framework language and a program answers five questions per agent, each with a name or a rule rather than a paragraph: who owns it, what it may do, whose authority it uses, what evidence is required before launch, and who can pause it when it fails. One more question spans the program: who may create an agent at all, and where is the list. An inventory naming each agent’s owner, purpose, and scope is what everything else depends on.
The review before an agent ships
Pre-launch review earns its cost when it asks for artifacts: permissions, data access, test results, failure plans, runtime records, and a named owner. Testing is where reviews are weakest, because teams assert that evaluations exist rather than showing results. A review should want cases, scorers, version, numbers, and what happened on cases designed to break the agent. Accepting a passing suite without asking which agent failure modes those tests can catch is being reassured rather than informed. A gate that never returns no is a formality teams learn to route around.
The review after it ships
Approval at launch describes a system that no longer exists a month later. Recurring review should read incidents, interventions, evaluation trends by version, policy denials, cost per run, and any capability added since launch. That last item is the quiet failure: a scope approved with three tools has seven a quarter later, each added in a pull request nobody read as a governance change.
Tying review to change rather than the calendar tends to work better. A reviewer who can open actual runs in an agent observability platform asks better questions than one reading a prepared summary, and OWASP guidance for agentic applications gives a concrete checklist for what those reviews should cover.
Evidence, and what it does not buy you
Every governance claim resolves to an artifact or it is a story: the agent inventory, approvals, evaluation results tied to versions, intervention records, action logs, and change history for prompts, models, tools, and rules. None of this makes a system compliant or audit-ready. Regimes such as the EU AI Act or GDPR may apply, and deciding which are in scope is for legal counsel. Internal governance is still worth building: it is how a team decides what an agent may do before finding out the hard way.
Where governance programs fail
Accountability assigned to a committee. Shared ownership means nobody is answerable when it matters.
No inventory. A program that cannot enumerate running agents is governing a subset without knowing which one.
Weight without discrimination. One heavy process for a read-only summarizer and for an agent that moves money. The first team routes around it and takes the second team’s credibility along.
FAQ
Who should own agent governance?
Split it. One accountable owner per agent, usually the lead who ships it, plus one owner for the program itself: the inventory, the review process, the escalation path. Legal, security, and privacy help set limits without becoming operators. The failure to avoid is a governance function with authority and no view of the running system.
What is the difference between agent governance and agent supervision?
Governance decides; supervision watches. Governance sets who is accountable, what the agent may do, and what evidence is required. Supervision is the operational practice of observing behavior and intervening, and it is one of the things governance should require. A program with no supervision has opinions and no feedback.
What should be required before an agent reaches production?
At minimum: a named owner, a written scope of actions and data, enforcement in code for the limits that matter, evaluation results covering the ways it could fail badly, a record of what it does at runtime, and a stated plan for pausing it. Scale the depth to what the agent can do. A drafting assistant and an agent with write access to production do not deserve the same review.
Does agent governance mean regulatory compliance?
No. Governance is internal: decision rights, accountability, and evidence about your own system. Regulatory obligation is external and depends on jurisdiction, industry, and use case, which is a question for counsel. A program producing real records makes external questions easier to answer, and neither substitutes for the other.
