Your AI Policy Is a PDF. Make It Executable.

Every company I talk to now has an AI acceptable-use policy. It lives in Confluence or a signed PDF, it was written by legal with input from security, and it says sensible things: don't paste customer data into chatbots, human review is required for AI-generated code, agents shouldn't touch production credentials.

Here's the uncomfortable question I ask next: which of those rules would actually stop anything? Not discourage — stop. In almost every case the honest answer is none of them. The policy is documentation of intent. The agents your engineers run every day never read it.

This mattered less when "AI use" meant a person typing into a chat window — you could train the person. It matters enormously now that the dominant mode is agents: tools that read files, call APIs, open pull requests, and run for an hour without a human watching each step. You cannot train an agent with a PDF. You can only constrain it with configuration. Which means the real policy — the one that's actually in force at your company — is whatever your tools' default settings happen to be. If you haven't written policy into configuration, your policy is "vendor defaults," and nobody signed off on that.

Policy as code, for AI

The good news: the enforcement surface already exists. Modern AI tooling is more configurable than most of the policies governing it. The work is mapping each sentence of the PDF to the mechanism that enforces it.

"Agents should have least-privilege access" → permission scopes and tool allowlists. Coding agents support per-project permission configuration: which commands can run without approval, which paths are writable, which tools are available at all. Enterprise platforms have moved the same direction — Microsoft Foundry's agent service and Google's Gemini Enterprise platform both ship identity, governance, and observability as first-class platform features, because they know enterprises won't deploy agents without them. If your policy says "agents can't touch production," the enforcement is credentials the agent never receives — not a paragraph asking it nicely.

"Sensitive data must not leave approved systems" → gateway and connector control. The practical unit of agent risk in 2026 is the integration: MCP servers and connectors decide what an agent can read and where its output can go. An approved-connector list enforced at a gateway is executable policy. A sentence about data handling is not. This is also where you decide the confused-deputy questions — what an agent connected to both your ticketing system and the open internet is allowed to do — and those decisions belong in configuration, not prose.

"AI-generated code requires human review" → branch protection you already have. Agents open pull requests; humans approve them; the branch protection rule enforces it. If you want more nuance — say, stricter checks on changes that touch auth or payments — CI is where that lives. Hooks in the agent tooling can block specific actions at the moment they're attempted, which is worth more than any amount of after-the-fact auditing.

"AI use must be auditable" → turn on the logs you're already paying for. Enterprise AI plans now ship audit logs and compliance APIs; agent platforms log tool calls and transcripts. Auditability is mostly a matter of enabling retention and deciding who reviews what — again, configuration, not aspiration.

The unexpected benefit: executable policy can say yes

Here's what surprises people. Moving policy into configuration doesn't just tighten enforcement — it lets you loosen the prose. A PDF policy has to be conservative because it's enforced by nothing; you write "never" because you can't write "only when." Executable policy can be precise. Instead of "agents may not run destructive commands," you allowlist the safe ones and gate the rest behind approval. Instead of banning a category of tool, you approve specific connectors with specific scopes. Teams get more freedom, not less, because the guardrails are load-bearing and everyone knows it.

That precision is also what makes the policy maintainable. Configuration lives in version control. Changes get proposed, reviewed, and rolled back like any other change. Compare that to the PDF, which was last updated when someone remembered it existed.

Where to start

Don't boil the ocean. Take your current policy document and build a two-column table: the rule, and the mechanism that enforces it. Every row with an empty second column is a decision — either wire up enforcement (permission config, gateway rule, CI gate, log retention) or admit the rule is advisory and label it that way. In my experience the table has ten to fifteen rows and the wiring is a few weeks of platform work, most of it flipping switches you already own.

Then make one structural change: give the policy an owner in engineering, not just legal. Executable policy is a system, and systems need maintainers who understand both the intent and the tooling.

The takeaway

The gap between written policy and enforced policy is where AI incidents will come from — not exotic model failures, but an agent doing something a PDF said it shouldn't, through a permission nobody thought to revoke. Close the gap in the boring direction: every rule gets a mechanism, every mechanism gets version control, and the PDF gets demoted to what it always was — a summary of the real policy, which now actually runs.