Key takeaways
- A usable policy names its owner, scope and decision rights. Principles without an accountable role cannot settle a production exception.
- Separate the written rule from the enforcement evidence. For every policy statement, name the system setting, approval record or review report that proves it is operating.
- Classify agents by the actions and data they can reach, then attach stronger approval, access and review requirements as consequence rises.
- Require an inventory record before production, a change review when tools or permissions move, and a retirement check that revokes credentials and preserves required records.
- Test the policy against one awkward case before approval. If it cannot answer who decides, what stops and what gets recorded, rewrite that section.
An AI agent governance policy should answer who may put an agent into production, which actions and data require stronger controls, how access and human approvals work, what evidence each run leaves, and what triggers review or retirement. The editable template on this page turns those answers into seven sections with bracketed decisions. It is a starting document, not a substitute for a risk assessment, security architecture or legal review.
What the template contains
The template starts from the process-level controls in the AI agent governance framework, then adds the organizational rules needed to apply them consistently. NIST's AI Risk Management Framework makes governance a cross-cutting function and asks organizations to establish policies, processes, roles and responsibilities. The practical consequence is simple: each rule needs an owner and a piece of evidence, not just careful wording.
| Section | Decision to make | Evidence that proves it |
|---|---|---|
| 1. Purpose and scope | Which agents, teams, environments and third parties are covered? | Approved scope, definitions and policy owner |
| 2. Inventory and ownership | What record must exist before production, and who is accountable? | Current inventory entry with business and technical owners |
| 3. Risk and approval | How do actions move into stronger control tiers? | Risk decision, autonomy boundary and named approvers |
| 4. Identity and access | Which identity, resources and actions may each agent use? | Permission envelope and authorization logs |
| 5. Records and monitoring | Which events are retained, for how long and who reviews them? | Run record, review report and retention setting |
| 6. Incidents and exceptions | Who can stop an agent, grant an exception or require manual fallback? | Incident, exception or emergency-stop record |
| 7. Change and retirement | Which changes require reapproval, and how is access removed? | Change decision, revoked credentials and archive record |
Policy
Editable AI agent governance policy template
A Markdown policy with bracketed choices, an approval table, evidence register and revision history. No signup.
Preview the fileHide preview
# AI agent governance policy template Version: [VERSION] Policy owner: [ROLE OR NAMED OWNER] Approved by: [DECISION AUTHORITY] Effective date: [YYYY-MM-DD] Next review: [YYYY-MM-DD] > Replace every bracketed field. Delete guidance that does not apply. This > operational template is not legal advice and does not assign regulatory risk. ## 1. Purpose and scope This policy defines how [ORGANIZATION] inventories, authorizes, operates, monitors, changes and retires AI agents that can access business data or tools. It applies to: - [BUSINESS UNITS AND TEAMS] - [PRODUCTION, TEST AND OTHER ENVIRONMENTS] - [EMPLOYEES, CONTRACTORS AND SERVICE PROVIDERS] - [INCLUDED AGENT TYPES] For this policy, an AI agent is [ORGANIZATION'S TESTABLE DEFINITION]. Systems that only generate text without tool or data access are [IN SCOPE / OUT OF SCOPE / COVERED BY ANOTHER POLICY]. Policy questions go to [CONTACT]. Suspected incidents go to [INCIDENT CHANNEL]. ## 2. Inventory and ownership An agent must not enter production until it has one current inventory record containing: - business purpose and affected process - lifecycle state and environment - named business owner and technical owner - non-human identity or identities - models, procedures and policy versions - connected tools and allowed actions - data categories and external audiences - risk tier and maximum autonomous action - required approvals and escalation owner - last review, next review and exception expiry The business owner is accountable for [PURPOSE, PROCEDURE AND OUTCOMES]. The technical owner is accountable for [DEPLOYMENT, IDENTITY, LOGGING AND RECOVERY]. [ROLE] reassigns or suspends agents whose owner leaves or no longer has the required authority. ## 3. Risk tier and human approval [ORGANIZATION] classifies deployed uses by consequence, reversibility, affected people, data sensitivity and maximum action. A model name does not determine the tier. | Tier | Maximum action | Required control | Decision authority | | --- | --- | --- | --- | | [0] | [READ OR INTERNAL DRAFT] | [LOGGING AND SAMPLED REVIEW] | [ROLE] | | [1] | [REVERSIBLE INTERNAL UPDATE] | [SUPERVISED RELEASE / ROLLBACK] | [ROLE] | | [2] | [EXTERNAL OR CONSEQUENTIAL ACTION] | [BLOCKING APPROVAL] | [ROLE] | | [3] | [PAYMENT, RIGHTS OR OTHER MATERIAL ACTION] | [PERMANENT / DUAL APPROVAL] | [ROLE] | Every action above [AUTONOMY LINE] stays pending until an eligible person reviews the exact proposal and approves, edits or rejects it. An approval expires after [INTERVAL] and becomes invalid when the proposed payload changes. ## 4. Identity and access Each production agent uses a distinguishable, managed non-human identity. It must not borrow a person's session or use a shared login. The approved permission envelope names: 1. agent identity and delegated principal 2. permitted systems and records 3. permitted read, propose, create, update, send and delete actions 4. permitted fields or data classes 5. required run, purpose, network and approval context 6. issue, expiry and revocation conditions Access is least-privilege, time-bound where supported and reviewed every [INTERVAL]. Allowed, denied and approval-required authorization decisions are logged with the agent identity and policy version. ## 5. Run records and monitoring Every production run receives a unique run ID. The audit trail records: - initiator, agent identity and delegated principal - procedure, model and policy versions - input and source references - proposed tool actions and normalized payload references - authorization decisions and matched rules - approval requests, exact proposals, reviewer decisions and edits - executed actions, provider receipts, errors, retries and rollback - final status and exception owner Records are retained for [INTERVAL] in [SYSTEM]. Access is limited to [ROLES]. [ROLE] reviews [POLICY DENIALS, OVERRIDES, FAILURES, ACCESS CHANGES AND OTHER EXCEPTIONS] every [INTERVAL]. Sensitive payloads remain in [AUTHORITATIVE RESTRICTED SYSTEM]; the audit trail stores [REFERENCE OR HASH]. Audit-record access, export and deletion are logged. ## 6. Incidents and exceptions [ROLE OR ROLES] may immediately pause an agent or process when [STOP CONDITIONS]. Pausing prevents new runs, preserves queued work where safe and revokes [CREDENTIALS OR SCHEDULES]. The manual fallback is [OWNER AND PROCEDURE]. Incident records include affected runs, observed impact, containment, recovery, notification, root cause and control changes. Exceptions must name: - the exact policy clause - business reason and affected process - compensating control - accountable owner - approval authority - start and expiry - evidence reviewed at renewal Expired exceptions deny or suspend the affected action; they do not renew silently. ## 7. Change and retirement The following are material changes and require review before production: - a new tool, action type or data category - a new external audience - wider record or field scope - movement of the autonomy line - changed business purpose or owner - changed procedure that affects approvals, evidence or recovery - [ORGANIZATION-SPECIFIC EVENTS] Retirement disables schedules and entry points, revokes credentials, settles or transfers queued work, preserves records for the required period and changes the inventory state to `retired`. ## Policy-to-evidence register | Policy clause | Enforcement mechanism | Evidence location | Control owner | | --- | --- | --- | --- | | Unique agent identity | [DEPLOYMENT OR IAM CONTROL] | [LINK] | [ROLE] | | Approval above autonomy line | [POLICY OR WORKFLOW CONTROL] | [LINK] | [ROLE] | | Material change review | [DEPLOYMENT OR CHANGE CONTROL] | [LINK] | [ROLE] | | Run audit trail | [EVENT OR LOGGING SYSTEM] | [LINK] | [ROLE] | | Timely retirement | [LIFECYCLE CONTROL] | [LINK] | [ROLE] | ## Awkward-case acceptance test Before approval, use this policy to decide: 1. An existing read-only agent requests a new state-changing tool. 2. A reviewer rejects an action and gives no alternative. 3. An approval expires while the process is paused. 4. An exception reaches its expiry date. 5. The business owner leaves the organization. 6. A retry follows an ambiguous external-system timeout. For each case, record who decides, what stops, which fallback runs, and what evidence remains. Rewrite any clause that does not produce one clear answer. ## Revision history | Version | Date | Change | Approved by | | --- | --- | --- | --- | | [0.1] | [YYYY-MM-DD] | Initial draft | [NAME OR ROLE] |
Fill decisions, not adjectives
Words such as appropriate, sufficient and regular are often where responsibility disappears. Replace each one with a threshold, role, event or interval. “Sensitive actions require appropriate oversight” becomes “external messages and state-changing tool calls remain pending until the process owner or named delegate approves the exact payload.” The second sentence can be tested.
Use one vocabulary across the policy and runtime. If the policy says “Tier 2 action,” the inventory, approval event and dashboard should use that same value. Translating between “high risk,” “restricted,” “level amber” and a numeric code during an incident is avoidable work.
- Name a role for every decision and a fallback when that role is vacant or unavailable.
- State whether a rule blocks execution, creates an alert or is checked during a later review.
- Define material change using observable events: a new tool, new data category, new external audience, wider autonomy or changed owner.
- Put time limits on approvals, exceptions, credentials and overdue reviews. “Until revoked” is rarely a useful default.
Join every policy clause to enforcement and evidence
A policy can be correct on paper and absent at run time. Build a three-column register while editing: the policy statement, the mechanism that enforces it, and the record a reviewer can inspect. Microsoft's current Agent 365 documentation is one concrete example of this pairing: its templates bundle policies for identity, audit, data protection and lifecycle management rather than asking administrators to restate a principle for every agent.
| Policy clause | Enforcement mechanism | Review evidence |
|---|---|---|
| Production agents use their own identity | Workload identity required at deployment | Identity ID joined to each tool event |
| Tier 2 actions require approval | Tool call pauses before execution | Proposal, approver, decision, time and executed payload |
| New tools require reapproval | Deployment diff blocks an unapproved tool scope | Change request and new permission envelope |
| Departed owners cannot remain accountable | Directory event opens reassignment and suspends overdue items | Owner history and reassignment decision |
Test the draft with an awkward case
A support summarization agent currently reads closed tickets. Its owner asks to add a refund tool and let it issue refunds below $50. The same model remains in place, but the action, data, external consequence and permission scope have changed.
A complete policy routes this as a material change. It names who re-tiers the use, who approves access, whether refunds require a gate, which proposed and executed fields enter the audit trail, how the first runs are supervised and how the credential is revoked if the trial ends. If the draft only says the use must be “reviewed,” it has not settled the case.
Repeat the test with a rejected approval, an expired exception and an owner who leaves. These cases expose missing decision rights faster than a line-by-line policy review.
Roll it out with one process before making it enterprise-wide
- 01Inventory one live or planned agentHuman approvalRecord its business purpose, owner, technical identity, tools, data categories, action types, approval boundary and lifecycle state.
- 02Map the policy to the running controlsHuman approvalFor every applicable clause, point to a configuration, check or person. Mark unsupported clauses plainly.
- 03Produce one review packetCodeExport policy denials, approvals, overrides, failures, access changes and overdue reviews for the process.
- 04Revise before broad approvalHuman approvalFix rules that created ambiguity or evidence nobody could retrieve. Then apply the tested version to the next risk tier.
Limitations and when not to use this
- This template is general operational guidance. It does not determine whether a use is lawful, regulated or contractually permitted in a particular jurisdiction or industry.
- A written policy does not enforce access, approvals, logging or retirement. Each clause needs a technical or procedural control and evidence that the control ran.
- Do not paste confidential architecture, credentials or incident details into a broadly shared policy. Keep the policy readable and link to access-controlled implementation records.
Sources
- AI Risk Management Framework Core — NIST Accessed 29 July 2026
- Software and AI Agent Identity and Authorization concept paper — NIST NCCoE Accessed 29 July 2026
- Agent 365 policy templates — Microsoft Learn Accessed 29 July 2026
Download and run the awkward-case test
Replace the bracketed decisions, then test the draft against one agent asking for a new tool, one rejected action and one expired owner.
Download and run the awkward-case testUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.