How to write an AI acceptable use policy for your IT team

Somewhere on your team, a firewall config has probably been pasted into a chatbot to debug a rule, and a coding agent has been pointed at a repository it can read and change. Whether either was allowed is a question many organizations can’t answer.IBM’s 2026 Cost of a Data Breach Report found that 68% of breached organizations lacked AI governance policies, up from 63% a year earlier, and that 43% reported security incidents involving shadow AI, up from 20%.

The difficult part is that an AI acceptable use policy for an IT team has to do more than name the tools people may use, since IT staff hold the configs, credentials, logs, and admin rights that make a careless paste or an over-permissioned agent expensive. An AI acceptable use policy sets out which AI services staff may use, what information they may give them, and what systems AI agents may reach. This guide covers why most policies fail, what an enforceable one controls, and how to write one, with a template at the end.

Why most AI policies fail in practice

Most AI policies fail because they state a preference but nothing in the environment makes it true. The rule names a tool, bans a tool, or tells an AI agent what not to do, while the people and systems it governs keep the access they already had.

Four patterns come up repeatedly, and they share a root cause:

1. Approved-tool lists control the product, not the risk

The most common first draft is a single rule that just says “use the approved AI tool”. This rarely holds in practice. ChatGPT and Gemini are two separate tools that can both be useful for coding, troubleshooting, and research, and anyone can reach them. Declaring one product approved doesn’t immediately make the alternatives disappear.

The deeper problem is what the rule can’t answer. It identifies a product, but it says nothing about:

• What information may go to any other AI service
• When a managed company account is required
• Whether an AI agent may read or change company systems

So it fails in both directions. A generic technical question asked through an outside service breaks the rule even though no company data is involved. Meanwhile, approving a product does nothing to define whether it may receive proprietary source code or be connected to repositories and cloud environments.

» Learn more about IT management

2. Blanket bans move AI use out of sight

A ban can reduce exposure on managed devices, but that doesn’t remove the demand. If technicians still need the capability, the work moves to a personal account, phone, or browser session the organization can’t see, and an AI or IT governance problem becomes a shadow AI and IT problem.

IBM’s 2026 Cost of a Data Breach Report put a price on it: breaches involving shadow AI averaged $5.39 million, against a global average of $4.99 million for all breaches.

» Learn more about the spread of Shadow IT and how much Shadow IT is costing your business

3. Prompt instructions are treated as access controls

In July 2025, SaaStr founder Jason Lemkin reported that Replit’s AI agent had deleted his production database during a code freeze. Replit CEO Amjad Masad confirmed that an agent working in development had deleted production data and said it “should never be possible.”

The instruction was never the control. A prompt is guidance to a model, which still has to interpret it while working out how to finish its task. If the agent holds credentials that permit deletion, a tool that can perform it, and enough autonomy to run it without approval, the destructive capability is still there whatever the prompt says. Nobody secures a human administrator this way. You don’t protect a production database by asking an account not to drop it.

4. Policy, procurement, and controls are designed apart

Behind all three patterns is the same gap. The policy is drafted as a document, procurement picks tools on cost and licensing, and technical controls are configured without reference to either:

• If procurement supplies an assistant that can’t do the work, no policy wording removes the need, and if the policy demands that no employee ever reaches another AI service, no control can deliver that.
• A capable approved tool still doesn’t settle what data it may receive or what systems it may touch, and a policy disconnected from how tools are bought and how access is enforced is easier to bypass than to enforce.

The same IBM report found that only 19% of organizations said their AI governance and security teams coordinate.

» Make sure you know the difference between automation and Autonomous IT

What an enforceable AI policy controls

An enforceable policy controls two things: the information given to an AI and the authority given to it. The product name is neither. Every rule in the policy follows from one of those two boundaries, which is what lets it be tied to identity, permissions, and logging, and what keeps it working when the tools change.

More specifically:

The information AI may receive

The first boundary separates processing company information from general AI assistance. Each side has its own rule for where the request may go and which account it runs under:

For MSPs, anything belonging to a client sits on the restricted side. Check client contracts and regulations too, since they may restrict AI processing of client data whatever your internal policy allows. Where a data classification scheme already exists, the boundary inherits it.

Gray areas need a rule too. Sanitized logs, configs with hostnames removed, and error messages that contain internal names should count as company information unless the data owner has cleared them. When in doubt, use the approved service.

