AI Agent Governance Policy Template.

An AI agent governance policy should say who owns each agent, what it may access and do, when a person must approve, what is logged, and how the agent is reviewed and switched off. It is short, specific and tied to a register of the agents you run. The template below gives you eleven clauses to adapt.

You do not need to invent the structure. The NIST AI Risk Management Framework (AI RMF 1.0, January 2023) is organized around four functions: Govern, Map, Measure and Manage. NIST says the framework is undergoing revision, so check the current version before you cite it. A joint CISA and ASD ACSC guidance on AI in operational technology, published with partner agencies in December 2025, names "Establish AI governance and assurance frameworks" as one of its four principles. Both treat governance as a starting point, not an afterthought.

Accountability is the thread through all of it. NCSC writes that humans remain responsible for deployment decisions, access permissions, safeguards and consequences. A policy makes that responsibility concrete: a named person for each agent.

Three sources are useful when you write or review the policy. Each one answers a different question.

For the technical controls behind the clauses, use OWASP. Its Top 10 for Agentic Applications 2026 and its guide to agentic threats are the best-known lists of what can go wrong, and the top threats to AI agents article maps them for you.

Copy the clauses, replace the text in brackets and delete what does not apply. Keep each clause to a few sentences. A policy nobody reads cannot be enforced.

1. Purpose, scope and definitions

"This policy applies to every AI agent that [your organisation] builds, buys or allows staff to use. An AI agent is a system that decides for itself which steps to take to reach a goal and can call tools." The OWASP agentic threat guide uses a similar test: does the AI agent independently determine the steps needed to achieve its goals? See the AI agents glossary entry.

2. Ownership and accountability

"Every agent has a named owner who is responsible for its access, behavior and shutdown. The owner approves deployment. No agent runs without an owner."

3. Agent register

"[Team] keeps a register with one entry per agent: purpose, owner, tools, data it can reach, permissions, approval rules, log location and next review date." The example further down shows an entry.

4. Identity and access

"Each agent has its own identity. Permissions follow least privilege. Credentials are temporary and limited in scope." See AI agent identity and access for more. NCSC advises least privilege, limited scope and temporary credentials. Agents are non-human identities and belong in the same inventory.

5. Autonomy and human approval

"The agent may read on its own. Changes inside our systems and any action outside or irreversible need approval from [role]." Use the human in the loop and least agency checklist to decide where each tool falls.

6. Untrusted input

"All text an agent reads, from web pages, email, files or other agents, is untrusted. Agents that read outside content must not hold privileges that the author of that content should not have." OWASP lists treating all natural-language input as untrusted among its mitigations, and NCSC says that when an LLM processes information from a party, its privileges should drop to that of the party. NCSC also says prompt injection may never be fully mitigated, so write the policy to limit impact. See prompt injection in AI agents.

7. Tools, servers and suppliers

"Agents may use only tools and servers on the approved list. Each addition is reviewed by [role]." OWASP's agentic list names MCP and A2A interfaces as part of the agentic supply chain. Detail is in securing MCP servers and tool access.

8. Data

"Agents get only the data the task needs. Secrets, keys and permission details are never placed in prompts." OWASP's system prompt leakage guidance says the system prompt should not hold API keys, auth keys or permission structure.

9. Logging and monitoring

"Inputs, outputs and tool calls are logged and kept for [period]. [Team] reviews alerts." NCSC recommends logging inputs, outputs and tool calls. Details are in monitoring and logging for AI agents.

10. Incident response and shutdown

"Every agent has a documented way to switch it off and revoke its access, and the incident plan covers agent misuse." NCSC advises planning incident response for agent deployments. Add the agent case to your incident response plan; our incident response plan template shows the structure.

11. Review and change

"New agents start as small pilots with bounded tasks. A change to tools, goals or permissions is a change request. Each agent is reviewed every [period], including adversarial testing." NCSC advises tightly bounded pilots, and OWASP advises putting goal changes under configuration management and running periodic red-team tests. See red teaming AI agents.

This is an illustrative entry for a made-up agent at acme.com. The names, tools and periods are invented to show the format.

Brandefense describes its own AI features as bound by the permissions of the signed-in user, with changes waiting for a person (see Brandefense AI). Ask any supplier for the same plain description before you add their agent to the register.