Shadow AI policy template

Why do most AI policies fail?

An AI acceptable use policy fails when it bans more than it approves, or when nothing enforces what it says. A policy that says "don't use generative AI with company data" leaves the problem the person had when they opened ChatGPT. They still have to summarize the contract or fix the failing test, so they paste it into a personal account on the same laptop. The use doesn't stop. It moves somewhere your logs, your contract, and your admin console can't reach. Arcjet's guide to stopping users sending PII to an LLM describes the same failure in an application, and the shadow AI pillar sets out the responses that start from the demand instead of the tool.

Many published AI policy templates are prose that no control backs. A clause such as "employees must use company accounts" has no setting behind it, so nobody can tell whether it holds, and an auditor can't test it. The template on this page is written the other way round. Each enforceable clause names something that you can configure, and the mapping table names the control options and the record that shows whether the clause held.

This template isn't legal advice, so have your legal and HR teams review it before you adopt it.

How do you fill in the template?

Copy the template into your policy system and replace the following placeholders:

• COMPANY_NAME: your organization's name.
• POLICY_OWNER: the role accountable for the policy, such as the chief information security officer.
• AI_REVIEW_OWNER: the team that approves AI tools and MCP servers.
• APPROVED_TOOLS_PAGE: the internal page that lists approved tools.
• REQUEST_CHANNEL: where people request a tool, server, or exception, such as a form or a ticket queue.
• DECISION_DAYS: the business days within which a request gets a decision.
• SECURITY_CONTACT: where people report incidents.
• REPORT_HOURS: the number of hours after discovery within which people report an incident.
• RETENTION_DAYS: how long monitoring records are kept.
• EXCEPTION_MAX_DAYS: the longest an exception can last before renewal.
• REVIEW_MONTHS: how often the policy is reviewed.
• DATA_CLASSIFICATION_POLICY and DISCIPLINARY_POLICY: links to the policies that this one depends on.

Italic notes inside the template are for the policy owner. Delete them before you publish.

The shadow AI policy template

1. Purpose and scope

This policy sets how people at COMPANY_NAME use AI tools for company work. Its purpose is to give everyone approved AI tools that fit their work, and to keep company data inside accounts that COMPANY_NAME controls and can audit. It doesn't ban AI.

The policy applies to employees, contractors, interns, and anyone else with a company account or a managed device. It covers AI tools in every form: chat in a browser, desktop apps, IDE extensions, command-line tools, coding agents, MCP servers, browser extensions, AI features inside software the company already uses, and models that run locally. It applies on any device used for company work.

2. Definitions

3. Approved tools and requests

Use only approved AI tools for company work. For each tool, APPROVED_TOOLS_PAGE lists the approved surfaces, such as web, desktop, or CLI, the highest data class it may receive, and its owner.

To request a tool, an MCP server, a model, or more capacity on an approved tool, submit a request at REQUEST_CHANNEL with the use case, the data classes involved, and who would use it. AI_REVIEW_OWNER decides within DECISION_DAYS business days. The decision is approve, approve with conditions, or decline with an approved alternative named. A request that needs a new contract can take longer, and the requester hears that within the same deadline. A request with no decision by the deadline isn't approved, and the requester can escalate to POLICY_OWNER.

When a vendor of approved software adds an AI feature, the owner of that software reviews the feature's admin settings before anyone enables it.

4. Accounts

Use approved AI tools only through a company account. Don't use a personal account for company work, including a personal account with the vendor of an approved tool. Don't use personal API keys for company work, and don't expense personal AI subscriptions.

If you reach a usage limit on a company account, request more capacity at REQUEST_CHANNEL instead of switching accounts. Don't share company accounts, and don't sign in to a company account on a personal device unless DATA_CLASSIFICATION_POLICY allows that device for the data involved.

5. Data classes

The following table sets which tools may receive each data class. If a tool's listing doesn't name a data class, the tool may not receive it.

Credentials, such as passwords, API keys, tokens, and private keys, may not go into any AI tool, prompt, or MCP server configuration in plain text, whatever the tool's approval.

6. Coding agents and MCP servers

