# Shadow AI tooling: enterprise AI policy pack Let people use AI tools that are sanctioned and reached through the approved tenant, gateway or proxy, while stopping company data from leaving through unmanaged AI accounts and stopping unreviewed extensions, connectors, models and skills from entering the environment. Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values. ## Control scope - Protected assets: Source code, customer and employee records, credentials, confidential documents, agent configuration and the model and skill artifacts agents run - Consequential actions: Paste and upload to unmanaged accounts, extension install, assistant sign-in, connector registration, model and skill load, vendor AI enablement and app consent - Applicable systems: Consumer and enterprise AI assistants, browsers, IDEs and coding agents, MCP servers, public model and skill hubs, SaaS AI features and identity providers - Context to resolve: Resolve the authenticated tenant, publisher and version, requested permissions and scopes, data classification at egress, route (gateway, proxy, direct) and the inventory entry an action maps to. - Enforcement boundary: Tenant restrictions, identity-provider consent policy, browser and editor management policies, gateway registry and artifact-proxy egress rules are the hard boundary. Agent, CLI and MCP interception adds the intent-aware decision and the record. ## Owners AI platform owner + data protection owner + endpoint security ## Configure first - Sanctioned AI tool inventory: providers, enterprise tenants, approved extensions, registered MCP servers and the internal model and skill catalogue - Discovery sources: browser management, cloud app discovery, identity-provider consent logs, network egress and endpoint DLP - AI tool intake process with named reviewers, pilot rules, expiry dates and the gateway and artifact-proxy routes every sanctioned tool must use ## Shared decision baseline ### Resolve the real target Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority. ### Fail closed on consequential ambiguity If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk. ### Bind approval to the exact action An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action. ### Keep an evidence-grade decision record Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity. ## Policies ### SA-01: Block work data in personal and unmanaged AI accounts - Severity: Critical - Decision: Block - Owner: Data protection owner + AI platform owner #### Policy statement Deny pasting, uploading or synchronising company source code, customer records, credentials or confidential documents into an AI assistant account that is outside the organisation’s tenant, contract and data-processing agreement. A consumer subscription used for work is unmanaged regardless of who pays for it. #### Covered operations - Paste or type confidential content into a consumer chatbot session - Upload files, screenshots or repositories to a personal AI account - Connect a personal AI account to company mail, drive, calendar or chat - Route API traffic to an AI provider using a personal or unmanaged API key #### Evaluation rules - Resolve the destination tenant from the authenticated account, not the vendor domain: the same provider can be sanctioned under the enterprise tenant and unmanaged under a personal login. - Classify the content at the point of egress (clipboard, upload, connector sync, outbound API) using the data classification of its source, not the user’s description of it. - Block when classification is confidential or higher and the destination account is not in the sanctioned tenant list; hold when the classification cannot be resolved. - Treat an API key that is not issued from the organisation’s provider organisation as a personal key and block outbound calls that carry protected data. #### Example decisions (illustrative; do not run against live systems) - **Browser:** `Paste a customer export into a consumer chatbot logged in with a personal email`. Block and point the user to the sanctioned tenant. - **Desktop AI app:** `Connect a personal AI account to the company Google Drive`. Block the OAuth grant at the identity provider. - **Terminal:** `Call a model API with a key that is not from the company organisation while a repository is in context`. Block when the request body contains protected content. #### Applicable tools and systems - ChatGPT - Claude - Gemini - Microsoft Copilot - Perplexity - Browser - Desktop AI apps - Provider APIs #### Enforcement Combine tenant-restriction headers and identity-provider consent controls with endpoint and browser DLP for paste and upload. Intercept agent, CLI and MCP egress for content-aware decisions; the sanctioned tenant and the DLP boundary are the final controls. #### Exception / approval No self-service exception. A team that needs a provider not yet sanctioned requests it through the AI tool intake process, which onboards an enterprise tenant rather than approving personal use. #### Test fixtures - Should remain permitted: Paste the same content into the sanctioned enterprise tenant of the same provider, or use a personal account for content classified as public. - Should be blocked or held: Upload a confidential file to a personal account, grant a personal AI app access to company drive, or split a protected document across several pastes. #### Implementation references - [OWASP · LLM02:2025 Sensitive Information Disclosure](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) - [Microsoft Purview · Data security for AI](https://learn.microsoft.com/en-us/purview/ai-microsoft-purview) - [Microsoft Entra · Configure user consent to applications](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent) ### SA-02: Review browser extensions with AI features that read page content - Severity: High - Decision: Require approval - Owner: Endpoint security owner #### Policy statement Hold installation or permission expansion of any browser extension that sends page content, form input or clipboard data to a model or third-party service until the publisher, permissions and data flow have been reviewed and the extension is on the managed allowlist. #### Covered operations - Install an extension requesting host access to all sites or to company SaaS domains - Grant an existing extension new permissions after an update - Enable an AI writing, summarising or recording feature inside a sanctioned extension - Side-load an unpacked extension outside the managed store #### Evaluation rules - Resolve the extension by store ID and version, its publisher, its requested host and API permissions, and the endpoints it sends data to. - Hold when host permissions include company SaaS, mail or source-control domains and the extension is not on the allowlist for that permission set. - Treat a permission increase on update as a new install; the previous approval does not carry over. - Block side-loaded or developer-mode extensions on managed devices outside an approved engineering exception. #### Example decisions (illustrative; do not run against live systems) - **Chrome:** `Install a meeting-summary extension requesting access to all sites`. Hold for security review and allowlisting. - **Edge:** `Extension update adds clipboard read and a new remote endpoint`. Hold the update as a new permission set. #### Applicable tools and systems - Chrome - Microsoft Edge - Firefox - Safari - Browser management (Chrome Enterprise, Intune, Jamf) - Endpoint DLP #### Enforcement Use browser management policies (install allowlist and blocklist, blocked permissions, forced installs) delivered through device management. The AI gateway records which sanctioned extensions may reach which model endpoints; the browser policy is the hard boundary. #### Exception / approval A time-boxed pilot on a named device group with the extension’s data flow documented; the allowlist entry expires with the pilot unless renewed. #### Test fixtures - Should remain permitted: Install an allowlisted extension whose permission set matches the approved version. - Should be blocked or held: Install an unlisted AI extension with broad host access, accept a permission-expanding update, or side-load the same extension from a folder. #### Implementation references - [Chrome Enterprise · ExtensionInstallAllowlist policy](https://chromeenterprise.google/policies/#ExtensionInstallAllowlist) - [OWASP · LLM02:2025 Sensitive Information Disclosure](https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/) - [Microsoft Defender for Cloud Apps · Shadow IT discovery](https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps) ### SA-03: Require approval for AI coding assistants and IDE extensions from public registries - Severity: High - Decision: Require approval - Owner: Developer platform owner + application security #### Policy statement Hold installation of any coding assistant, agent or IDE extension pulled from a public registry until its publisher is verified, its version is pinned and its permissions (workspace access, shell execution, network egress) are reviewed. Sanctioned assistants run under the organisation’s tenant with content exclusions configured. #### Covered operations - Install an IDE extension or agent plugin from a public registry - Enable auto-update for an extension with shell or network access - Sign into a coding assistant with a personal account inside a company workspace - Add an agent instruction file or rules file that grants tools or turns off approvals #### Evaluation rules - Resolve the registry, publisher identity, extension ID, version and declared capabilities; an unverified publisher or a name that mimics a sanctioned extension is held. - Hold when the extension can execute shell commands, read the whole workspace or reach network endpoints and is not on the pinned allowlist. - Require the assistant to be signed in under the organisation’s tenant; hold sessions authenticated with a personal account while a company repository is open. - Treat rules, settings or instruction files that disable permission prompts or expand tool access as a policy change requiring the same review as the extension itself. #### Example decisions (illustrative; do not run against live systems) - **VS Code:** `Install a coding assistant from a look-alike publisher on Open VSX`. Hold; publisher is not verified and the ID is not on the allowlist. - **Cursor:** `Sign in with a personal account in the company monorepo`. Hold until the session uses the enterprise tenant. - **Claude Code:** `Commit a settings file that allows every shell command without prompting`. Hold for developer platform review. #### Applicable tools and systems - VS Code - Cursor - JetBrains IDEs - GitHub Copilot - Claude Code - Codex - Open VSX / VS Code Marketplace - JetBrains Marketplace #### Enforcement Use editor enterprise policies (allowed extensions, allowed publishers, pinned versions) delivered by device management, and configure assistant content exclusions for sensitive paths. The control plane records the assistant, version and tenant behind each action; the editor policy is the hard boundary. #### Exception / approval An engineering exception names the extension ID, version and device group, and expires within 30 days unless the extension is promoted to the allowlist. #### Test fixtures - Should remain permitted: Install a pinned, allowlisted assistant under the enterprise tenant and use it with content exclusions in place. - Should be blocked or held: Install an unlisted extension with shell access, sign in with a personal account in a company repository, or disable permission prompts through a committed settings file. #### Implementation references - [VS Code · Enterprise support and allowed extensions](https://code.visualstudio.com/docs/setup/enterprise) - [VS Code · Extension runtime security](https://code.visualstudio.com/docs/configure/extensions/extension-runtime-security) - [GitHub Copilot · Content exclusion](https://docs.github.com/en/copilot/how-tos/configure-content-exclusion/exclude-content-from-copilot) - [Claude Code · Settings and permissions](https://docs.claude.com/en/docs/claude-code/settings) ### SA-04: Block unsanctioned MCP servers and agent connectors - Severity: Critical - Decision: Block - Owner: AI platform owner + security operations #### Policy statement Deny agents from connecting to an MCP server, plugin or connector that is not registered with the organisation’s gateway, and deny edits to agent configuration that add a direct server URL, command or credential bypassing that gateway. Sanctioned servers are reached through one endpoint with per-user credentials. #### Covered operations - Add an MCP server entry to a user, project or IDE configuration file - Launch a local MCP server from a package fetched at runtime - Connect an agent to a remote MCP endpoint with a shared or embedded credential - Install a connector or plugin that exposes company systems as agent tools #### Evaluation rules - Resolve the server by its endpoint or launch command, its package and version, the tools it exposes and the credential it uses; an entry that cannot be matched to the gateway registry is unsanctioned. - Block configuration changes that introduce a direct server URL or command for a system the gateway already fronts, including changes made by the agent itself. - Block connectors whose tool descriptions or responses contain instructions to the model (tool poisoning) and quarantine the server pending review. - Deny shared, long-lived or embedded credentials in connector configuration; the gateway fetches a per-user credential at call time. #### Example decisions (illustrative; do not run against live systems) - **Claude Code:** `Add a third-party database MCP server with an embedded connection string to the project config`. Block; the database is fronted by the gateway. - **Cursor:** `Agent edits its own MCP configuration to add a server it found in a README`. Block the self-modification and record the attempt. - **Terminal:** `Run an MCP server from an unpinned package pulled at startup`. Block until the package is registered and pinned. #### Applicable tools and systems - Claude Code - Cursor - VS Code - Codex - Windsurf - MCP servers - Custom agents - Tracelet MCP gateway #### Enforcement Publish sanctioned servers through the MCP gateway with policy checks, roles and per-user credentials from the secret store. Protect agent configuration files with endpoint policy and repository rules; the gateway registry and network egress controls are the hard boundary. #### Exception / approval Registering a new server through the gateway intake: publisher, version, exposed tools and credential model reviewed, then published to named roles. No exception for direct connections. #### Test fixtures - Should remain permitted: Connect to a registered server through the gateway endpoint and call a tool the caller’s role permits. - Should be blocked or held: Add a direct server entry for a gateway-fronted system, launch an unregistered local server, or let the agent modify its own connector configuration. #### Implementation references - [Model Context Protocol · Security best practices](https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices) - [Model Context Protocol · Authorization](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization) - [OWASP · LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/) - [OWASP · LLM01 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/) ### SA-05: Block untrusted models, datasets and agent skills from public hubs - Severity: Critical - Decision: Block - Owner: ML platform owner + application security #### Policy statement Deny loading or executing a model, dataset, prompt package or agent skill from a public hub unless it comes from an approved publisher, uses a non-executable format or has passed the organisation’s scan, and is pinned by digest. A skill is executable content and is reviewed as code. #### Covered operations - Download and load a model file in a serialisation format that can execute code - Install an agent skill, prompt pack or tool bundle from a marketplace - Pull a dataset or model into a build, notebook or agent runtime at run time - Run a model or skill whose digest differs from the reviewed version #### Evaluation rules - Resolve the hub, publisher, repository, revision and file digest; a floating tag or unpinned revision is unresolved and is blocked for anything that executes. - Block pickle-based and other executable model formats unless the file is from an approved publisher and passed a malware and pickle scan; prefer safetensors or equivalent non-executable formats. - Treat agent skills and prompt packs as third-party code: review for embedded instructions, tool grants and outbound calls before allowing an agent to run them. - Block runtime downloads that bypass the internal artifact proxy so provenance is recorded for every artifact an agent runs. #### Example decisions (illustrative; do not run against live systems) - **Python / Hugging Face Hub:** `Load a pickle model from an unverified repository at notebook start`. Block; require a scanned, digest-pinned safetensors artifact from the internal proxy. - **Agent marketplace:** `Install a skill that grants shell and network tools from an unknown publisher`. Block and route to skill review. - **CI:** `Pull a model by floating tag into the inference image build`. Block until the revision is pinned by digest. #### Applicable tools and systems - Hugging Face Hub - PyTorch / TensorFlow - Ollama - Agent skill marketplaces - Claude Code - Cursor - Internal artifact proxy (Artifactory, Nexus) - CI platforms #### Enforcement Route model and skill downloads through an internal artifact proxy with scanning and digest pinning, and deny direct egress to public hubs from build and agent runtimes. The control plane blocks skill installation and runtime loads that skip the proxy; egress and proxy policy are the hard boundary. #### Exception / approval Research use in an isolated sandbox with no company data or credentials, recorded as a sandbox load; promotion to any shared environment goes through the proxy and scan. #### Test fixtures - Should remain permitted: Load a scanned, digest-pinned safetensors model from the internal proxy, or install a skill from the internal reviewed catalogue. - Should be blocked or held: Load an unscanned pickle model, install an unreviewed skill from a marketplace, or pull a model by floating tag directly from the hub. #### Implementation references - [Hugging Face · Pickle scanning and model file security](https://huggingface.co/docs/hub/security-pickle) - [Hugging Face · Safetensors format](https://huggingface.co/docs/safetensors/index) - [OWASP · LLM03:2025 Supply Chain](https://genai.owasp.org/llmrisk/llm032025-supply-chain/) - [SLSA · Build track requirements](https://slsa.dev/spec/v1.2/requirements) ### SA-06: Review vendor AI features that process company data - Severity: High - Decision: Require approval - Owner: Data protection owner + SaaS platform owner #### Policy statement Hold enablement of an AI feature inside a sanctioned SaaS product, and hold OAuth grants from AI applications to company data, until the data-processing terms, training opt-out, retention and tenant isolation have been reviewed and recorded. A feature a vendor switches on by default is treated as a new processor. #### Covered operations - Enable a vendor AI assistant, summariser or copilot for a tenant, workspace or team - Approve an OAuth or app consent request from an AI application for mail, files, chat or CRM scopes - Accept updated vendor terms that add model training or third-party processing - Connect a sanctioned SaaS tenant to an external model provider #### Evaluation rules - Resolve the vendor, product, feature, model provider, processing region, training opt-out state and the data scopes the feature can read. - Hold tenant-wide AI feature enablement until a named data-protection reviewer records the assessment; block user-level consent to AI applications requesting broad scopes. - Re-evaluate when the vendor changes the model provider, adds scopes or changes terms; the earlier approval does not carry over. - Record every enabled AI feature and consented AI application in the inventory so shadow AI discovery has a sanctioned baseline to compare against. #### Example decisions (illustrative; do not run against live systems) - **Microsoft 365:** `Enable a third-party AI summariser for all Teams meetings`. Hold for data-protection review and inventory entry. - **Google Workspace:** `User consents to an AI note-taker requesting read access to all Drive files`. Block user consent; route to admin consent workflow. - **Salesforce:** `Switch on a generative feature that sends CRM records to an external model`. Hold until processing terms and region are recorded. #### Applicable tools and systems - Microsoft 365 - Google Workspace - Slack - Salesforce - Zoom - Notion - Atlassian - Identity providers (Entra ID, Okta) #### Enforcement Use identity-provider app consent policies, SaaS admin controls and cloud app discovery to gate features and grants. The control plane records the approved feature and scope set; the consent policy and vendor admin setting are the hard boundary. #### Exception / approval A workspace-scoped pilot with synthetic or public data, recorded in the inventory with an end date; production data requires the full review. #### Test fixtures - Should remain permitted: Enable a reviewed feature for the approved workspace with the recorded scopes and training opt-out in place. - Should be blocked or held: Enable an unreviewed vendor AI feature tenant-wide, approve a broad-scope AI app consent at user level, or accept new training terms without review. #### Implementation references - [Microsoft Entra · Configure user consent to applications](https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent) - [Microsoft Defender for Cloud Apps · Shadow IT discovery](https://learn.microsoft.com/en-us/defender-cloud-apps/what-is-defender-for-cloud-apps) - [NIST AI 600-1 · Generative AI Profile](https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf) ### SA-07: Allow sanctioned AI tools through the approved route, with a record - Severity: High - Decision: Allow with record - Owner: AI platform owner + security operations #### Policy statement Permit AI assistants, agents, connectors and models that are on the sanctioned inventory and reached through the approved tenant, gateway or proxy, and record the actor, tool, version and action for every session so the organisation can answer who did what through which tool. #### Covered operations - Use a sanctioned assistant under the enterprise tenant - Call a registered MCP server through the gateway - Load a scanned, pinned model or skill from the internal catalogue - Run an agent action inside its approved permission set #### Evaluation rules - Resolve the tool, version, tenant and route for every action; a sanctioned tool reached outside its approved route (personal login, direct server URL, direct hub download) is not sanctioned for that action. - Record actor, effective identity, tool, version, matched policy and outcome at decision time; minimise captured content and keep the record outside the acting identity’s control. - Reconcile the record against shadow AI discovery (browser, network, identity-provider consent logs) so tools seen in traffic but absent from the inventory are surfaced for intake. - Re-evaluate a sanctioned tool when its version, publisher, permissions or model provider changes. #### Example decisions (illustrative; do not run against live systems) - **GitHub Copilot:** `Generate code in a repository under the enterprise tenant with content exclusions applied`. Allow and record the session and version. - **Tracelet MCP gateway:** `Call a registered ticketing tool with a per-user credential`. Allow and record actor, tool and matched policy. #### Applicable tools and systems - GitHub Copilot - Claude - Cursor - Microsoft Copilot - Tracelet MCP gateway - Internal model catalogue - Identity providers (Entra ID, Okta) - SIEM #### Enforcement Keep the sanctioned inventory as the source of truth and forward decision records to the SIEM. Discovery from browser management, cloud app discovery and identity-provider consent logs closes the gap between what is sanctioned and what is running. #### Exception / approval None needed; this policy is the sanctioned path. Adding a tool to the inventory goes through the AI tool intake process. #### Test fixtures - Should remain permitted: Use an inventoried tool through its approved route and confirm a decision record exists for the action. - Should be blocked or held: Use the same tool through a personal login or a direct endpoint; the action is evaluated by SA-01 to SA-05, not allowed under this policy. #### Implementation references - [NIST · AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [NCSC · Guidelines for secure AI system development](https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development) - [NIST SP 800-207 · Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) ## Rollout checklist - [ ] Inventory authoritative resource IDs, environments, classifications and owners. - [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console. - [ ] Put the hard deny or least-privilege boundary in the destination system. - [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox. - [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope. - [ ] Observe matches, tune false positives and then enforce a bounded production scope. Coverage: https://tracelet.ai/platform#coverage