Example AI Agent Governance Policy, Published in Full

Ask ten companies running AI agents against real project work for their actual governance policy, and nine will hand over a slide of principles that has never been tested against an incident. Here is ours, unabridged, because a policy nobody has tried to break is not a policy yet. It's a draft with good intentions.

The direct answer: this is an example AI agent governance policy in full, not a template: four permission tiers scoped by what an agent actually does today, a destructive-action list enforced as a technical block rather than a written expectation, a quarterly review cadence that moves tiers up or down based on real incident data, and a named owner for every agent connection currently running. The clauses that matter are the ones a template always leaves generic: exactly what's on the destructive-action list, and exactly who signs off when a tier changes.

The Four Permission Tiers in This Example AI Agent Governance Policy

Every agent connection in this policy is assigned one of four tiers before it runs its first task, and the tier determines what gets reviewed and when, not just what the agent is nominally allowed to attempt.

1. Tier 1, draft-and-wait. The agent proposes a change and stops. Nothing it produces becomes real until a person applies it. This is the default for any agent class on its first thirty days of real work.
2. Tier 2, apply-with-pre-review. The agent's output goes live only after a person reviews the specific action, not a sample of past actions. Used for anything touching a live schedule, budget field, or external-facing document.
3. Tier 3, apply-with-post-review. The agent's actions commit immediately and get sampled for review afterward. Reserved for agent classes with a clean acceptance record over at least two full quarters at Tier 2.
4. Tier 4, apply-unattended. Reserved for narrow, mechanical, fully checkable actions, closing a task once a linked deliverable is verified complete, for example, where the check itself is deterministic rather than a judgment call.

The five levels of AI agent autonomy is the framework these four tiers map onto; this policy is what that framework looks like once it's written down as an enforceable document instead of a conceptual scale. No agent class starts above Tier 1, and moving up requires the evidence in the section below, not a manager's confidence that it's probably fine now.

The Destructive-Action List, in Full

This is the clause most policies leave vague, so here it is exactly as written. No agent connection covered by this policy, at any tier, may do the following without an explicit human ratification step immediately before the action commits:

Action	Why it's on the list
Permanent delete of a project, task, or document (past the recycle-bin recovery window)	Irreversible once the retention window closes
Any external send: email, webhook to a third party, published app content	Cannot be recalled once it leaves the system
Budget or contract commitment above a per-tier dollar threshold	Financial exposure that outlives the task that created it
Changing another user's permission scope or role	A privilege change is how a small mistake becomes a large one
Bulk action above 50 records in a single call	Caps blast radius regardless of how correctly the identity was scoped

The list is enforced at the permission layer the agent's credentials pass through, not inside the agent's instructions. Guardrails versus permissions covers why that distinction is the whole policy: a rule that lives only in a prompt holds only as long as nothing in the agent's context argues persuasively against it, and a task comment worded like a routine, authorized request looks the same to a model as one that actually is.

The diagram below shows how a request moves through this policy before anything on the destructive-action list can commit.

Audit Retention and Credential Handling

Every agent action is logged with the trigger that started it, the data it read or changed, and the connection that authorized it, retained for twelve months and exportable on request. Credentials follow the job, not the person who requested them: a connection is scoped to the specific task class it runs today, re-scoped the moment that job changes, and revoked immediately when the agent class it belongs to is retired. Who is accountable when an agent is wrong covers what happens when this clause is skipped: accountability doesn't disappear, it just lands on whoever approved skipping it, later, with less evidence to work from.

What Changed After the One Time This Policy Was Tested

The policy's review clause isn't theoretical. A connection scoped to a broader role than the task in front of it needed was caught in a routine audit pass, not by a real-time alert, the same incident what broke when agents joined our team describes in full. The response the policy required: revoke that connection immediately, without touching any other agent's access, then narrow every other connection's scope to the job it does today rather than the role it was issued under. That change is now clause language, not a lesson kept in someone's head.

Publishing the real document, near-misses included, is worth more to another PMO writing its own policy than a clean template would be. The rest of the Onplana blog's AI and Innovation coverage covers the adjacent decisions this policy assumes are already made, including where PMO policy for autonomous agents should draw its lines before the first incident, and the full security posture this policy's audit and credential clauses sit inside.