Use only approved coding agents, signed in with a company account. Device management installs managed settings and hooks for each approved agent. Don't remove, override, or work around them, and don't run an agent with a configuration that skips them.

Connect agents only to MCP servers on the approved list. This includes servers in a repository's committed configuration. Store MCP server credentials in an approved secret store or environment variable, not in the configuration file. Use only the models that the approved list names for each agent.

Agents don't receive production credentials unless an approval names the agent, the credential, and the task. Modes that skip per-action approval run only in a disposable environment that holds no credentials beyond the task's own.

You're responsible for what an agent does on your behalf, as if you had typed it. Agent-written changes go through the same code review as your own.

7. Prohibited uses

The following uses are prohibited, whatever the tool:

• Entering data into a tool that isn't approved for its class.
• Using AI output as the sole basis for a decision about a person, such as hiring, performance, or access to a service, without review by a qualified person.
• Publishing AI output to customers, or using it in a contract or legal statement, without review by its human owner.
• Installing an AI browser extension that can read every site you visit, unless the extension is approved.
• Exposing a local model server to a network.
• Getting around a control in this policy, for example with a second browser profile, a personal hotspot, a VPN, or a renamed binary.

8. Monitoring

Note for the policy owner: keep only the statements that are true for the controls that you run. If you run a TLS-inspecting proxy or browser DLP that reads prompt content, say so in the first list.

COMPANY_NAME collects the following records about AI use on managed devices and company accounts:

• Which AI services a managed device connects to, which app made the connection, the time, and the person mapped to the device account.
• For approved coding agents, the tool calls that the agent makes, their arguments, the prompts sent through the agent, and whether policy allowed each one.
• Activity logs that vendors provide for company accounts, which can include conversation content.
• Refused sign-ins to personal accounts on the company network.

COMPANY_NAME doesn't collect the following:

• The content of prompts that you type into AI tools in a browser tab.
• Keystrokes or screen recordings.
• Anything from personal devices that aren't enrolled in device management.

SECURITY_CONTACT reviews these records for security and for compliance with this policy, and keeps them for RETENTION_DAYS days. The records aren't used to measure productivity.

9. Exceptions

Request an exception at REQUEST_CHANNEL. AI_REVIEW_OWNER and the owner of the data involved approve it in writing, with an end date no more than EXCEPTION_MAX_DAYS days away and any compensating control. Exceptions are recorded in a register and expire on their end date unless renewed.

10. Incident reporting

Report to SECURITY_CONTACT within REPORT_HOURS hours if any of the following happens:

• You entered data into a tool not approved for its class.
• An agent deleted, pushed, sent, or contacted something you didn't intend.
• An MCP server or tool asked for credentials unexpectedly.
• You suspect that an AI tool account was compromised.

Reporting your own mistake within that window isn't by itself a disciplinary matter. Security then rotates exposed credentials and asks the vendor to delete data where the contract allows.

11. Review

POLICY_OWNER reviews this policy every REVIEW_MONTHS months, and also after an AI incident, a change to the approved tools that alters a data class rule, or a new legal requirement. AI_REVIEW_OWNER keeps APPROVED_TOOLS_PAGE current between reviews.

12. Ownership

POLICY_OWNER owns this policy. AI_REVIEW_OWNER owns approvals and the approved tools list. IT and security operate the controls. Legal and HR review each version. Violations are handled under DISCIPLINARY_POLICY, in proportion to the data and intent involved.

How does each clause map to a control and evidence?

The following table pairs each enforceable clause with control options and the record that shows whether it held. Generic controls come first in each row, then the vendor setting, then where Arcjet provides one. Vendor settings were reviewed on November 3, 2026.

Read the evidence column as three different kinds of proof. An endpoint connection shows that an app on a device reached a provider, but not which account it used or whether it sent a prompt. A hook event shows what an approved agent ran and what the policy decided. A Compliance API record shows that a company account had a session. A hook event near a connection isn't proof that they were the same request, so keep each source as its own field. For how the three apply to coding agents, see shadow AI coding agents. For each tenant control in detail, see block personal AI accounts on work laptops.

