Official AI tool policy

Three governance items now belong in any L2+ policy:

1. Per-session spend caps + kill switches. The community documented multiple "agentic fork bomb" incidents in April, including a $3,800 overnight bill from a runaway subagent loop. Caps must be enforced at the harness level, not just monitored.
2. Capability-restricted licensing as a permitted vendor pattern. Claude Mythos Preview (Apr 7, 93.9% SWE-bench Verified) is restricted under "Project Glasswing" to defensive cybersecurity workloads only. Expect this licensing model to spread to other high-capability releases. Your policy needs language for it.
3. Bad-day protocol. Anthropic's April 23 postmortem confirmed that harness/system-prompt changes silently degrade vendor models. Policy should require: documented rollback path, telemetry threshold for "switch to backup model", and a vendor-postmortem subscription.

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 (Guided), 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.

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. 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
• 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. 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.

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.