AI Acceptable Use Policy Template That Covers Agents, Not Just Chat

Most AI acceptable use policies were written for chat. Employees type, a model answers, and the risk is what they paste in.

Agents change that. An agent reads your systems, calls tools, and takes actions. The policy has to say what it may access, what it may do, who approves it, and what staff must report.

This is an AI acceptable use policy template built for agents, with sample clauses you can adapt. It is not legal advice. Have counsel review it before you adopt it.

Why Chat-Era Policies Fall Short

A chat policy answers one question: what may people put into a model? That still matters. Microsoft’s 2024 Work Trend Index found that 78% of AI users bring their own AI tools to work, and 80% at small and medium-sized companies. It surveyed 31,000 knowledge workers in early 2024. So people use tools you did not approve.

Agents add three new questions:

• What can it reach? Email, files, CRM, finance systems, code.
• What can it do? Read, draft, send, change, delete, pay.
• Who is accountable when it acts? The person who set it up, the owner of the system, or the vendor.

Look at a popular template and you will see the gap. Tenable’s guide, last updated October 2025, lists five solid elements: scope and roles, authorized tools and prohibited uses, data handling, a governance and change process, and safe use. It mentions autonomous agents as a security concern, but gives no agent-specific rules, and says little about plugins or connecting AI tools to internal systems. That is typical of templates I see. They handle the first generation of the problem.

The risk is real. OWASP defines Excessive Agency as the vulnerability that enables damaging actions in response to unexpected, ambiguous, or manipulated model outputs. It names three root causes: excessive functionality, excessive permissions, and excessive autonomy. Your policy should address each one directly.

Do You Need a Separate Agent Policy?

Short answer: you need agent rules, but not always a second document.

My recommendation:

• Small company: One policy with an “Agents and connected tools” section. Fewer documents means fewer gaps.
• Larger company, or regulated industry: A short agent standard that sits under the main policy. Security and legal can update it faster than the parent policy.

Either way, link it to your wider governance work. My guide on AI governance in practice covers roles and review, and the AI governance gap explains why policy alone does not close the problem.

If you want a framework behind the policy, use one. The NIST AI Risk Management Framework (released January 2023, with a Generative AI Profile in July 2024) organizes work into four functions: Govern, Map, Measure, and Manage. ISO/IEC 42001, published in December 2023, specifies requirements for an AI management system. You do not need to certify to use either as a checklist.

Scope: Tools, Agents and Plugins

Start by defining terms. A policy that says “AI tools” will be read three ways.

Define at least these:

• AI tool: Software that uses a model to answer or create. Chat apps, writing assistants, code helpers.
• AI agent: Software that uses a model to decide and then act through tools or connections, with or without a human in each step.
• Connector or plugin: Anything that gives a tool or agent access to a system, such as an email connector, a file integration, or an MCP server.
• Owner: The named person responsible for an agent.

Then say who the policy covers: employees, contractors, and anyone acting on your behalf. And say where it applies: company devices, personal devices used for work, and company accounts.

Connectors deserve their own line. The Model Context Protocol security guidance, in its November 2025 version, describes attacks such as the “confused deputy” problem and token passthrough, where a server passes along credentials it was never issued. Employees should not be wiring up unvetted servers to company data.

Data Rules

Keep data rules simple. Staff will follow three tiers, not twelve.

Tier	Examples	Rule for agents
Public	Published pages, marketing copy	Allowed with any approved agent
Internal	Plans, internal docs, non-sensitive records	Allowed only with approved agents on company accounts
Restricted	Customer personal data, health, payment, credentials, legal, trade secrets	Only with agents approved for that data class, by named owner

Add a few firm rules:

• No credentials, API keys, or passwords in prompts or agent configuration files.
• No personal accounts for company data.
• Agents get access to the minimum data needed for the task. This is the least-privilege idea, and I cover it in AI agent permissions.
• Know where data goes. Ask what the vendor does with inputs and whether it trains on them.

Action Rules and Approvals

This is the part chat policies skip. Sort agent actions by impact.

Action level	Examples	Rule
Read-only	Search, summarize, retrieve	Allowed within approved data scope
Draft	Write an email, propose a record change	Allowed. A human reviews before it takes effect
Reversible write	Update a ticket, tag a record	Allowed with logging and a named owner
Irreversible or external	Send to customers, move money, delete data, change permissions, deploy code	Human approval required each time

OWASP’s prevention guidance for excessive agency says to use human-in-the-loop control so that a human approves high-impact actions before they are taken. Put that into policy as a plain rule. The detail on how to design those gates is in human-in-the-loop AI agents.

Also decide who approves new agents. I suggest three tiers:

1. Low risk (read-only, internal data): The owner’s manager and IT.
2. Medium risk (draft or reversible writes): IT security plus the system owner.
3. High risk (restricted data or irreversible actions): A named review group with security, legal, and the business owner.