How do you adapt the template?

The template fits a company of a few hundred people with device management and a security team. The following sections describe what to change for three other shapes.

A small startup

At 30 people on Google Workspace with no proxy, cut the template to a page. Collapse the data classes to two: customer data, which goes only to tools approved by name, and everything else. Keep the credentials rule from sections 5 and 6 as written, because plaintext credentials don't go into any AI tool, approved or not. Set DECISION_DAYS to two and make the CTO AI_REVIEW_OWNER. Without a TLS-inspecting proxy, tenant headers aren't available, so enforce the accounts clause on the device with Cursor AllowedTeamId, Claude Code forceLoginOrgUUID, and the Codex workspace pin through your MDM. Your evidence is OAuth grants and the expense report, which you already have. Keep the monitoring section short and accurate, even if it says that you collect little.

A regulated company

In financial services or healthcare, map the four data classes onto your existing classification instead of adding a new one, and make the vendor contract part of approval: data processing terms, retention, training exclusion, and region. If you handle health data in the US, ask legal whether a tool needs a business associate agreement before it can receive Restricted data. Require a second approver from the data owner for every Restricted exception, and set RETENTION_DAYS to match your audit evidence requirements. Have HR and legal confirm whether your monitoring needs notice or consultation in each country where you employ people. Auditors ask for the evidence column, so test that each source produces a record before you rely on it.

An engineering-heavy organization

When most staff write code, the coding agents and MCP servers section carries the policy. Split the approved MCP list by environment, so that a read-only documentation server is fine on every laptop and a server that holds production credentials isn't. Treat a committed .mcp.json as a request that goes through approval. Agents in CI run under service accounts with their own scoped credentials and appear in the approved list like a person's tool would. Start every hook policy in dry run, and give each team a sandbox exception path so that experiments with new agents happen inside the policy.

How do you roll out the policy without driving use underground?

Publish the approved tools list and the request channel before any restriction takes effect. People who can see a sanctioned path with a known deadline use it. People who meet a block first look for a way around it. Explain each restriction in terms of the data it protects, and make every block page link to the approved alternative.

Then run an amnesty and inventory period of about 30 days. Ask people to declare the AI tools, accounts, and MCP servers they use, with no penalty for anything declared in that window. At the same time, run the one-week shadow AI discovery so that the declarations and the detected use can be compared. Each finding becomes an approval, a move to a company account, or a decision to block.

Enforce in stages. Publish hook policies in dry run and read what they would have denied before you set them live. Apply tenant controls once company accounts have capacity for everyone who needs one. Start endpoint provider blocks with a pilot device group before the whole fleet.

Measure the outcome, not the block count. Track the share of AI connections that go to approved providers, refused personal sign-ins per week, the median time from request to decision against DECISION_DAYS, sessions in vendor audit feeds that have no hook decisions, and exceptions past their end date. Read the block count against approved use: when blocks rise and approved use stays flat, the blocked work has moved to a path that you don't see yet, so add capacity to the approved tool or shorten the approval time before you add blocks.

Where does Arcjet fit?

Arcjet supplies controls and evidence for several rows of the mapping table. The Arcjet endpoint agent for macOS and Windows, deployed through your MDM, including Jamf, records each connection from a managed device to an AI service with the signed app and the person behind the local account, and endpoint provider policies set Allow or Block per provider for a group of devices. It doesn't decrypt TLS or read prompts. Arcjet hooks enforce one policy across Claude Code, GitHub Copilot, Cursor, OpenAI Codex, and Muse Code, with starter policies for MCP, model, and egress allowlists, credential access, and sensitive information. The Claude Compliance API and OpenTelemetry ingest record without enforcing.

Arcjet doesn't cover the whole policy. A hostname can't separate a personal account from a company account, so the accounts clause needs vendor tenant controls. Prompt content in browser tabs needs browser DLP, a local model with no network traffic isn't a connection, devices without the agent are out of scope, and a connection from an AI app can be an update check rather than a request. The policy text, training, and HR process are yours. For endpoint agent pricing and availability, book a demo.