Official AI tool policy

An official AI tool policy is the organization's first structured governance response to AI in the delivery pipeline. It replaces the L1 state - either nothing (everyone uses whatever they want) or a blanket ban (nobody uses anything officially) - with a written policy that specifies which AI tools are approved, under what conditions they can be used, what data handling rules apply, and what disclosure is required.

At L2 (Delegated), the policy is primarily document-based: a policy document, a list of approved tools, and a disclosure requirement in PR templates. It's not yet enforced by automation - compliance depends on developers reading and following the policy. That's a real limitation, but it's dramatically better than L1. A documented policy creates a shared reference point, gives compliant developers explicit protection, and gives the organization something concrete to show auditors.

The critical design decision in an official AI policy is scope. Too narrow (only covers code generation in IDE) and developers legitimately use AI tools that fall outside the scope without any governance. Too broad (covers any AI assistance including reading documentation) and the policy becomes unenforceable and developers ignore it entirely. The right scope is the set of AI use cases where the data handling and auditability requirements are materially different from traditional development - primarily: code generation, code review assistance, AI-driven debugging, and AI agents acting autonomously in the codebase.

The most important change of 2026 is where agent autonomy is decided. For a while the industry's answer was the permission prompt: the agent asks, a human reads it, the human decides. That answer is now empirically dead. Developers approve 97% of permission prompts. In an Anthropic study of 1,053 participants, humans caught 13.6% of dangerous commands while a classifier caught 89%. Across 40,000 runs, human approval accuracy was 66.3%, and npm run - which can execute arbitrary code from a package script - was waved through 52.5% of the time. A control that is exercised correctly two times in three, on a decision the operator has already stopped reading, is not a control.

The correct conclusion is not "let the classifier decide" either. It is that autonomy belongs in a declarative ruleset that is written down, reviewed and version-controlled like any other configuration, and evaluated before any classifier is consulted. In Claude Code the two layers are concrete: permissions.deny blocks a command outright, and neither the classifier nor a stated intent can override it; permissions.ask forces a prompt, and because an explicit ask rule counts as your stated intent, the classifier cannot auto-approve past it. Everything the ruleset does not speak to is where the classifier operates. Write the rules first, and the classifier only ever gets the residue.

This is why auto mode becoming the default on 2026-08-14 for Pro, Max and Team accounts - announced a week earlier - is not the return of YOLO mode that it was reported as. It ships with a circuit breaker at three consecutive or twenty total blocks and scored 0% success across 720 simulated prompt injections, and it remains opt-in on Claude Enterprise, the Claude API, Bedrock, Google Cloud and Microsoft Foundry. Existing user-set defaults move only through a one-time prompt, and org-managed defaults do not move at all. If your policy has anything to say here, it should say which deny and ask rules are mandatory in every repository, and who reviews changes to them.

For the tightest cases there is now a blunt instrument worth naming in policy: Claude Code's --restricted flag and CLAUDE_CODE_RESTRICTED=1, shipped in 2.1.248 on 2026-08-27, which removes command and code-execution tools and WebFetch, keeps file tools inside the working directory, refuses bypassPermissions, and ignores user, project and local settings files entirely. Version 2.1.251 the following day fixed a TOCTOU symlink swap inside the working directory after the permission check, and Grep and Glob ignoring Read() deny rules through symlinked paths - a reminder that a deny rule is only as good as the version of the tool enforcing it, so pin and patch deliberately.

A well-designed official policy does four things: it specifies approved tools with enterprise data handling agreements (not consumer-grade tools), it defines what data can be sent to AI systems (code: yes; customer PII: no; secrets: never), it requires disclosure of AI use in pull requests, and it identifies who is accountable for each tool's governance. A fifth has joined them at L2: it states the baseline autonomy ruleset - the deny and ask rules every repository inherits - along with per-session spend caps, short-lived keys, and a kill switch. Everything else is detail that can be added later.

• Creates a defensible compliance position - an organization with a documented AI tool policy, even an imperfect one, is in a fundamentally better position in a SOC2 audit than one with no policy. "Here is our policy and here is evidence we follow it" is an audit response; "we don't have a policy" is a finding
• Reduces shadow AI - approved tools with enterprise data handling agreements, made available through official procurement, give developers a better alternative to personal subscriptions. The policy legitimizes official use and delegitimizes shadow use
• Establishes the data handling baseline - specifying which data can and cannot be sent to AI systems is the most important risk control in an AI policy. This prevents the most common high-risk AI misuse: developers sending customer data or secrets to consumer AI interfaces
• Gives developers clear guidance and protection - developers who want to use AI tools appropriately need to know what's allowed. A policy gives them permission, guidance, and organizational cover. Without it, every developer makes their own risk assessment, which leads to inconsistent behavior
• The permission prompt is not a control and your auditors will eventually know it - 97% approval, 13.6% detection of dangerous commands, 66.3% accuracy over 40,000 runs; a policy that rests on the human click is resting on a number that does not support it
• Short-lived keys are now an incident-response measure, not hygiene - Unit 42's August "Token Jacking" research describes stolen AI API keys resold through gray-market proxies and used within minutes of exposure, with one incident-response case reaching roughly $1M in charges before containment
• Creates the foundation for L3 automation - policy-as-code (L3) requires a policy to automate. An organization that skips L2 and tries to jump to L3 will automate ad-hoc rules rather than a coherent policy