The open side is deliberate. Staff keep a legitimate way to use outside AI, and when the approved service can’t handle a task that involves company data, they have a route to request another one for security and data-handling review. Without that route, the need goes underground. The open side still has limits: services barred by law, sanctions, or client contract stay prohibited.

The authority AI may hold

The second boundary covers what an AI is able to do. Being available as an assistant (or even approved to receive company data) doesn’t authorize a service to reach company systems. If it can do any of these things, it needs explicit authorization for the required access:

• Read files
• Execute commands
• Modify repositories
• Access cloud environments
• Change infrastructure

It should receive only the permissions its approved function requires, with read-only access wherever write access isn’t needed.

Connectors count as authority too. Every plugin, browser extension, or MCP server that lets an AI reach company systems is an access grant, and it goes through the same authorization. Agents also need their own service identities: they should never run under a technician’s personal or shared administrator credentials, and secrets should come from a vault or secrets manager, not a pasted prompt.

For autonomous agents, that authority is set in the execution layer, outside the model. Destructive, irreversible, privileged, security-sensitive, and production-changing actions are technically restricted and held at an approval gate, and prompt instructions don’t count as an authorization control. Whether an action needs approval is decided by the workflow, not by the agent’s own reading of the situation.

What remains is deciding which actions sit on each side of the gate. It largely depends on what happens if the agent is wrong, so look at these factors:

A routine action that affects one verified user and follows a predefined, approved path can run without a person. An action that fails any one of these tests stops and waits for one. If the risk can’t be determined, the default is to require approval.

» Here are our picks for the best enterprise AI platforms for IT management

How to write and enforce your AI acceptable use policy

A policy is quick to write once each rule is paired with a control and you’ve decided where agents stop for approval. Here are the three main procedures to follow:

Draft the policy in eight steps

1. List the AI services your team uses today for scripting, troubleshooting, research, and documentation, including personal accounts and coding agents. An approved-tool list shows what you intended, so ask technicians directly.
2. Write the information rule by naming the data categories that count as company information, such as source code, configuration files, logs, credentials, ticket content, and client data, and stating that they go only to approved services through managed accounts.
3. Write the system-access rule, stating that no AI service or agent may read files, run commands, or change systems without explicit authorization for that access. Include connectors and plugins in that rule, and require agents to run under their own service identities.
4. Set approval criteria for services. Before a service joins the approved list, check whether the vendor may train on your data, how long it retains inputs, where data is stored, and which connectors it can use to reach your systems.
5. Write the output-review rule. AI-generated scripts, configs, and firewall rules get reviewed and tested before they run in production, and the person who runs the output owns the result.
6. Pair every rule with the technical control that enforces it. High-impact or destructive actions must be blocked in the execution environment, never by a prompt.
7. State what stays allowed. Staff may use outside AI services for general questions, provided they share no company data and the service has no access to company systems. Add a way for staff to request a different service when the approved one can’t do the job.
8. Schedule the review, checking the policy against actual use on a fixed cadence and whenever a new AI service or agent is introduced. Update the approved list freely and leave the underlying rules stable.

The document also needs three administrative pieces before it goes out:

• An owner: One named role that maintains the policy, approves exceptions, and signs off new services.
• Acknowledgement: A record that each technician and contractor has read it.
• A violations process: A way to report mistakes without blame. Punishing staff for unsanctioned tool use just stops others from disclosing theirs.

» Looking to automate at scale? Don’t miss this AI agent stack

Tie each rule to a control

A rule is enforceable when something in the environment makes it true. Here are some examples:

Decide where agents stop for approval

The agent rules need to be worked out action by action. For example, Robin by Atera is an AI technician that resolves Tier-1 and complex Tier-2 technical incidents end to end. It handles end-user support requests, verifies the requesting user, and takes approved actions such as password resets, account unlocks, app installs and repairs, device restarts, and removal of risky mailbox rules.

The policy decides which of those run without a person:

When an action needs approval, the policy should require the agent to stop before execution and raise a request containing:

• The requested action
• The affected user or device
• The reason for the action
• The expected impact
• Any relevant security context

The policy then sets how that request is handled:

• First approver: The service desk or a designated operational approver handles routine exceptions.
• Escalation: Privileged-account changes, suspected compromise, security-control changes, and anything affecting shared or production services go to the system owner or security team. Even the ticket escalation process can be automated.
• Unclear risk: The request defaults to the higher authority.
• Scope and expiry: An approval covers one specific action and expires if unused within a defined window.
• Rejection or timeout: The environment is left unchanged.
• Audit trail: The request, approver, decision, and resulting action are retained.

