AI Agent Governance Framework: How to Govern AI Agents With Approved Processes
By Kirill Stolbushkin
Short answer: An AI agent governance framework decides what each agent may do, who answers for it, and when a person has to step in. The practical version has six parts: an owner for every agent, an approved process it follows, authority limits, approval gates at the risky steps, version control on the process, and a way to stop it. Underneath sits a technical layer of identity, logging, testing and incident response. Start with the process. If you can't draw what the agent is supposed to do, you can't govern it.
What is an AI agent governance framework?
An AI agent governance framework is a written set of rules for what each AI agent may do, who answers for it, and when a person must step in.
A quick note on where I stand: I'm Kirill, one of the founders of Vevos, and governing agents through approved processes is exactly what we build. I'll keep the framework itself tool neutral and save the product for one section near the end. If you'd like to see a process drawn from a plain description while you read, open the free mapper. It needs no account.
An AI agent is software that plans steps and takes actions, not just answers questions. It might read a request, look something up, draft a reply and update a record. Governance keeps those actions inside lines you chose on purpose, for every agent, not only the one a careful engineer set up.
Several public sources already cover the principles:
IMDA (Singapore), Model AI Governance Framework for Agentic AI. Version 1.5, published 20 May 2026 and updated 5 June 2026. It's organized in four areas: assess and bound the risks upfront, make humans meaningfully accountable, implement technical controls and processes, and enable end-user responsibility. Read the IMDA framework.
NIST AI Risk Management Framework. Released January 26, 2023, with four core functions: govern, map, measure and manage. See the NIST AI RMF.
ISO/IEC 42001:2023. The international standard for an AI management system, published December 2023. See ISO/IEC 42001.
OWASP Top 10 for Agentic Applications 2026. Released December 2025 by the OWASP GenAI Security Project, it lists the highest-impact security risks for agents, such as agent goal hijack, tool misuse, and identity and privilege abuse. Read the OWASP agentic Top 10.
These tell you what good looks like. They don't tell an operations lead on Tuesday morning which invoice an agent may approve. That's the gap this framework fills.
What are the main risks of AI agents?
The main risks of AI agents are wrong actions, data leakage, prompt injection, runaway cost and unauthorized actions.
Risk | What it looks like | Control that helps most |
|---|---|---|
Wrong action | The agent pays the wrong amount or closes the wrong ticket | Approved process, approval gates on money and irreversible steps |
Data leakage | The agent puts customer or employee data where it doesn't belong | Least-privilege access, data rules per process |
Prompt injection | Text hidden in an email or document steers the agent off task | Treat inputs as untrusted, limit tools, gate external actions |
Runaway cost | The agent loops or calls paid tools far more than expected | Usage caps, monitoring, a stop switch |
Unauthorized action | The agent does something no one gave it permission to do | Authority limits, identity per agent, review of what it did |
OWASP's agentic Top 10 goes deeper on the security side. Use it with your security team; use this framework with the people who own the work.
Why AI agent governance starts with the process
Governance starts with the process because an agent at work does a job, and you can only set limits on a job you've written down.
Think about how you govern a new hire. You don't audit their brain. You give them a documented way of working, a manager, a spending limit, and a list of things to escalate. Agents need the same four things.
The process is the part teams skip, because it usually lives in people's heads. Once it's a map with owners, rules and exceptions, the rest of the framework has something to attach to.
This is also how companies move from older bots to agents. Rule-based automation follows a fixed script; agents choose their steps, so the boundaries must be explicit. Our explainer on agentic process automation and how it differs from RPA covers that shift.
The six parts of a practical AI agent governance framework
The six parts are an owner, an approved process, authority limits, approval gates, version control, and a way to stop and review the agent.
Part | The question it answers | What to write down |
|---|---|---|
1. Owner | Who answers for this agent? | One named person per agent, plus a backup |
2. Approved process | What job does it do, step by step? | A process map with steps, rules, exceptions and the version in use |
3. Authority limits | What may it do on its own? | Amounts, record types and actions it may take without a person |
4. Approval gates | Where must a person decide? | The steps that pause for a named approver, and what happens if nobody answers |
5. Version control | What changed, and who agreed? | Version history, a diff of each change, and sign-off before a new version goes live |
6. Stop and review | How do we stop it, and how often do we check? | A stop switch, the person allowed to use it, and a review date |
1. Give every agent an owner
Each agent gets one accountable owner, usually the person who owns the process rather than whoever wrote the code. If the agent makes a bad call on refunds, the support lead should hear about it first. Name a backup too. Our post on process ownership and RACI shows a simple way to assign this.
2. Make the agent follow an approved process
The agent should follow a documented process, not an improvised plan: a map with the trigger, steps, decision rules and named exception paths. Write rules as rules. "Approve if under $500 and the customer has no open dispute" can be followed; "use judgment on small refunds" can't. Our guide to AI-ready SOPs shows how to rewrite vague steps.
3. Set authority limits
Authority limits answer one question: what can the agent do without asking? Make them concrete, such as issuing credits up to $100 and drafting, but not sending, contract changes. Start below the most junior person who does the job today. Our approval matrix template has a column for exactly this.
4. Put approval gates at the risky steps
An approval gate is a step where the agent stops and a named person approves, edits or rejects. IMDA suggests defining significant checkpoints that need human approval, such as high-stakes or irreversible actions, and checking over time that the oversight still works. A reviewer clicking approve 300 times a day isn't oversight. Our guide to human-in-the-loop workflows covers where gates belong.
5. Version the process and sign off on changes
A change to the process is a change to the agent's behavior. Keep version history, read the diff before a change goes live, and have the owner sign off. When something goes wrong, you can see which version the agent followed. Our post on keeping process documentation up to date covers review cycles, and process governance software covers governing the process library itself.
6. Have a stop switch and a review date
Someone must be able to stop an agent in minutes, without filing a ticket, so name that person. Then put a review on the calendar; monthly works for most teams.
The technical controls layer
The technical controls layer is the IT and security work underneath the six parts: identity and least privilege, logs and traceability, testing before launch, and incident response.
Identity and least privilege. Give each agent its own identity and only the access its process needs. No shared admin accounts.
Logs and traceability. Keep a record of what each agent did, with which inputs, under which process version. In Vevos itself, the process side of this is version history and diff; the action logs come from your systems and the agent platform.
Testing before launch. Run the agent on real past cases, including exceptions and bad inputs, before it touches live work.
Incident response. Decide in advance who gets called, how the agent is stopped, how affected work is fixed, and how the process is updated afterward.
Your security team owns most of this layer. The business owner should still know it exists and who to call.
The AI agent register (copy this)
An AI agent register is a single table that lists every agent with its owner, process version, limits, gates, stop person and review date.
Agent | Owner | Process version | Authority limits | Approval gates | Stop person | Next review |
|---|---|---|---|---|---|---|
Discount request agent | Sales operations lead | Discount approval v3 | Up to 10% on deals under $20,000 | Sales manager from 10% to 20%; finance manager over 20% or over $100,000 | Sales operations lead | First Monday of next month |
Invoice matching agent | AP lead | Invoice approval v5 | Queue matched invoices within 2% of the PO | AP lead on any mismatch | Controller | First Monday of next month |
Ticket triage agent | Support lead | Ticket triage v2 | Tag and route; no customer replies | Support lead before any refund | Support manager | First Monday of next month |
The rows are examples. Keep the register where your ops and risk people already look, and update it whenever a process version changes.
Crosswalk: the six parts vs IMDA, NIST AI RMF and ISO/IEC 42001
Each of the six parts lines up with an IMDA area, a NIST AI RMF function and an ISO/IEC 42001 management system theme.
Framework part | IMDA agentic AI area | NIST AI RMF function | ISO/IEC 42001 theme |
|---|---|---|---|
Owner | Make humans meaningfully accountable | Govern | Leadership and roles |
Approved process | Assess and bound the risks upfront | Map | Operation |
Authority limits | Assess and bound the risks upfront | Manage | Planning and risk treatment |
Approval gates | Make humans meaningfully accountable | Manage | Operation |
Version control | Implement technical controls and processes | Govern | Documented information |
Stop and review | Implement technical controls and processes | Measure | Performance evaluation and improvement |
This crosswalk is my own reading, not an official mapping. It helps when legal or risk asks how your approach lines up with published guidance.
If you sell into the EU, Article 14 of the EU AI Act requires high-risk AI systems to be designed so people can effectively oversee them while they're in use. After the 2026 AI Omnibus amendment, the high-risk rules apply from 2 December 2027 for the Annex III use cases and from 2 August 2028 for AI built into regulated products, per the EU AI Act Service Desk. Our post on the EU AI Act documentation problem covers the inventory side. Ask counsel what applies to you.
Worked example: a discount request agent
Here's the framework applied end to end to one process: a sales rep asks for a discount outside the standard price rules.
Owner: the sales operations lead. Backup: the finance manager.
Approved process (version 3):
Trigger: a rep submits a discount request with the deal size and reason.
The agent checks the request is complete and pulls the customer's past discounts.
Rule: discounts up to 10% on deals under $20,000 are approved by the agent.
Gate: discounts from 10% to 20% go to the sales manager, with the agent's summary.
Gate: discounts over 20%, or any deal over $100,000, go to the finance manager.
Exception: if the customer has an unpaid invoice older than 60 days, the agent stops and routes to finance, whatever the discount.
If an approver doesn't answer within one business day, the request goes to their backup.
The agent sends the decision to the rep and updates the deal note.
Authority limits: up to 10% on deals under $20,000. No changes to prices, contract terms or payment terms.
Version control: version 3 lowered the agent's limit from 15% to 10% after a monthly review. The owner approved the change, and the diff shows the one rule that moved.
Stop: the sales operations lead can stop the agent; requests then go to the sales manager's queue by hand.
In BPMN this is a short map: a start event, a service task for the checks, an exclusive gateway on discount and deal size, two user tasks for the approvers, a timer on each approval, and an end event. The BPMN symbols cheat sheet covers each shape. The same routing appears as rows in our approval matrix template.
How to measure AI agent governance
Measure governance with five numbers: the share of agents with an owner, the override rate, incidents, time to stop, and how current the reviews are.
Metric | How to calculate it | What good looks like |
|---|---|---|
Agents with an owner | Agents with a named owner divided by all agents in the register | Every agent, always |
Override rate | Approvals where a person changed or rejected the agent's recommendation, divided by all approvals | Stable or falling; a sudden jump means the process or data changed |
Incidents | Count of times an agent did something it shouldn't have, per month | Each one reviewed, with the process updated |
Time to stop | Minutes from "stop it" to the agent actually stopped, measured in a drill | Minutes, not hours |
Review currency | Agents reviewed by their due date, divided by all agents | All of them; overdue reviews are the early warning |
Run a stop drill once a quarter. It's the only way to know the time-to-stop number.
How to roll it out by team size
Roll the framework out one process at a time, and scale the paperwork to the size of the company.
Under 50 people. One register row and one page per agent. Review monthly in an existing ops meeting.
50 to 500 people. A shared register, owner sign-off before any agent uses a new process version, and two or three processes in one team to start.
500 and up. A small review group from operations, IT and risk that approves new agents and the processes they follow, with the same six parts and metrics in every team.
At any size, start with a process that's frequent, rule-based and easy to check.
How Vevos fits
Vevos holds the approved process, and the governance controls live on that playbook rather than inside each agent.
Framework part | In Vevos |
|---|---|
Approved process | Describe a process, or upload an SOP, a document or a recording, and get a BPMN 2.0 map plus documentation; refine it in chat |
Authority limits | Set what an agent may do on its own in each playbook |
Approval gates | Mark the steps where an agent stops for a named person |
Version control | Version history and diff, with owner sign-off before a version goes live |
Stop | A stop switch on the playbook |
Outside agents | Unison lets outside AI agents call your approved playbooks over MCP |
After you review a map, Conductor Agents can also build and deploy a working app from it, starting on the Tempo plan. Plans are on the pricing page.
The honest limit: Vevos governs the process an agent follows. Agent identity, data access and security testing still belong to your IT and security teams.
FAQ
Short answers to the questions people ask most about governing AI agents.
How do companies govern automated workflows?
They give each workflow an owner, document the process it follows, set limits on what it can do alone, add approval steps for risky actions, version every change, and review it on a schedule. AI agents need the same, plus a fast way to stop them, because they choose their own steps.
What are the main risks of AI agents?
Wrong actions, data leakage, prompt injection, runaway cost and unauthorized actions. Most of them are reduced by the same few controls: an approved process, tight access, authority limits, approval gates on risky steps and a stop switch.
What frameworks exist for governing AI agents?
IMDA's Model AI Governance Framework for Agentic AI, the NIST AI Risk Management Framework, ISO/IEC 42001 for AI management systems, and the OWASP Top 10 for Agentic Applications for security risks. Most companies borrow from several and turn them into rules for their own processes.
What does an AI agent register include?
One row per agent with its owner, the process version it follows, its authority limits, its approval gates, the person who can stop it, and the next review date. It's the first thing to build, because you can't govern agents you haven't listed.
Who is accountable when an AI agent makes a mistake?
The agent's named owner, usually the process owner, is accountable for fixing the outcome and updating the process. The company stays responsible to customers and regulators. That's why every agent needs an owner before it goes live.
Related reading
These three guides go deeper on the parts of the framework.
Human-in-the-loop workflow design: where approval gates belong
Approval matrix template with thresholds and AI agent limits
The AI automation playbook for mapping and automating your first processes
Start with one process
The fastest way to start is to govern one process this week.
Pick a process an agent could handle. Draw it, name the owner, set the limits, mark the gates, and add a row to the register. Describe it at vevos.ai/free to get a BPMN map and documentation draft in a few minutes. When you're ready to put approved playbooks in front of your agents, see plans and pricing.
Related blog posts
- Approval Matrix Template: Thresholds, Approvers, and Authority Limits for AI Agents — A copyable approval matrix template for finance and operations: who approves what at which amount, with backups and deadlines, step-by-step setup in Excel or Google Sheets, examples by process, and a column for what an AI agent may do on its own.
- AI Automation Playbook: How to Map, Document, and Automate Your First Processes — A practical AI automation playbook for operations teams: eight steps from listing processes to measuring ROI, a scored sample shortlist, a 30/60/90-day rollout, a worked vendor setup example and the mistakes to avoid.
- Human-in-the-Loop Workflow: Where to Put Approval Gates for AI Agents — A practical guide to human-in-the-loop workflows: five real examples, where to put approval gates and where not to, how a gate pauses and resumes an agent, how to draw it in BPMN, and how to measure whether it works.