The AI Agent Policy Template Your PMO Actually Needs
An AI agent policy template needs eight enforceable clauses, not a values statement: permitted work, decision rights, audit retention, destructive-action list.
Ask a PMO director for their written AI agent policy and most produce one of two things: nothing, or a page of principles that would not survive contact with an actual incident. "Agents operate under human oversight" reads fine in a slide deck. It answers nothing when an auditor asks which specific operations an agent can commit to project state without a person clicking approve first.
The direct answer: a working ai agent policy template has eight enforceable clauses, not a values statement: permitted work, decision rights by autonomy level, review requirements, escalation, audit retention, credential handling, a destructive-action list, and a review cadence. Each clause has to name specific operations and a specific owner, because a policy that cannot be checked against a real incident is not a policy yet, it is a draft.
A PMO agent policy needs eight clauses: what work the agent is permitted to do, how decision rights change as autonomy widens, what gets reviewed before it ships, where escalation goes, how long audit records are kept, how credentials are issued and revoked, an explicit list of actions the agent may never take, and a fixed cadence for revisiting all seven of the above. Skip the destructive-action list or the review cadence and the other six clauses erode within two quarters.
Why Most Agent Policies Fail Before an Incident Happens
The failure pattern is consistent. A PMO writes a policy during a pilot, gets three sentences of consensus in a meeting, and files it. Six months later an agent does something nobody explicitly authorized, and the room discovers the policy never named who owns that decision or what the agent's credentials actually allowed. AI governance for PMOs covers the act, suggest, and stay-out zones that should sort every operation before this document gets written; this post is the document itself, the thing a PMO is handed and has no template for.
A policy built from principles instead of a checklist fails the same way every time: it describes intent, not a control. The eight clauses below are the difference between a document a PMO can point to during an audit and one it has to apologize for, and they map onto the same structure the NIST AI Risk Management Framework uses for govern, map, measure, and manage: name the boundary, know where AI touches real work, log what happened, and revisit on a schedule.
The Eight Clauses an AI Agent Policy Template Needs
| Clause | What it has to answer | What happens if it's missing |
|---|---|---|
| Permitted work | Which task types and artifacts an agent may touch at all | Scope creep: an agent asked to draft a status report also edits budget fields |
| Decision rights by autonomy level | What a level-1 agent can do that a level-3 agent cannot | A junior automation gets treated like a trusted one, or vice versa |
| Review requirements | What gets checked before an action becomes final | Errors ship silently because nothing was ever gated |
| Escalation | Where a rejected or ambiguous action goes next | The same failure repeats because nobody owns fixing the pattern |
| Audit retention | How long action logs are kept and who can query them | "Prove it" has no answer six months after the fact |
| Credential handling | How agent access is issued, scoped, and revoked | A deprecated agent keeps write access nobody remembered to pull |
| Destructive-action list | What the agent may never do, no exceptions | "Just this once" access quietly becomes the new normal |
| Review cadence | How often the whole policy gets revisited | A policy calibrated for the pilot governs a portfolio it was never tested against |
Decision rights and the destructive-action list are the two clauses worth writing first, because every other clause depends on them. The five levels of AI agent autonomy is the framework decision rights should map onto: a level-1 agent that only drafts and waits needs a lighter review clause than a level-4 agent that commits changes on its own.
Decision Rights Have to Change With Autonomy Level
A policy that grants the same review requirement to every agent, regardless of how much it is trusted to do unattended, is either too loose for the agents that need tight review or too heavy for the ones that have earned a lighter touch. Decision rights should scale with autonomy level explicitly, not implicitly.
- Name the autonomy level for each agent or agent class before it runs its first task, using a shared scale rather than an ad hoc description.
- Write the review requirement per level, not per agent. A level-2 agent's proposals get reviewed before they apply; a level-4 agent's actions get reviewed after, on a sample basis.
- Require a named approver to move an agent up a level, with the evidence (acceptance rate, near-miss count) that justified the change attached to the record.
- Allow the same approver to move it back down after a near-miss, without that being treated as a punitive action against the team that deployed the agent.
The diagram below shows how the eight clauses fit together as a single policy document, not eight disconnected rules.
The Destructive-Action List Nobody Wants to Write
Every other clause is easier to draft than this one, which is exactly why PMOs skip it or leave it vague. The destructive-action list names, specifically, what an agent may never do regardless of who asks or how the request is worded: irreversible deletes, external sends without a hold state, budget or contract commitments, anything touching a performance record. Who is accountable when an agent is wrong covers what happens when this list is missing: the answer defaults to "the AI did it," which satisfies nobody.
The list only works if it is enforced at the credential layer, the same principle covered in defining AI agent scope: a permission the agent's access token cannot technically exercise cannot be talked around by a persuasive comment or an urgent-sounding request. A destructive-action list that lives only in a policy document, unread by the system enforcing access, is a sentence, not a control.
Setting a Review Cadence That Actually Holds
A policy set once at rollout and never revisited is calibrated for a pilot, not a portfolio. Set the cadence explicitly: quarterly for the full document, and immediately after any near-miss regardless of the calendar. Each review should move at least one clause based on real data, tightening the destructive-action list where an agent came close to a boundary, or widening decision rights where a level has run clean for two quarters straight. A cadence that never changes anything is not evidence the policy is perfect; it usually means nobody is looking.
Onplana's own governance model, available at the Enterprise tier, gives a PMO the audit trail and the permission scoping this policy assumes exists: every agent action logged with the trigger, the data it read, and the actor who authorized it, exportable for the review this policy requires. The PMO Maturity Assessment is a reasonable starting point for finding out which of these eight clauses your PMO already has covered before an agent's first real task, rather than after its first real incident. The rest of the Onplana blog covers the adjacent decisions this policy assumes are already made: autonomy levels, accountability, and where an agent's scope should stop.
Run the free PMO Maturity Assessment Get a structured read on your PMO's governance readiness in about ten minutes, before an agent policy gets tested by an actual incident. No signup required. → Open the PMO Maturity Assessment
Frequently asked questions
What should an AI agent policy template for a PMO include?
Eight clauses at minimum: permitted work, decision rights by autonomy level, review requirements, escalation, audit retention, credential handling, a destructive-action list, and a review cadence. A policy missing any one of these has a gap someone will find during an actual incident, not before.
How is an agent policy different from a general AI ethics policy?
An ethics policy states values like fairness and transparency. An agent policy names specific operations, who can approve them, and what an agent's credentials can technically reach. Only the second one can be audited, because 'be responsible' has no pass or fail.
Can an agent bypass the policy if someone asks it to in a task comment?
Yes, if the policy lives only in the agent's instructions rather than in what its credentials can technically reach. A comment that reads like an authorized request looks the same to the agent as one that actually is, which is why the destructive-action list has to be enforced at the permission layer, not the prompt layer.
Who is accountable if the policy itself turns out to be wrong?
Whoever signed the policy and set the zone assignments, the same person accountable for a human delegation policy that turns out to have a gap. A written policy does not remove accountability, it makes clear in advance whose judgment is being tested and gives that person something concrete to revise.
Does a written policy actually stop an agent from doing something irreversible?
Only if the destructive-action list is enforced as a hard technical block, not a documented expectation. A policy that says 'agents should not delete production data' without a permission scope that makes deletion technically impossible is a sentence, not a control.
How often does an agent policy need to be reviewed?
Quarterly at minimum, and immediately after any near-miss. Autonomy levels widen as trust is earned and narrow after an incident, so a policy set once at rollout and never revisited is already stale by the time anyone reads it again.
Ready to make the switch?
Start your free Onplana account and import your existing projects in minutes.