In Atera, Playbooks can create approvals as part of a workflow, and Robin logs the actions it takes, so these requirements map onto configuration instead of staying on paper. Start Robin with a narrow set of low-impact actions, review the results, and widen its scope over time.

» Make sure you know the differences between help desk vs service desk vs ITSM

AI acceptable use policy template

Your acceptable use policy will obviously vary depending on your specific environment, but here’s a good starting point template to build your AI acceptable use policy around. Adapt the bracketed fields to your organization.

1. Purpose and scope

This policy governs the use of AI services and autonomous AI agents by [Company] employees, contractors, and third parties working on [Company] or client systems.

2. Definitions

“Company information” means [list data categories, or reference the data classification policy]. “Approved service” means an AI service listed in [location of approved list]. “Autonomous AI agent” means any AI system able to read files, execute commands, or change systems.

3. Ownership

[Role] owns this policy, maintains the approved service list, and decides exception requests.

4. Use of AI with company information

Organization-approved AI services must be used where [Company] information, credentials, customer information, proprietary source code, internal documentation, infrastructure details, or other restricted company data is processed. External AI services and personal AI accounts may be used for general assistance where no [Company] information or restricted data is disclosed and no access to [Company] systems is provided. Autonomous AI agents must not access or act on [Company] systems unless explicitly authorized for that purpose. Client information is handled under the applicable client contract.

5. Approved services and connectors

[Role] approves each service before it is added to the approved list. Review covers whether the vendor may train on [Company] data, how long inputs are retained, where data is stored, and which connectors, plugins, or extensions the service can use to reach [Company] systems. Each connector is an access grant and requires explicit authorization under section 7.

6. Review of AI output

Scripts, configurations, firewall rules, and other AI-generated changes must be reviewed by a qualified person and tested before they run in production. The person who runs or deploys AI-generated output is accountable for it.

7. Agent permissions

Autonomous AI agents must operate under least-privilege permissions appropriate to their assigned function. Instructions contained in prompts must not be treated as authorization controls. Destructive, irreversible, privileged, security-sensitive, or production state-changing actions must be technically restricted and require independent human authorization before execution. Where human approval is required, the execution layer must prevent the action from proceeding until that approval has been validated. Agents run under dedicated service identities, not personal or shared administrator credentials, and receive secrets from [secrets store], never through prompts.

8. Agent autonomy and approval

Autonomous AI agents may execute pre-approved, low-impact and reversible actions without human approval where the requesting user has been appropriately verified and the action remains within the agent’s explicitly authorized scope. Human approval is required for actions involving privileged identities, security controls, shared or production services, significant business impact, uncertain security context, or changes that cannot be readily reversed. Approval requirements must be enforced by the execution workflow and must not depend solely on the agent determining whether approval is necessary.

9. Approval routing and audit

Approval requests go to [service desk or designated approver]. Requests involving privileged accounts, suspected compromise, security controls, or shared or production services escalate to [system owner or security team]. Approvals apply to one action and expire after [window]. All requests, decisions, and resulting actions are logged.

10. Exceptions

Where an approved service cannot perform a legitimate task involving company information or system access, staff may request review of an alternative service through [process].

11. Monitoring

[Company] monitors AI use on managed accounts, devices, and networks to enforce this policy and identify unapproved services.

12. Acknowledgement

All staff and contractors in scope must acknowledge this policy on joining and after each revision.

13. Violations

Suspected breaches are reported to [role]. Unintentional or self-reported breaches are treated first as a process issue. Deliberate or repeated disclosure of restricted data is handled under [disciplinary policy].

14. Review

This policy is reviewed every [interval] and whenever a new AI service or agent is introduced.

Write the policy your controls can enforce

AI tools will keep changing faster than any approved list can track, so the parts of your policy worth getting right are the ones that stay put. This includes what company information an AI service may receive, which identity it runs under, what systems it can reach, and which actions stop for human approval. Write those down, tie each one to a control that enforces it, and review the policy against how your team uses AI in practice.

The same boundaries apply when an Autonomous IT agent sits in your service desk. For example, Robin verifies the requesting user, takes only approved actions, routes sensitive requests for approval, and logs each step, so your autonomy clause has something concrete to map onto.

» Learn how to train your team to work with agentic AI or skip straight to an Atera free trial