Shadow AI Policy Template: Discovering, Approving and Managing Unsanctioned AI

An acceptable use policy tells staff which AI they may use, but it does not say what the organisation does when it finds AI that nobody approved. That gap matters: in IBM's 2025 Cost of a Data Breach research, one in five organisations reported a breach due to shadow AI, and among organisations with AI governance policies only 34% performed regular audits for unsanctioned AI. This template covers how unsanctioned AI tools, features, agents, MCP servers and integrations are discovered, triaged, approved, contained or retired, and how people are encouraged to declare what they use. It is written for CISOs, IT, risk and AI governance leads, and is designed to sit alongside the AI Acceptable Use Policy Template rather than repeat it.

How to use this template

• Replace text in square brackets, such as [Organisation], [AI governance group] and [X days], with your own terms and values.
• "Must" indicates a mandatory requirement; "should" indicates a recommended practice where a justified exception may apply.
• Keep the rules about what staff may do with AI in your acceptable use policy. This policy governs how the organisation finds and handles AI use that falls outside those rules or outside the approved list.
• Agree the triage tiers in section 4.3 with privacy, legal and procurement before adoption.
• Have legal, HR and, where required, employee representatives review the monitoring provisions.
• Review the policy at least every [12] months; AI products, features and regulation change quickly.

1. Purpose

This policy sets out how [Organisation] discovers, assesses, approves, contains and retires artificial intelligence (AI) tools, features, models, agents and integrations that are used for [Organisation] business without approval ("shadow AI"). Its aims are to:

• Maintain an accurate register of the AI used to process [Organisation] data or act on its behalf.
• Bring useful AI into a governed, approved state quickly rather than driving its use out of sight.
• Remove or contain AI that creates unacceptable risk to [Organisation] data, systems, customers or legal obligations.
• Support [Organisation]'s obligations under data protection law, the EU AI Act where it applies (including the Article 4 AI literacy duty on providers and deployers), client contracts and [other applicable requirements].

2. Scope

This policy applies to all employees, contractors, temporary staff and third parties who use [Organisation] data, systems, devices or accounts. It covers any AI used for [Organisation] business, whether paid for, free, trial or personal, including:

• Public and consumer generative AI services (chat assistants, image, audio and video generators, translators, summarisers, transcription and meeting bots).
• AI features embedded in software and SaaS services that [Organisation] already uses, including features enabled by a vendor after the original approval.
• Third-party AI applications granted access to [Organisation] accounts or data through OAuth, API keys, browser extensions or add-ins.
• AI agents, coding assistants and automation that act on systems, including low-code and no-code agent platforms.
• Model Context Protocol (MCP) servers, plugins, connectors, skills and tools used by AI agents, whether run locally or remotely.
• AI models, model files and AI provider API keys obtained or created outside approved channels.

AI systems developed or procured through [Organisation]'s approved project and procurement processes are governed by [AI governance policy] and [AI agent security policy]. They fall under this policy only when they are used outside their approved scope.

3. Roles and responsibilities

4. Policy statements

4.1 Approved AI and the AI register

1. [Organisation] must publish an approved AI list, stating for each tool the permitted data classifications, permitted uses and how to get access. The list must be available to all staff at [location].
2. [AI governance group] must maintain an AI register recording, for every approved and discovered AI tool, agent or integration: name, vendor, owner, business purpose, users, data classifications processed, integrations and credentials, risk tier, status (approved, conditional, contained, blocked, retired) and review date.
3. Where an approved enterprise version of a tool exists, staff must use it instead of a consumer or personal version.

4.2 Discovery

1. [Security team] must operate continuous discovery of AI use, using at least: [CASB or SSE] cloud discovery, identity provider records of OAuth grants and sign-ins to third-party apps, browser extension inventories, endpoint software and configuration inventories, and [expense and procurement records].
2. Discovery on developer and power-user endpoints must include AI agents, coding assistants and MCP server configuration files, such as .mcp.json, .vscode/mcp.json and [tool-specific paths].
3. Source code repositories and endpoints must be scanned for AI provider API keys and tokens.
4. Discovery results must be reconciled against the AI register at least every [month]. Any AI found that is not in the register must be recorded as "discovered" and triaged under 4.3 within [10] working days.
5. Monitoring under this section must be proportionate, documented in [monitoring notice] and carried out in line with [employee monitoring policy] and applicable law.

4.3 Triage and risk tiers

1. Each discovered AI tool must be assigned a risk tier based on the data it can reach, its access method and the vendor's terms:
   • Tier 1 (low): no [Organisation] data beyond public information, no account integration, business terms with no training on inputs.
   • Tier 2 (medium): internal data, or read-only OAuth scopes, or a recognised vendor with acceptable terms.
   • Tier 3 (high): confidential, regulated or personal data; write or broad OAuth scopes such as full mail or file access; agents or MCP servers that execute code or take actions; unknown vendor or terms that allow training on inputs.
2. Tier 3 tools must be contained under 4.6 within [2] working days of discovery, pending a decision.
3. Triage must identify whether [Organisation] data may already have been exposed. If so, the matter must be handled under [incident response procedure] and the [Data Protection Officer] informed.

4.4 Declaration and fast-track approval

1. Staff must declare any AI they use for [Organisation] business that is not on the approved list through [request form or service catalogue item].
2. [Organisation] must operate a fast-track review for declared tools, targeting a decision within [5] working days for Tier 1 and [15] working days for Tier 2. Tier 3 tools follow [AI procurement process].
3. The review must cover at least: data use for model training, retention and deletion, data location and sub-processors, SSO and SCIM support, audit logging, and features that act on systems.
4. Staff who declare AI use in good faith, including during a declared amnesty period, must not face disciplinary action for that past use, unless it involved deliberate misuse or concealment.