1. Draft a one-page policy first - resist the temptation to build a comprehensive policy from the start. Write one page: approved tools list, data classification rules, disclosure requirement, who to contact with questions. Circulate it for comment, improve it, publish it. One page that gets read is better than ten pages that don't.
2. Start the approved tools list with what developers already use - identify the AI tools with the highest existing adoption through the shadow AI census (or through developer surveys) and get enterprise agreements for those tools first. Starting with tools developers already use maximizes adoption of the official policy immediately.
3. Create the data classification section carefully - this is the highest-risk section. Work with security to define: what repository content can go to AI tools (generally: yes), what data from databases can go to AI tools (generally: no without review), whether any production access is permitted for AI tools (generally: read-only, no secrets). Get explicit sign-off from the CISO on this section.
4. Build the PR disclosure requirement into the template - update the pull request template in your repositories to include an AI disclosure section: "AI tools used (if any): [list tools and purpose]." This is your earliest form of audit trail and requires no new tooling. Make it a required field, not optional.
5. Identify a policy owner - a policy without an owner becomes stale. Assign someone (typically a security architect or engineering manager) to own the policy with a quarterly review responsibility. The policy owner's name and contact should be in the document.
6. Write the baseline deny/ask ruleset and put it in version control - deny is for things no stated intent should unlock: writes outside the working tree, credential paths, production endpoints, destructive VCS operations. Ask is for the narrower set where a human genuinely adds signal. Review changes to this file the way you review changes to production infrastructure, because that is what it is. Do not rely on the classifier for anything you can state as a rule, and do not rely on the prompt for anything at all.
7. Set per-session spend caps, short-lived keys and a kill switch at the harness level - caps enforced by the harness rather than monitored after the fact, credentials with a lifetime measured in hours rather than quarters, and one documented action that stops every agent in the organisation. Keys leaked in agent contexts are used within minutes, so rotation windows measured in months are decorative.
8. Publish the policy with a grace period - announce the policy, give developers 30 days to review it, and communicate what happens at the end of the grace period (PR template changes take effect, shadow AI use is expected to migrate to official tools). Don't enforce against developers who were using approved tools before the policy existed.

Writing a policy that prohibits more than it enables. An AI policy that says "you may not use AI tools except in the following narrow circumstances" will not be followed because it's more restrictive than what developers need. Policies that succeed describe what's allowed broadly and what's prohibited specifically, with the approved list being expansive enough to cover real use cases.

Not getting the data handling section right. The most important part of the policy is what data can go to AI systems. If this section is vague or missing, developers will make their own judgments, and some of those judgments will be wrong in ways that create real risk. "Code files from non-regulated repositories: OK; files containing secrets or tokens: never; customer data: requires security review" is the right level of specificity.

Forgetting about agentic AI. Most first-generation AI policies were written for copilot-style tools where a developer explicitly queries the AI. As teams adopt agent tools (Claude Code, Cursor with agent mode, GitHub Copilot Workspace), the policy needs explicit rules for AI systems that take autonomous actions: what actions can agents take without approval, what requires human confirmation, what is prohibited entirely.

Writing "a human must approve each action" into the policy. It reads well in a control matrix and it does not survive contact with the data: 97% of prompts are approved, and human approval accuracy across 40,000 runs was 66.3%. Worse, it displaces effort from the control that does work. If your policy names the prompt as the safeguard, replace that clause with the deny/ask ruleset and name the file it lives in.

Delegating the whole decision to the classifier instead. The opposite error, and equally wrong. The classifier is good - 89% detection against the humans' 13.6% - but it is probabilistic, and probabilistic controls are not what you want standing alone in front of your production credentials. The deny layer exists precisely so that some decisions are never delegated to a judgement call of any kind.

No exceptions process. A policy with no exceptions process will either be ignored (when the exceptions are obvious and the stakes are low) or create blockers (when legitimate use cases are excluded and there's no path to approval). Build a lightweight exceptions process: a specific person to contact, a target response time of 48 hours, and a list of what information is needed for an exception request.

Treating publication as completion. Publishing the policy is the start of governance, not the end. You need to communicate it, train developers on it, answer questions about it, and update it as tools and practices evolve. Schedule the first policy review at the time of publication, not when a problem forces your hand.