Skip to content
AI Compliance Tool
Check my AI risk
PlatformSolutionsPricingRegulationsFree toolsGuides Partners Sign in

AI Agent Governance Explained

What makes AI agents different from chatbots, and how to govern them: permission matrix, autonomy levels, approval gates, logging, override and escalation, with a CRM incident example.

By AI Compliance Tool editorial team · Published 2026-10-14 · Reviewed 2026-10-14 · Reviewer: Pending independent review · 10 min read

Key takeaways

  • A chatbot produces text for a person to act on; an agent acts. Governance for agents is about permissions and reversibility, not about wording.
  • Write a permission matrix per agent: which systems it can read, write, send to and spend from, and which of those require approval.
  • Assign one of four autonomy levels (Suggest, Act with approval, Act and report, Fully autonomous) per action type, not per agent.
  • Every action an agent takes should be logged with who authorised the agent, what it did, to whom, and how to reverse it.
  • Build the kill switch before the agent goes live, and make sure more than one person can use it.

For two years the question was “what can staff paste into a chatbot?”. The question now is “what can the software do on its own?”. AI agents, systems that read your email, update your CRM, send messages, book appointments and trigger payments, change the governance problem from controlling words to controlling actions.

This guide explains the difference, gives you the four artefacts every agent needs (permission matrix, autonomy levels, approval gates, logging) and walks through an incident so you can see where each control earns its place.

Chatbots vs agents

Chatbot or assistantAgent
OutputText, images, suggestionsActions in other systems
Human in the loopA person reads and decidesOptional, by design choice
Failure modeWrong information a person might repeatWrong action already taken
ReversibilityDelete the draftDepends: an email cannot be unsent; a payment may be reversible with effort
Governance focusData rules, verification, disclosurePermissions, approval gates, logging, override

The test is simple: can the system change something outside the conversation without a person acting in between? If yes, it is an agent for governance purposes, however the vendor describes it. A “smart inbox” that archives and replies on its own is an agent. A CRM “assistant” with a “auto-update lead status” toggle is an agent when the toggle is on.

The permission matrix

For each agent, build a table of what it can touch. Columns are the four verbs; rows are the systems.

SystemReadWriteSendSpend
CRM contactsYesYes, with approvaln/an/a
CRM deal stageYesYes, report onlyn/an/a
Email (shared sales inbox)YesDraft onlyWith approvaln/a
CalendarYesYes, report onlyInvites with approvaln/a
Payment or invoicingNoNoNoNo
Public website or socialNoNoNon/a

Three rules for the matrix:

  1. Least privilege. Grant the minimum that the agent’s purpose needs. If the purpose is “qualify inbound leads”, it does not need to send invoices.
  2. Separate read from act. Many agents need to read widely and act narrowly. Keep those as distinct permissions, because the data an agent reads is also personal information you are responsible for under PIPEDA, Alberta and BC PIPA, Quebec Law 25 and GDPR.
  3. Record it in the inventory. The agent-permissions field in your AI inventory is the matrix in summary form, and it is what changes when the vendor adds a feature.

Four autonomy levels

Assign a level per action type, not per agent. A single agent can be Act and report for internal note-taking and Suggest for anything customer-facing.

LevelWhat happensUse when
SuggestThe agent proposes; a person does the actionNew agents; customer-facing content; anything irreversible
Act with approvalThe agent prepares the action and waits; a person approves each oneSending to customers, changing records that drive other processes, scheduling with external people
Act and reportThe agent acts and a person reviews a log afterwardsReversible internal actions with low stakes: tagging, drafting notes, updating internal fields
Fully autonomousThe agent acts; review is by exception and samplingOnly for reversible, internal, non-financial actions with a proven record and a working override

Promotion between levels is a decision to record: who approved, on what evidence (how many logged actions reviewed, how many errors), and when it will be reviewed.

Approval gates

An approval gate is a defined point where the agent must stop and get a human decision. Design them around consequences, not around the agent’s confidence.

Mandatory gates for most small businesses:

  • Any external communication (email, SMS, social post) until the action type has earned a higher level.
  • Any change to a record that drives a decision about a person: lead scores that determine follow-up, applicant status, credit or eligibility flags, tenant or patient records. This is where automated-decision rules bite: Quebec s. 12.1 for decisions based exclusively on automated processing, GDPR Art. 22, Colorado SB 26-189 notice and human-review rights from 1 January 2027, and EU Annex III high-risk status for employment uses from 2 December 2027.
  • Any spend, including purchases, refunds, credits and subscription changes.
  • Any deletion or bulk update (more than a handful of records in one run).
  • Any new recipient or new system the agent has not acted on before.

Make the gate a real interface: the approver sees exactly what will be sent or changed, to whom, and can edit or reject. A gate that shows “Approve 47 actions?” is not a gate.

Logging