4.5 Accounts, credentials and integrations

1. Approved AI services must be accessed with [Organisation] accounts through single sign-on where the service supports it. Personal AI accounts must not be used for [Organisation] business.
2. Users must not grant third-party AI applications OAuth access to [Organisation] mail, files, calendars or other data beyond [low-impact permissions] without approval through [admin consent workflow].
3. AI provider API keys must be issued by [team], stored in [approved secrets manager], scoped to a named owner and purpose, and must not be placed in source code, notebooks, prompts or configuration files.
4. Existing OAuth grants and API keys for AI services must be reviewed at least every [quarter], and grants for tools that are not approved must be revoked.

4.6 Containment and blocking

1. [Security team] may contain an unapproved AI tool by: marking it unsanctioned in [CASB], applying warn or block controls, restricting uploads, revoking OAuth grants and API keys, removing browser extensions, or removing MCP server configurations.
2. Blocking should be accompanied by a message that tells users the approved alternative and how to request review.
3. AI tools that are known to be malicious, that have been compromised, or that are prohibited by [Organisation] or by law must be blocked immediately on all managed devices and networks.
4. [Organisation] must not block critical approved services as a side effect; blocking rules must be tested in [audit or monitor mode] before enforcement.

4.7 AI agents and MCP servers

1. AI agents and coding assistants may connect only to MCP servers, plugins and tools on [approved MCP list], enforced through [managed configuration or MCP registry] where the tool supports it.
2. Remote MCP servers must require authorisation. Local MCP servers must come from [approved source] and must not be started from configuration files in untrusted repositories.
3. Agents must not run with an individual's broad personal credentials or with production administrator credentials. Agents with access to [Organisation] systems must be registered under [AI agent security policy].

4.8 Embedded AI features in approved services

1. Service owners must check for new AI features in approved software and SaaS services at least every [quarter], and when a vendor announces new AI functionality or changes its AI terms.
2. New AI features that send [Organisation] data to a new sub-processor or model provider, or that can take actions, must be disabled until reviewed under 4.4.

4.9 Retirement

1. When an AI tool is retired, blocked or loses its owner, [IAM team] must revoke its OAuth grants, API keys and service accounts, and the owner must request deletion of [Organisation] data from the vendor where the contract allows.
2. Ownership of approved AI tools must be transferred within [30] days when the owner leaves or changes role, or the tool must be suspended.

4.10 Training and awareness

1. All staff must complete AI awareness training covering the approved list, data handling, and how to declare tools, at induction and every [12] months.

5. Exceptions

Exceptions must be requested by the tool owner through [exception process], risk assessed by [Security team] and [privacy team], and approved by [approver at the appropriate level for the risk tier]. Each exception must record the compensating controls, the data classifications permitted and an expiry date of no more than [6] months. Expired exceptions must be renewed or the tool contained under 4.6. Exceptions cannot be granted for tools that are known to be malicious or prohibited by law.

6. Compliance and monitoring

1. [Security team] must report the following measures to [AI governance group] every [month]: number of AI tools discovered and their status; median time from discovery to decision; number of active OAuth grants to unapproved AI apps; number of AI provider keys found in code or files; share of AI use, by users or traffic, going to approved tools; and number of incidents involving shadow AI.
2. Internal audit should review compliance with this policy every [12 to 24] months, including a sample of register entries against discovery data.
3. Repeated or deliberate use of blocked or prohibited AI, or deliberate concealment of AI use, may be handled under [disciplinary procedure].

7. Review and approval

Implementation guidance

The policy only works if the approved route is faster and better than the shadow route. Roll it out in this order:

1. Publish the approved list and the request route first. Before any blocking, make sure people have a sanctioned enterprise assistant and a working declaration form.
2. Baseline in monitor mode. Turn on cloud discovery and export OAuth grants for 30 days without blocking. In Microsoft Defender for Cloud Apps, marking an app unsanctioned does not block it by itself; blocking happens through integrations such as Defender for Endpoint with Network Protection, which also supports warn-and-educate.
3. Run an amnesty. Announce a fixed declaration window under 4.4, with a clear promise of no disciplinary action for past good-faith use.
4. Close OAuth consent. In Microsoft Entra, set user consent to "Allow user consent for apps from verified publishers, for selected permissions" and enable the admin consent workflow. In Google Workspace, move unconfigured third-party apps away from "Allow users to access any third-party apps" and set access to "Trusted", "Limited", "Specific Google data" or "Blocked" per app. Existing grants are not removed by these settings, so review them separately.
5. Control agents and MCP on developer endpoints. For example, GitHub Copilot offers an "MCP servers in Copilot" policy with an MCP Registry URL and a "Restrict MCP access to registry servers" setting of "Registry only"; Claude Code supports a managed-mcp.json file and managed allowedMcpServers and deniedMcpServers lists. See the Unsanctioned AI Agents and MCP Servers Guide.
6. Enforce in rings. Move Tier 3 tools to warn, then block, starting with one business unit. Roll back by reverting the app tag or policy if an approved workflow breaks, and record the cause.
7. Report and tune. Track the measures in section 6 monthly.

Mapping to frameworks

For the threats behind each section, see the Top 10 Shadow AI Risks; for discovery techniques, see the Shadow AI Discovery Guide.

Related NHI Mgmt Group resources: AI Acceptable Use Policy Template · Shadow AI Discovery Guide · Agentic AI Security Policy Template · AI Register and AI Inventory Template · SaaS and OAuth App Governance Guide