Claude Code Policy: Write Managed Settings Fast
Read More
Blog

Your Enterprise AI Policy Needs Dials, Not Switches

Author:
Eyal Ben Ezra
00 min
June 18, 2026

Most enterprise AI policies come in two flavors: block or allow. Ban the tool, or wave it through. That binary is comforting on a slide and useless in practice, because it is not how AI works, and it is not how your employees work.

A policy that only knows two settings cannot govern a workforce that has already moved. People are connecting personal AI accounts to company data, shipping vibe-coded apps, and pointing agents at their browsers and inboxes, right now, with or without your sign-off. The question is no longer whether to allow AI. It is how precisely you can say yes.

The six questions a real AI policy has to answer

Sit down to write an honest enterprise AI policy and you run into questions a toggle cannot answer:

  1. Are we okay with people using DeepSeek?
  2. Are we okay with employees connecting personal Claude accounts to our Salesforce data?
  3. Are we okay with non-technical employees publishing vibe-coded artifacts straight to production?
  4. Are we okay with an agent controlling our employees' browsers?
  5. Are we okay with agents sending emails on behalf of our people?
  6. Which actions should require human-in-the-loop approval before they fire?

Notice what these have in common. None of them is a yes or no about a vendor. Each is a question about a specific action, on specific data, by a specific person or agent, in a specific context. "Allow Claude" tells you nothing about whether Claude should be allowed to read your CRM, write to production, or send mail as your VP of Sales. Those are three different risks wearing the same logo.

Every company's answer is different

Here is the part that breaks one-size policies. The right answer to those six questions changes with who is asking.

A fintech under regulatory supervision needs tighter controls on customer data than a real estate firm. An energy company with critical infrastructure has a different risk surface than a software startup shipping daily. A hospital answering to patient-privacy rules cannot run the same playbook as a marketing agency. Same tools, same questions, completely different answers. And regulators are closing the gap fast, with regimes like the EU AI Act landing real obligations on high-risk use in 2026.

So every company has to build its own policy. Not download a template, not copy a competitor, not pick "block" or "allow" and hope. The policy has to reflect your data, your industry, your risk tolerance, and your appetite for speed. That is a lot of dials to set. The problem is that most AI security tools only ship switches.

Why toggle switches fail

A switch can block a tool or permit it. It cannot say "marketing can use this model for copy but never on customer records," or "engineers can let an agent open a pull request but a human approves the merge," or "anyone can spin up an internal app but publishing to production needs review." The real world lives in those conditions. Switches flatten them into on or off, and the moment the policy is too blunt, one of two things happens. Security blocks everything and employees route around it on personal devices, taking your visibility to zero. Or security allows everything and you are one prompt injection away from an agent doing real damage with real credentials.

Block and allow are not a policy. They are the absence of one.

Control dials, not toggle switches

This is exactly why we are building Willow. We give companies control dials, not toggle switches, for every AI agent, tool, MCP, and skill in the enterprise.

A dial sets policy at the level the question actually lives: the action, the data, the identity, and the context. With Willow, every agent gets a real identity tied to a human, scoped to exactly the tools and data its task requires, with guardrails enforced at runtime and a full audit trail behind it. You decide that DeepSeek is fine for general research but never touches regulated data. You let an agent draft emails but require human-in-the-loop approval before it sends as someone. You allow vibe-coded apps in a sandbox and gate the path to production. One control plane, set once, enforced everywhere, instead of seven point tools each guarding a slice.

That is the difference between governing AI and reacting to it. Toggles tell you what you forbade. Dials let you express what you actually want.

The point of dials is a faster yes

Precision is not about saying no more often. It is about being able to say yes safely, which is the only kind of yes that scales. When the policy can be specific, security stops being the team that blocks and becomes the team that enables.

We see it in production. At Wix, Willow governs around 600 tools and MCPs across roughly 5,000 weekly active users, more people than the entire engineering org, processing over 300,000 governed tool calls a week across HR, legal, finance, design, and R&D. That is not a pilot with three approved apps. That is a whole company using AI freely because the policy is granular enough to let them, and tight enough that security can sleep. Innovid and Riskified run the same way.

Block or allow was always a false choice. The companies pulling ahead in 2026 are not the ones saying no fastest. They are the ones who can say a precise, governed yes, and tune it as the tools and the rules keep changing. That takes dials. Build your AI policy on something that has them.

Everything you need to get your Basecamp running.

Blog

What's happening on the AI agent frontier.

Documentation

Get up and running fast.

Rollout playbook

How to deploy across your org without chaos.

Your agents are already in the wild.

Give them a Basecamp. Go from AI chaos to AI work, in minutes.