Each agent action should produce a log entry with:

  • Timestamp and the agent’s identity (so human and agent actions are distinguishable in your systems).
  • Who authorised the agent and at what autonomy level for that action type.
  • The input or trigger (the email it read, the record it saw).
  • The action taken, the target (record, recipient) and the content.
  • The approval, if any, and who gave it.
  • How to reverse it, or a note that it is irreversible.

Keep logs where the agent cannot edit them. Retention: at least six months is a sensible floor (it is what EU high-risk deployers will be required to keep from 2 December 2027), longer where other record rules apply (Colorado SB 26-189 requires three-year compliance records from 1 January 2027). Logs that contain personal information are themselves personal information; apply your retention and access rules.

Override and escalation

  • Kill switch. A documented way to pause the agent entirely, usable by at least two named people, tested before go-live and quarterly after. In your inventory, this is the move to Suspended.
  • Per-action reversal. A written procedure for undoing each action type: recall or correct an email, restore a record from history, cancel a booking.
  • Escalation path. Who is told, within what time, when an agent does something unexpected: the tool owner, then the governance owner, then whoever is responsible for affected customers or staff. If personal information was sent to the wrong place, your privacy breach procedure starts (Alberta PIPA s. 34.1 notification where a real risk of significant harm exists; Quebec confidentiality-incident rules; GDPR breach rules in the EU).
  • Disclosure. If the agent interacts with people, they should know it is an AI system (EU AI Act Art. 50(1) from 2 August 2026; Utah 13-75-103 when asked, with a safe harbour for upfront disclosure). If it affects a decision about them, the relevant notice applies.

Worked example: the Tidewell CRM agent

Tidewell Fitness, a 30-person chain of three gyms in British Columbia, deployed a CRM agent to follow up on trial memberships. The permission matrix allowed it to read contacts and visit history, update lead stage, and send email. Autonomy was set to Act and report for all three, because the vendor’s demo was convincing and the sales lead was busy.

On a Tuesday the vendor pushed a model update. The agent began interpreting “no visit in 14 days” as a cancellation signal and sent 212 “we’re sorry to see you go” emails, including to 38 people who had visited on Monday but whose check-ins had not yet synced. Nine replies came back from people who had previously told staff about medical reasons for a pause; three were upset that the email referenced “your recent inactivity”. Two of the 212 recipients were former members who had asked to be removed from marketing.

What the controls would have done:

  • Approval gate on external communication would have stopped all 212 emails at a human screen, where the odd phrasing and the volume would have been obvious.
  • Model-change notice from the vendor (a due-diligence question) would have triggered a return to Suggest for one week.
  • Logging did exist, so Tidewell could identify every recipient within an hour, confirm no health details were included in the emails, and send a correction. Without it they would have been reconstructing the list from the sent folder.
  • Separate read from send permissions would not have prevented this incident but limited its scope: the agent could not reach payment or membership records.
  • Privacy review of recipients: the two unsubscribed former members were a consent and limiting-use issue under BC PIPA; the fix was a suppression check as a gate condition.

Tidewell moved email sending to Act with approval, added a daily cap of 25 sends per run, added a suppression-list check, and recorded the incident, the fix and the autonomy-level change in the inventory entry. Three months later, with 60 days of clean logs reviewed, sending was promoted back to Act and report for one template only.

Where frameworks help

The NIST AI RMF (voluntary; released January 2023) and its generative AI profile, NIST AI 600-1 (July 2024), list agentic risks such as value-chain dependence and information integrity under Map, Measure and Manage, and ISO/IEC 42001:2023 Annex A expects lifecycle and third-party controls. None of these certifies your agent or makes it lawful. They give you a structure; the permission matrix, autonomy levels, gates and logs are the substance.

Sources

Frequently asked

Is an email assistant that drafts replies an agent?
Not if a person reads and clicks send. It becomes an agent the moment it can send without that click. The test is whether the system can change the world (send, post, update, pay) without a human action in between.
Which laws apply specifically to AI agents?
None we track use the word 'agent'. The relevant rules are the ones about what the agent does: privacy law for the personal data it reads and writes, transparency rules where it interacts with people (EU AI Act Art. 50, Utah 13-75-103), automated-decision rules where its actions affect people (Quebec s. 12.1, GDPR Art. 22, Colorado SB 26-189 from 2027), and consumer-protection law for anything it says to customers.
What autonomy level should we start with?
Suggest or Act with approval for anything that touches customers, money or records. Move individual action types up one level only after a defined period of logged, reviewed operation with no incidents.
How long should agent logs be kept?
Long enough to investigate, reverse and explain. EU high-risk deployers will be required to keep automatically generated logs for at least six months from 2 December 2027; Colorado SB 26-189 requires three-year compliance records from 1 January 2027. Six months is a reasonable floor for everyone; align to your record-retention policy.

This guide is general information, not legal advice. Laws and dates are drawn from our verified regulatory dataset and link to official sources; check them for changes after the review date.