TL;DR: Most AI acceptable use policies are unenforceable as written, because they were drafted for a world where every AI interaction was a SaaS session visible at the gateway. Access clauses enforce well. Data-handling clauses enforce partially. Clauses about locally-run models, coding agents and their extensions enforce only at the endpoint, and most organisations have nothing looking there. Map each clause to the system that would catch a violation; the ones with no answer are your real policy.
The question underneath "which platform enforces this"#
Security teams asking which platform enforces an AI acceptable use policy are usually asking something sharper: we wrote this document, and we suspect nothing behind it is real.
That suspicion is generally correct, and it is not a drafting failure. Most AUPs in circulation were written between 2023 and 2025, when AI use meant an employee opening a chatbot in a browser tab. Every clause implicitly assumed the interaction was a SaaS session — reachable over the network, identifiable by destination, inspectable in transit. That assumption held well enough to build controls on.
It does not hold for a model running on a laptop, or for a coding agent with filesystem access, or for an MCP server a developer added to a config file on Tuesday. The clauses covering those did not get weaker. They never had an enforcement point.
Clause by clause, what actually binds#
| Clause type | Enforceable? | Where |
|---|---|---|
| Access to named hosted services | Yes | CASB / secure web gateway |
| Approved-tool list | Partly | Only if something inventories what is installed |
| Data-handling rules | Partly | DLP on inspected channels; nothing elsewhere |
| Locally-run models | Endpoint only | No network or identity signal exists |
| Coding-agent permissions | Endpoint only | Agent config is a local file |
| Extensions, skills, MCP servers | Endpoint only | Per-user config, no admin console |
| "Use good judgement" | No | Documentation |
Two things stand out.
The clauses that enforce cleanly are the oldest ones, inherited from web filtering, and they cover the smallest and fastest-shrinking share of actual AI use. The clauses covering how people work now cluster entirely in the bottom half, where the only available enforcement point is the machine.
The highlighted band is how people work now, and it is the band with no enforcement point at the network or identity tier.
Where policies quietly stop matching reality#
"Only approved AI tools may be used with company data." Enforceable for hosted services. A model running locally makes no outbound request, so there is no destination to categorise and no session to attribute. The clause is not violated loudly; it is violated invisibly.
"Do not share confidential information with AI systems." DLP can inspect what leaves through channels you terminate. It cannot inspect a prompt that never leaves the machine, and it cannot see a coding agent reading a file directly off disk — no paste, no upload, no inspection point.
"AI tools must be reviewed before use." Reasonable, and it assumes a procurement moment. Adding an MCP server is a text edit to a JSON file. There is no purchase, no login, no ticket. The review process has nothing to attach to, which is the subject of our MCP server visibility writeup.
"Agents must not be granted excessive permissions." The permission grant is a local configuration file on a developer's machine. Nothing outside that machine records what was granted or when it changed.
Enforcement has three layers, and vendors sell one#
When someone asks which platform enforces the policy, the honest answer is that no single one does.
Network. A CASB or secure web gateway blocks and logs access to hosted AI services. Mature, well-understood, and scoped to services you thought to list.
Data. DLP inspects content moving through channels you terminate. Effective where you have coverage; silent where you do not.
Endpoint. The only layer that sees locally-run models, which coding agents are installed, what those agents are pointed at, and which skills and MCP servers are attached to them. For a large and growing share of the policy, this is the only place a violation is observable — and it is the layer most organisations have not extended to AI at all.
A vendor selling one of these as AUP enforcement is describing a layer, not a solution. That is fine, as long as you know which layer you bought.
Measure coverage, then write clauses#
The practical move is unglamorous. Take the policy you already have, and for each clause name the specific system that would detect a violation. Not the team responsible — the system.
Clauses with a named system are controls. Clauses without one are documentation. Both have a place: documentation establishes that an expectation was communicated, which matters for accountability and for audit. It just should not be mistaken for prevention.
Our AI acceptable use policy guide covers drafting the document, including the ten clauses worth having. This post is the other half: which of those clauses anything behind them can actually enforce, and where you would have to look to find out.
FAQ#
Which platforms actually enforce an AI acceptable use policy across employee tools?#
No single platform covers the whole policy, and any vendor claiming otherwise is describing one layer. Enforcement splits across three: a CASB or secure web gateway can block access to unapproved hosted AI services; a DLP layer can inspect what leaves through those services; and an endpoint agent is the only thing that sees locally-run models, coding agents and the MCP servers and skills attached to them. Clauses covering the third layer have no enforcement point at the network or identity tier at all.
Why are most AI acceptable use policies unenforceable?#
Because they were written against the hosted-chatbot era, when every AI interaction was a SaaS session you could see. Clauses like "do not paste customer data into unapproved AI tools" assume the tool is reachable over the network and identifiable by destination. A local model on a laptop, or a coding agent calling it, satisfies neither assumption, so the clause describes a behaviour nothing can observe.
Which AUP clauses can actually be enforced technically?#
Access restrictions on hosted services enforce well through a gateway. Data-handling rules enforce partially, via DLP on inspected channels, and not at all on channels you do not inspect. Approved-tool lists enforce only if something inventories what is installed. Clauses about agent permissions, extensions and locally-run models enforce only at the endpoint, and most organisations have nothing there today.
What is the difference between a policy and a control?#
A policy states an intention and assigns accountability after the fact. A control changes what is possible, or at minimum produces a record when the boundary is crossed. A clause with no corresponding control is not a weak control, it is documentation — useful for establishing that an expectation was communicated, and not useful for preventing or detecting anything.
How should we prioritise AUP enforcement work?#
Measure coverage before adding clauses. For each clause already in the policy, name the system that would detect a violation. The ones with no answer are the gap, and they cluster predictably around endpoint-resident AI: local models, coding agents, and the extension surfaces attached to them. Closing the largest uncovered cluster beats adding language to the document.
Does blocking AI tools work as an enforcement strategy?#
Partially, and with a predictable failure mode. Blocking hosted services at the gateway is effective against the services you know to block, and it pushes determined users toward the options you cannot see — local models, personal devices, and unapproved coding-agent extensions. Blocking narrows the visible surface faster than it narrows the actual one, which is why inventory should precede enforcement.
Close the layer nothing is watching#
Access and data clauses have owners. The endpoint clauses — local models, coding agents, the skills and MCP servers attached to them — usually have none. Workstation Lens covers that layer across the fleet, through the EDR you already run, so the bottom half of your policy has a system behind it.
