AI Agent Governance: The Permission Model Nobody Writes Down

Nothing in the setup screen looks like a decision. Permissions arrive as clicks, not as a policy, and that gap is where AI agent governance gets decided. You connect an account, paste a key, approve a scope, and the agent starts working. Three weeks later you are explaining why a post went live on a Tuesday afternoon carrying a claim your legal team has never seen, and the honest answer is that four clicks spread over four weeks added up to one permission nobody granted on purpose. You would have caught that with a new hire, because a new hire asks. An agent does not ask, and the first time you learn where the boundary sits is the first time it crosses one.

Why AI agent governance is not AI governance with a bigger scope

Your AI policy probably answers one question: what is the model allowed to say. That assumes a human reads the answer before anyone else does. An agent removes the assumption. It reads the dashboard, drafts the post, uploads the image, schedules the publish and moves on, and nobody is in the loop unless you put them there.

So the unit of review changes. Output review asks whether this paragraph is accurate. Action review asks whether this agent may publish at all, at what volume, on whose authority. Two different documents, and only one of them usually exists.

The practice data is blunt about which one is failing. A survey the Cloud Security Alliance ran for Zenity, published 16 April 2026, found that 53% of organisations have had AI agents exceed their intended permissions, while only 8% said agents never do. Just 31% have formally adopted a policy for agent usage, against 50% with something partially documented. Zenity, which sells agent security, financed the study.

Teams cross the boundary in production while the paperwork sits in draft. Nobody wrote the permissions down one at a time, for that specific agent.

Of the five pages I read on this query, credal.ai gets closest, and it deserves the credit: three action classes, read-only, low risk write and high risk write, each with a stated rule, plus an explicit refusal to decide where low ends and high begins.

Those three stop at write. Publish a blog post, send a campaign email and spend five thousand dollars all land in the same bucket or the one beside it, though they share nothing except that they change something. A published post is a public claim with your name on it. A sent email reaches somebody who never asked to hear from you. Spent budget does not come back. None of the five names send, spend or publish as its own class, and the gap is narrower than the title suggests because it sits inside that bucket: three actions under one word, with three different owners.

A permission model you can paste into a policy

Five permissions, five review requirements.

Read and write you can grant quickly. Neither leaves the workspace and you can revoke both in a minute. Teams get into trouble when they file send under write: a draft nobody read costs you nothing, and a message that reaches four thousand people has already been read.

Spend has to be reviewed before the fact, because the correction afterwards is an accounting entry. Set the ceiling where you set the access, and fire the alert on the first breach rather than the monthly total.

Publish needs a name on a specific artefact. Not a role, not a channel, not an approval thread from last quarter. One name, one file, one date.

There is no standard to copy yet. NIST's Center for AI Standards and Innovation opened its AI Agent Standards Initiative in February 2026 and is still at the request-for-information stage.

The published-output agent, walked end to end

One agent, one post, five steps.

1. It reads the keyword data, the link inventory and the last four posts. Read, no review. Nothing has left the project.
2. It writes the draft into the project file system. Write, no review. The draft is not public.
3. It produces the meta title, the description and the share image. Still write, still private.
4. It submits the artefact and its sources for sign-off. This is the checkpoint and the only one that matters. The reviewer opens the rendered page, not the markdown, because that is what a reader sees.
5. It publishes and schedules. The agent executes, but the authorisation came from step four and it is recorded against a name.

The checkpoint fails for a boring reason: teams review the draft instead of the artefact. A heading renders two lines longer than in the editor, an image sits above the fold on mobile, a link points at a page that moved.

The undo is the second thing that fails. Unpublishing is not undo. Search engines keep the copy, readers keep the email, and the person who screenshotted it does not care that the URL is gone.

What an audit trail looks like when the owner is a marketer

You will be offered a log, and a log is not evidence. The row a marketing lead can hand to a legal team has four fields:

• what the agent did, in the language of the interface rather than the API,
• what it read to decide,
• who authorised it, by name,
• how to reverse it, or the plain statement that it cannot be reversed.

Four columns, one row per action, stored where the agent cannot edit them. That last condition is the one teams skip, and it decides whether the record survives a vendor dispute.

The rules a published post must satisfy are a separate subject, owned by content governance. This row proves only that somebody authorised the post against those rules.

If you publish into the EU, check which obligation is nearest. Article 50 transparency applies from 2 August 2026, so the live question is whether you mark AI-generated content as AI-generated. Annex III high-risk obligations arrive on 2 December 2027 under the Digital Omnibus amendments, a conformity assessment for a team you have not met.

The three permissions that should never be unattended

Publish to a live URL. The artefact outlives your correction. It is indexed, cached, quoted and forwarded, and every one of those copies is yours.

Send to the customer list and there is no unsend. The inbox is the record, and the person who received it decides what it meant. That list is also where your customer advocacy program lives, so an agent that burns it costs you two things at once.

Spend budget, and the money is gone before you notice. The bidding consequences keep working after you do.

None of the three should run unattended. Not with a better prompt, not with a monitoring dashboard, not with a vendor's assurance that the guardrails hold. The permissions you can leave alone are the ones whose worst outcome is wasted time.

Kill switch, and who is allowed to hold it

Three of the five pages describe a kill switch. None of them assigns it to a named person. accelirate's guide gets the architecture right: the switch has to sit outside the agent rather than inside its own instructions.

Can the person who notices the problem pull it without asking anybody? If the answer involves a ticket, a channel message or a review, you have an escalation path and you have called it a kill switch.

Then decide what off means for a task in flight. Pausing stops the next action. Unwinding reverses the previous ten. Most agents do the first badly, and most incidents need the second.

Write two names beside it: who may pull it, and who must be told within the hour. Neither should be the person who built the agent, who will be the last to believe it is broken.

Where this leaves you

If your team has not settled where it sits on the AI maturity model, expect the table to feel like a jump. It is smaller than the one you make the first time an agent publishes something you have to explain.

The table is the whole deliverable. Print it, fill the last column with names instead of roles, and keep it where the agent's access gets granted. When AI agent governance is finished it looks like this: five rows, an owner for each, and no permission that arrived as a side effect of a setup screen.