And require a way to stop an agent fast. See the AI agent kill switch for what that should look like.

Reporting and Review

A policy only works if people know what to report. Spell it out.

Staff must report:

• An agent doing something outside its approved scope
• Sensitive data sent to an unapproved tool
• Output that looks wrong, harmful, or manipulated
• A new agent or connector being used without approval
• Any request from an agent for new access it did not have before

Make reporting easy and safe. One email alias or form. No blame for good-faith reports. If people fear punishment, they hide problems.

Training is part of this. For EU operations, Article 4 of the AI Act requires providers and deployers to take measures to ensure a sufficient level of AI literacy among staff who operate AI systems on their behalf. Check how it applies to you, but a short onboarding session on this policy is good practice anywhere.

On review cadence: review the policy at least every six months, and any time you add a new class of agent or after any incident. Agent tooling changes faster than a yearly cycle can keep up with. Keep a short change log at the bottom of the document.

Sample Clauses for Your AI Acceptable Use Policy Template

These are plain-language starting points. Edit names, tiers, and thresholds for your company.

Definitions. “An AI agent is software that uses an AI model to decide on and carry out actions through tools or connections to company systems. This policy applies to all AI agents, whether built by us, bought from a vendor, or set up by an employee.”

Approved use. “Employees may use only agents and connectors on the approved list. To request a new one, submit a request to IT Security with the purpose, the data it will access, and the actions it can take.”

Named owner. “Every agent must have a named owner who is responsible for its access, behavior, and review. An agent without an owner must be turned off.”

Minimum access. “Agents receive only the access needed for the approved task. Access is reviewed every quarter. Shared or personal credentials may not be used to connect an agent to company systems.”

Human approval. “An agent may not send external communications, move money, delete records, change permissions, or deploy code without approval from a human each time.”

Logging. “Agent actions on company systems must be logged, with the time, the agent, the action, and the data touched. Logs are kept for [period set by Legal].”

Prohibited. “Employees may not enter credentials, customer personal data, or restricted information into any tool not approved for that data class. Employees may not connect an unapproved plugin, connector, or server to company data.”

Reporting. “Report any unexpected agent behavior, data exposure, or unapproved agent use to [alias] within one business day. Good-faith reports will not result in discipline.”

Enforcement and review. “Violations may lead to loss of access and disciplinary action. This policy is reviewed every six months and after any significant incident.”

For a broader security review, use the enterprise AI security checklist.

Rollout and Training

A policy nobody reads protects nobody. A simple rollout:

1. Inventory first. Find out which tools and agents people already use. Expect surprises, given the bring-your-own-AI numbers above.
2. Publish an approved list. Make the safe path the easy path. If approved tools are bad, people will route around them.
3. Train in 30 minutes. Cover data tiers, the approval rule, and how to report.
4. Brief managers separately. They approve low-risk agents and answer questions.
5. Set a first review date. Put it on the calendar when you publish.
6. Track two numbers. Requests approved or denied, and incidents reported. Low reports does not mean low risk. It may mean low awareness.

Bottom Line

A chat policy tells people what they may type. An agent policy also says what a tool may reach and do.

Cover four things: scope, data tiers, action levels with human approval, and reporting. Name an owner for every agent.

Next step: copy the sample clauses, tailor the tiers, and send the draft to security and legal this week.

FAQ

What should an AI policy include? At minimum: scope and definitions, approved tools, data rules, prohibited uses, approval steps for new tools, reporting duties, training, enforcement, and a review date. For agents, add rules on access, action limits, named owners, and logging.

Do we need a separate agent policy? Not always. A smaller company can add an “Agents and connected tools” section to one policy. A larger or regulated company may prefer a short agent standard under the main policy, so it can be updated faster.

Who approves new agents? Match the approver to the risk. Read-only agents on internal data can be approved by a manager and IT. Agents that write to systems need security and the system owner. Agents that touch restricted data or take irreversible actions need a review group that includes legal.

What can employees connect to an agent? Only connectors and data sources on the approved list, using company accounts. No personal accounts, no shared credentials, and no unvetted servers or plugins. Any request for new access goes through the approval process.

How often should the policy be reviewed? At least every six months, and after any incident or when you add a new kind of agent. Agent tools change quickly, so a yearly review is often too slow.

Does this policy replace legal review? No. This is a starting template and not legal advice. Have counsel check it against the laws that apply to you, including any AI literacy duties under the EU AI Act if you operate in the EU.

Three Ways to Work With TMA

Need an agent built? We deploy production AI agents in your infrastructure. Working pilot. Real data. Measurable ROI. → Schedule Demo

Want to co-build a product? We’re not a dev agency. We’re co-builders. Shared cost. Shared upside. → Partner with Us

Want to join the Guild? Ship pilots, earn bounties, share profit. Community + equity + path to exit. → Become an AI Architect