AI agent governance: a practical guide for 2026

An AI agent is software that takes a goal, decides on steps and calls tools to carry them out. Some of those tools only read: they search, summarise or look up a record. Others write: they post a journal entry, change a price, refund an order or update a customer's address. AI agent governance is the set of controls that decides what an agent may change, who must approve it and what evidence is kept afterwards.

It overlaps with AI model governance but is not the same thing. Model governance asks whether a model is fit for purpose: how it was trained, how it performs, whether it is biased, who signed off its release. Agent governance asks a narrower, more operational question each time the agent acts: should this specific change happen, now, under these rules, and can we prove afterwards what happened? A well-governed model can still be wired into an agent that has too much access.

The distinction matters because most governance programmes were built for models that produce text or scores for a person to read. An agent removes that person from the loop unless you put them back deliberately. This guide is about putting the controls where agents act.

A wrong answer from a chatbot is a quality problem: someone reads it, doubts it and moves on. A wrong write from an agent is an operational problem: the ledger is now wrong, the customer has been refunded twice, the stock count no longer matches the shelf. The cost of a mistake moves from embarrassment to correction, reconciliation and, sometimes, a regulator's question.

The OWASP Top 10 for LLM Applications 2025 names this risk “Excessive Agency” (LLM06) and traces it to three root causes: too much functionality, too many permissions and too much autonomy. All three are properties of the agent's wiring, not of the model. That is good news, because wiring is something you control.

A practical rule follows. Sort every tool an agent can call into reads and writes, then split the writes into routine changes within limits and consequential changes. Reads need access control. Routine writes need limits and a record. Consequential writes need a decision, by rules and, above a threshold, by a named person.

Across frameworks and vendors, the same five controls keep appearing. You can implement them with any stack.

1. Inventory

List every agent in use, who owns it, which systems it can reach and which tools it can call. Include agents built into SaaS products you already pay for. Most organisations find more agents than they expected, many with write access granted for a pilot and never removed.

2. Identity

Give each agent its own identity, separate from the person who runs it, and record both on every action: the agent that proposed the change and the person or process it acted for. Shared service accounts make it impossible to say afterwards which agent did what.

3. Rules

Write down what each agent may change, within what limits and under which conditions, as versioned rules a machine can check. A policy document that says “agents must not make material changes without approval” is a statement of intent; a rule that says “journal entries above ₹50,000 to accounts in group 4 need an approver” can be tested on every write.

4. Human approval

Above a risk threshold, a named person who is not the requester decides, with enough context to say no. Below the threshold, the agent works within limits. The threshold is the design decision; asking for approval on everything produces rubber-stamping.

5. Evidence

Keep a record of every action the agent proposed, which rules were checked, who approved it and what happened, including the actions that were refused. Link the records so a later edit is detectable. Evidence is what turns a governance programme into something an auditor can test.

Before designing anything new, look for the patterns that cause most agent incidents. Each one is cheap to find and usually cheap to fix.

• Shared service accounts. Several agents, or an agent and a batch job, write with the same credential. Nobody can say afterwards which one made a change.
• Pilot permissions that never expired. Write access granted for a proof of concept is still live months later, often broader than the pilot needed.
• Prompt-only controls. The only thing standing between the agent and a payment is an instruction in its system prompt. Instructions steer; they do not bind.
• Approvals by the requester. The person who asked the agent to act is the one who clicks approve, so the approval adds no independent check.
• Logs nobody can verify. Records live only in a vendor dashboard or in a database the agent's operators can edit, so they cannot serve as evidence.

If you find any of these, fix them before adding new agents.

There are three places to put controls on an agent, and they are not interchangeable.

Use all three, but rely on the third for anything consequential. The strongest version is a single path that every change must take, where the agent never holds the write credential itself: it proposes, and a separate component that does hold the credential commits only what the rules allow. If an agent can reach the system of record by another route, the path is advisory.

Analysts have started naming this market. Gartner uses “AI TRiSM” (AI trust, risk and security management) for the broad discipline and, in a June 2025 press release, described “guardian agents” as technologies that oversee other agents and can redirect or block their actions.

For a buyer, the labels matter less than three questions you can ask any product in the category:

• Does it see the action or only the conversation? Monitoring prompts and outputs is useful, but only a control that sees the proposed change can stop it.
• Is its decision deterministic where it needs to be? Using one model to supervise another is useful for triage. For an allow or a refusal on a consequential write, you want rules you can read and test, plus a named person above the threshold.
• What evidence does it leave, and can you check it without the vendor? A dashboard is not evidence. Records you can export, verify and hand to an auditor are.

Human-in-the-loop is the control most often promised and least often designed. It fails in predictable ways: approvers are asked about everything, so they approve everything; the request is a wall of model output rather than a clear diff; the person approving is the person who asked.

It works when approval is reserved for changes above a threshold set by value, reversibility and blast radius; when the approver sees exactly what will change and which rule caused the hold; when the approver is a named person other than the requester; and when the system stops and asks a person whenever something is missing, rather than proceeding. Our guide to human-in-the-loop for AI agents covers thresholds, maker-checker and approval fatigue in detail.

Auditors test whether controls operate, not whether they exist on paper. For agents, that means a record for each action that answers six questions: who or what asked, what was proposed, which rules ran and in which version, who approved or refused, what changed, and how this record links to the one before it so an edit would show.

Two details separate useful trails from logs. First, record the policy decision, not only the tool call: a log that shows an API was called does not show why it was allowed. Second, record refusals, because a control that never refuses anything cannot be shown to work. The AI agent audit trail guide goes through the fields one by one.

No framework regulates “AI agents” as a separate category yet. They regulate AI systems by risk or set management-system expectations, and agents inherit those duties. The table maps the five controls to the main sources, as of October 2026.

For the detail, see EU AI Act Articles 12 and 14 for AI agents, ISO 42001 audit evidence for AI agents and NIST AI RMF for AI agents.

You do not need a programme office to start: one owner, one process and four weeks.

1. Week 1: inventory. List every agent, its owner, its tools and the credentials it holds. Remove write access nobody can justify.
2. Week 2: classify actions. For one business process, sort each tool call into read, routine write and consequential write. Agree the threshold with the process owner.
3. Week 3: one write path. Route the consequential writes through a single checkpoint that applies versioned rules and holds changes above the threshold for a named approver. Take the write credential away from the agent.
4. Week 4: evidence. Confirm every action, allowed or refused, leaves a linked record. Ask someone outside the team to check a week of records without your help.

At day 30 you should be able to show three things to someone outside the team: a current list of agents and their access, a written threshold for one process, and a week of linked records, including at least one refusal, that they can check on their own. That is real evidence, and it scales one process at a time.

Two free tools help: the 12-question AI agent readiness assessment, and a set of RFP questions for AI agents that write for when you buy rather than build.

elan1 is a governed write path for AI agents. Agents and our own products propose changes as write intents; only elan1 Govern can allow one. Every write climbs the Right Path: identity, nine pre-gates, versioned rules, a blast-radius guardrail and an autonomy check, then a named approver where your rules ask. The outcome, allowed or refused, is written to a 16-field proof record, SHA-256 hash-chained so that a change to an earlier record is evident.

In Mode A, where the credential is held by elan1 and the agent never has it, the rules are enforced. Over MCP or HTTP without the credential (Mode B), every intent is still evaluated and recorded, but enforcement stays with your system. Records are tamper-evident at L1 Guarded; from L2 Attested they are signed, and an auditor can check them offline. A refusal costs 40% of one governed action. See AI agent governance with human approval for the detail.