How to Write an AI Agent Acceptable Use Policy

An acceptable use policy is the one document most organizations deploying AI agents don't have and need before an incident forces them to write one under pressure. It is the artifact that tells employees, contractors, and — increasingly — the agents acting on the organization's behalf what they may do, with which tools, on which data, and what happens when the rules are broken. It's a natural companion to the site's AI governance guide and the broader AI agent compliance checklist, which covers audit-readiness beyond the AUP itself.

What an AUP is for, and who signs it

An acceptable use policy is a governance document that defines who may use an organization's AI systems, for what purposes, under what data-handling constraints, and with what accountability if those constraints are violated. For an agent-inclusive AUP specifically, it also defines what actions an autonomous system may take without a human confirming each one, and what triggers human review.

Employees and contractors typically acknowledge the AUP as a condition of system access, the same way they acknowledge an acceptable-use policy for corporate email or internet access today. What's new in 2026 is that the policy increasingly has to cover a second category of actor: the agents and embedded AI features acting on the organization's behalf, which don't sign anything but still need explicit rules governing what they're permitted to do.

Scope: employees, contractors, and agents acting on the org's behalf

A usable AI acceptable use policy defines its scope explicitly — who and what it covers, including employees, contractors, and, increasingly, agents and vendor systems acting on the organization's behalf (dope.security, "AI Acceptable Use Policy: A Free 2026 Template"). This scope statement is not boilerplate: an AUP that only names "employees" leaves an obvious gap the moment an agent is deployed to act autonomously within a workflow a human used to run manually. The policy should name agents as a distinct covered category, not assume the human who configured an agent absorbs all responsibility for what it subsequently does.

The sections a usable policy needs

At minimum, a usable policy covers an approved-tools list plus the process for adding new tools, data-classification rules for what can and cannot be given to an AI system, prohibited uses, accountability and incident-reporting requirements, and a review cycle (dope.security). A more complete version extends this to eight sections: scope and applicability, approved and prohibited tools, data-classification rules, human-review requirements, confidentiality obligations, incident reporting, training requirements, and enforcement or disciplinary consequences (Strac.io, "AI Acceptable Use Policy Template").

The extended version is the better starting template for any organization deploying autonomous agents, because human-review requirements and confidentiality obligations are exactly the sections that carry the agent-specific weight a chatbot-only AUP doesn't need.

Data-classification rules: what may never reach an AI system

Every version of a usable AUP includes explicit data-classification rules governing what can and cannot be given to an AI system (dope.security). For an agent AUP, this needs to be more specific than a chatbot policy's typical "don't paste confidential data into a public chat tool" guidance, because an agent with tool access can read and pass data along without a human ever typing it into a prompt. The policy should classify data (public, internal, confidential, restricted) and state explicitly which classifications an agent may access, process, or output — and which classifications require the data never leave a system the agent doesn't have access to at all.

Approved-tools list and the process for adding one

A usable policy names its approved-tools list and, just as importantly, the process for getting a new tool added to it (dope.security). Without a defined intake process, the approved-tools list calcifies and employees route around it — the exact shadow-AI dynamic covered in the rise of shadow AI. The intake process should specify who reviews a new tool request, what data-handling and security questions it must answer, and a target turnaround time, so the policy doesn't become the reason people go around it.

Numbered authoring procedure

Writing an AUP that survives contact with legal, security, and actual usage follows a repeatable sequence:

1. Draft against the eight-section extended template, filling in scope, tools, data classification, human-review requirements, confidentiality, incident reporting, training, and enforcement for your organization's specific systems.
2. Route the draft through legal review for enforceability language, alignment with employment agreements, and any regulatory documentation obligations that apply — including, for organizations subject to the EU AI Act's high-risk deployer requirements, governance-documentation obligations that give the AUP concrete regulatory grounding rather than best-practice value alone (Aona AI).
3. Pair the policy with a training rollout, not just a signature requirement — a policy nobody reads is not a control.
4. Publish the approved-tools list and intake process as a living artifact, separate from the static policy text, so it can be updated without a full policy revision each time.
5. Set an explicit review cycle (quarterly is common for fast-moving AI tooling) and assign an owner responsible for triggering that review, not leaving it to whoever notices the policy is stale.

What makes an agent AUP different from a chatbot AUP

Most AI acceptable use policy templates in circulation were written for generative chat tools and barely mention autonomous agents (per the researcher's review of currently available templates). Coverage should explicitly extend beyond generative chat tools to agentic AI and embedded AI features inside SaaS products the organization already uses, and to the devices those agents and features run on — corporate-managed, BYOD, and personal (Strac.io). Four gaps specifically separate an agent AUP from a chatbot-only version:

• Autonomous action. A chatbot produces text a human reads and acts on. An agent takes actions directly — the policy needs rules for what actions require human confirmation versus what an agent may execute unsupervised, tied to the least-privilege access it's been granted.
• Tool grants. A chatbot AUP governs what a person types in. An agent AUP has to govern what tools and systems the agent itself has been connected to, since that's the actual capability surface.
• Embedded SaaS AI. Many AI capabilities now arrive pre-embedded in SaaS products a team already uses, not as a standalone chatbot anyone opted into — the policy has to name this category explicitly or it goes ungoverned by default, feeding directly into the inventory problem most organizations haven't solved.
• BYOD and personal devices. An agent or embedded AI feature running from a personal device carries different data-exposure risk than the same capability running on a managed corporate device, and the policy should say so explicitly rather than assume device management is out of scope.

Getting the policy in front of the people who need it

An AUP that exists only as an onboarding-day signature is a compliance artifact, not a working control. Pair it with the approved-tools intake process, the shadow AI detection practice it depends on for enforcement, and a review cadence that actually happens — and it becomes the document legal, security, and every employee or agent-owning team can point to when the question "was this allowed" comes up, instead of discovering the answer after the fact.

That last point is worth restating because it's where most AUPs quietly fail: the policy is signed once, filed, and never revisited as new tools, new agent deployments, and new embedded AI features enter the organization between review cycles. Treat the AUP the way a security policy is treated generally — a living document with an owner, a scheduled review, and a defined path for someone to request an exception or a new tool without having to route around the policy entirely. A policy that's easier to work within than to work around is the only version that actually holds.