An AI acceptable use policy tells your staff which AI tools they may use and what they may do with them. Most of the ones in use today were written for chatbots, so they say what you may type into a box. They say nothing about an AI agent that reads files, runs commands and installs software on a developer's laptop. This article is for the person who owns that policy. It covers what the policy already does well, where a coding agent falls outside it, the seven clauses to add, a section you can copy, and how to know the clauses are being followed after everyone has signed.
What an AI acceptable use policy covers today
The policy became a standard document in 2023, when staff started pasting company data into public chatbots. So it is built around one risk: information leaving the company through a prompt.
Read a common template and you can see it. FRSecure's free one has ten provisions: customer data confidentiality, secure channels, legal compliance, vendor review and approval, data retention, appropriate use, audits, monitoring, employee education and policy updates (source: FRSecure). Every one of them treats AI as a service a person talks to. The person decides what goes in, reads what comes out, and acts on it themselves.
That is still right for a chatbot, and you should keep it. It just does not describe the AI tools your developers use now.
Why a coding agent falls outside it
Claude Code, Cursor, Codex CLI and GitHub Copilot in agent mode do not wait for a person to act on their answer. They act. On a developer's laptop, an agent works with the developer's own access, which means four things your policy never had to think about.
It reads files nobody typed in. The developer asks for a bug fix. The agent opens whatever it decides is relevant, and that can include the .env file, the cloud credentials in ~/.aws and the SSH keys. No one pasted anything, so the "do not enter confidential data" clause never applies.
It runs commands. It can install a package, push to a repository, call an API or delete a directory. Each agent has a permission prompt that asks the developer first, and each one has a way to switch the prompt off. The Claude Code permissions article shows the three ways that happens on one agent.
It loads other people's code. MCP servers, skills, extensions and hooks add tools to the agent. A developer adds one in a minute, from a blog post or a marketplace. In September 2025 a package called postmark-mcp copied a real MCP server and added one line that sent a copy of every email to its author (source: The Register). The "vendor review" clause in your policy was written for a contract with a company, not for a package one developer installed on a Tuesday.
It can run with nobody there. A scheduled job or a long session can keep an agent working for hours with no person reading what it does.
So the policy needs a section for agents. It is short. Seven clauses cover it.
The seven clauses to add
Each clause below has the rule, the reason, and where on the laptop you would see it being broken. The last part matters most, because a clause you cannot check is a wish.
1. Approved agents, on a company account. Name the agents staff may use, and say they must be signed in with the company account. A personal account means the company's code goes to a plan with no company contract behind it, and the agent stays signed in after the person leaves. You see this in the agent's own sign-in file on the laptop.
2. The permission prompt stays on. Developers may not run an agent in a mode that skips approval, and may not give it standing permission to run any shell command. This is the control that keeps a person in the loop. It is a line in a settings file, and it changes every time someone clicks "don't ask again".
3. Credentials the agent must not read. List them: .env files, cloud credential folders, SSH keys, production tokens. If an agent can read a credential, anything that tricks the agent can use it. The credential count on one real laptop shows how many that is.
4. No secrets in the prompt. Never paste a key, token or password into the agent's chat. This is the old chatbot clause, and it still holds: what goes into the prompt goes to the model provider and into the session history on disk.
5. New components, packages and models are requested first. An MCP server, skill, extension or hook is software from a third party that runs with the developer's access. So is a package the agent decides to install, and so is a model pulled from a public registry. The clause says: ask first, use it when it is approved. For that to work, asking has to be fast, or people will skip it.
6. No unattended agents with prompts off. An agent may run on a schedule or in a pipeline only when it is set up for that, with its own narrow access. A developer's own agent, with the developer's own credentials, does not run overnight with approvals off.
7. Say something when the agent surprises you. If an agent deletes something, sends something or acts on instructions it found in a web page or a file, the developer reports it the same day, without blame. Prompt injection looks like an odd tool call to the person watching, and that person is the only one who sees it happen.
You can check five of these seven by reading files that are already on the laptops. Join the launch list and see what those files say on your own machines
A section you can copy
Add this to the policy you have. Change the tool names, the paths and the request route to fit your company.
AI CODING AGENTS
This section applies to any AI tool that can read files, run commands
or install software on a company device, including Claude Code, Cursor,
Codex CLI and GitHub Copilot.
1. Approved agents. Use only the agents on the approved list, signed in
with your company account. Do not sign in with a personal account.
2. Approval prompts. Keep the agent's approval prompts on. Do not use a
mode or a flag that skips them, and do not grant an agent standing
permission to run any shell command.
3. Credentials. Do not allow an agent to read .env files, cloud
credential folders, SSH keys or production tokens. If an agent asks
to read one, say no.
4. Secrets. Do not paste keys, tokens or passwords into an agent.
5. New software. Request MCP servers, skills, extensions, hooks,
packages and models through [request route] before you install them.
You will get an answer within [one working day].
6. Unattended use. Do not leave an agent running on a schedule or
overnight with your own credentials and its approval prompts off.
7. Reporting. If an agent deletes, sends or changes something you did
not ask for, or follows instructions that did not come from you,
tell [security contact] the same day. Reports are never held
against the person who makes them.
Exceptions are granted in writing by [owner], for a named team and a
stated period.
A worked example: one developer, three weeks after signing
Picture a developer who read the policy, agreed with it, and signed it. Three weeks later their laptop looks like this. Nothing here is unusual, and nobody did anything in bad faith.
They use Cursor on their personal account, because the company licence took a week to arrive and they never switched. That is clause 1.
In one repository, the agent's local settings file allows ssh and git push without asking. They clicked "don't ask again" twice during a release. That is clause 2.
Their AWS credentials file sits in the home folder, where every agent on the machine can read it. They did nothing to cause this. It is the default. That is clause 3.
They added an MCP server for the team's issue tracker from a tutorial. The package is not pinned to a version, so it updates itself to whatever the author publishes next. That is clause 5.
A scheduled job runs an agent every night to tidy up branches, with approval prompts skipped so it can finish. That is clause 6.
Five of the seven clauses are broken on one laptop. The developer would tell you, honestly, that they follow the policy. And you have no way to know any of this, because none of it leaves the machine.
Why a signed policy is not enough
You could sit with that developer for an hour, read the files together and fix all five. That works for one laptop.
With two hundred developers it stops working. The settings files change daily, some of them written by the agents themselves. New components appear every week. People join, and people leave with an agent still signed in. A yearly sign-off records that everyone read the policy on one day. It does not show what the laptops looked like the day after.
An auditor, a customer's security questionnaire and your own board all ask the same follow-up question: how do you know it is followed? The answer has to come from the machines. The AI agent governance article covers who decides what, and the lockdown checklist is the technical version of clauses 2 and 3.
Where it fits your frameworks
You do not need a new programme for this. The section lands in controls you already have.
- EU AI Act. Article 4 asks you to make sure staff who use AI systems have enough AI literacy for the job, and it has applied since 2 February 2025 (source: Article 4). A policy that people are trained on is how most companies show it.
- ISO/IEC 42001. Annex A.2 asks for an AI policy, and A.9 asks for processes for the responsible use of AI systems. The agent section is the A.9 text for developer machines. The ISO 42001 article goes through the controls.
- NIST AI RMF. The Govern function asks that policies for AI risk are "in place, transparent, and implemented effectively" (source: NIST). The last two words are the part a document cannot do alone.
How ZYBE handles this
ZYBE reads the agents' own files on every laptop it is installed on, and shows you each clause as a finding with the machine, the developer and the fix beside it. Agent signed in with an unknown account is clause 1. Agent acts without asking and Agent may run shell commands without asking are clause 2. Credentials an agent can read is clause 3, and Secret pasted into the prompt is clause 4, recorded as a hash so the secret itself never leaves the machine. Unreviewed components and MCP server package not pinned to a version are clause 5, and Agent runs unattended is clause 6. For clause 5 there is a request screen: a developer who wants a new MCP server, package or model asks for it, and an admin allows it for a week, a month or for good, or says no. In block mode ZYBE stops a credential file read or an unapproved component on the call, and tells the agent why. The compliance view files all of it under the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, so the policy and the proof are in one place.
Join the launch list: first access when ZYBE opens, and the lockdown checklist in the first mail
Frequently asked questions
What should an AI acceptable use policy include? Two parts. The first is the one most policies already have: which AI tools are approved, what data may be typed or uploaded into them, who checks the output, and who to tell when something goes wrong. The second is for AI agents that act on a machine, and most policies lack it: which agents are approved and on which account, that the permission prompt stays on, which credentials an agent must never read, that secrets are never pasted into a prompt, that new MCP servers, skills, packages and models are requested before they are installed, and that an agent does not run unattended with its prompts off.
Is there an AI acceptable use policy template for developers? The section in this article is written to be copied. It is seven clauses for AI coding agents such as Claude Code, Cursor, Codex CLI and GitHub Copilot, and it is meant to be added to the AI acceptable use policy you already have, not to replace it. Change the named tools, the credential paths and the request route to match your company, and have the engineering lead read it before it is signed, because every clause changes how a developer works.
Who owns the AI acceptable use policy? The CISO or the person with the security responsibility owns it, with legal and HR signing the parts on data and conduct. The agent section needs a second owner in engineering, because the approved list of agents and components changes monthly and somebody has to answer the requests. Review the whole policy once a year, and the approved list every time a new agent or a new kind of component shows up on a laptop.
Does the EU AI Act require an AI acceptable use policy? Not by name. Article 4 has applied since 2 February 2025 and asks every company that uses AI systems to take measures so that its staff have a sufficient level of AI literacy. A written policy that people are trained on is the usual way to show that measure exists. The Act does not ask for the document, it asks for the outcome, so the policy counts for more when you can show it is followed on the machines.