Shadow AI Detection and Governance: Stopping Unauthorized AI Tool Use Before It Becomes a Breach
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Shadow AI is the new shadow IT, and it moves faster. When an employee copies a customer contract into ChatGPT to summarize it, that data may be used for model training, stored in a third-party system subject to a breach, or exposed through a prompt injection attack the employee has no awareness of. Your existing DLP rules were written for file transfers and email. They do not match against text pasted into a browser-based AI prompt field.
The challenge is not purely technical. Employees use these tools because they are genuinely useful and productivity-improving. A governance program that only blocks will fail; employees will find workarounds or use mobile devices. The program needs to detect, classify, educate, and selectively allow while blocking the highest-risk data flows.
This guide covers the full detection and governance stack: DNS and proxy log analysis to find what AI endpoints are already in use, CASB configuration for Netskope and Zscaler, browser extension policy for AI prompt data, data classification integration, acceptable use policy templates, SaaS OAuth auditing, and an incident response workflow when sensitive data has already been exposed through an AI tool.
DNS and Proxy Log Queries to Detect AI Endpoint Usage
Start with visibility before you block anything. Pull 30 days of DNS query logs and proxy connection logs. Filter for the following domains and their subdomains:
api.openai.com, chat.openai.com, chatgpt.com claude.ai, api.anthropic.com gemini.google.com, aistudio.google.com copilot.microsoft.com, bing.com/chat huggingface.co perplexity.ai bard.google.com cohere.ai, cohere.com ai.meta.com mistral.ai
For DNS logs in Splunk use: index=dns query IN ("api.openai.com", "claude.ai", "gemini.google.com", "copilot.microsoft.com", "huggingface.co", "perplexity.ai") | stats count by src_ip, query | sort -count. For proxy logs: index=proxy dest_host IN ("api.openai.com", "claude.ai", "gemini.google.com") | stats count, sum(bytes_out) as data_sent by src_ip, dest_host | sort -data_sent.
The bytes_out value from the proxy query is your first risk signal. A user sending 500KB or more in a single session to an AI API is likely uploading document content. Any source IP sending more than 2MB aggregate per day to AI endpoints warrants investigation before you build policy.
Export a unique user list grouped by AI endpoint accessed. This is your baseline population. You will reference it when configuring CASB policy and when conducting manager-level conversations about acceptable use.
CASB Policy Configuration for Shadow AI
Cloud Access Security Brokers provide the enforcement layer once you have visibility. The configuration approach differs between Netskope and Zscaler, but the policy logic is the same: allow approved AI tools under data controls, block unapproved tools for specific data classifications, and log everything for incident response.
For Netskope: navigate to Policies > Real-time Protection. Create a new policy with Activity set to Upload and Post. Set App Tag to Generative AI, which Netskope maintains as a curated category. Set the action to Block with user notification for any upload activity where the DLP profile matches your sensitive data classifications (PII, PCI, confidential). For approved tools like Microsoft Copilot or your enterprise ChatGPT tenant, create an allow policy above the block rule with a stricter DLP inline scan.
For Zscaler Internet Access: go to Policy > URL Categories and create a custom category named Shadow AI Tools. Add the unapproved AI domains to this category. Under Cloud App Control, create a new rule with the action Block for your Shadow AI Tools category applied to all users outside of a designated AI Pilot group. Set the SSL inspection policy to include AI domains so payload inspection is possible.
For both platforms, configure an alert policy that notifies the security team when a user attempts to upload content flagged as confidential to any AI endpoint, whether blocked or allowed. Blocked attempts still indicate user intent and need follow-up.
Subscribe to unlock Remediation & Mitigation steps
Free subscribers unlock full IOC lists, Sigma detection rules, remediation steps, and every daily briefing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Browser Extension Management and AI Prompt Data
Browser extensions for AI tools like Grammarly, Compose AI, and Otter.ai operate inside the browser context and can read page content, clipboard data, and form inputs before your CASB proxy ever sees them. These extensions bypass TLS inspection entirely because they operate client-side.
Audit installed browser extensions using your endpoint management platform. For Microsoft Intune: Settings > Devices > Configuration Profiles, create a policy under Administrative Templates > Google Chrome > Extensions. Use the ExtensionInstallBlocklist to block AI extensions that are not approved. For Jamf or other Mac MDM solutions, use a configuration profile with the com.google.Chrome.extensions.blocked key.
For Windows environments with Defender for Endpoint, the DeviceFileEvents and DeviceBrowserArtifacts tables in MDE advanced hunting can surface recently installed extensions. Query: DeviceBrowserArtifacts | where ArtifactType == "Extension" | where BrowserName in ("Chrome", "Edge") | project DeviceName, Timestamp, ArtifactValue | where ArtifactValue contains "AI" or ArtifactValue contains "GPT" or ArtifactValue contains "Copilot".
Create an approved extension list that includes extensions with enterprise data handling agreements. Any extension that requests access to all site data or clipboard access for AI-related functionality should require explicit approval. Include browser extension governance in your acceptable AI use policy so employees understand what is permitted at the browser level, not just at the network level.
SaaS OAuth Audit for AI App Grants
When a user visits an AI tool and clicks Sign in with Google or Sign in with Microsoft, they grant that AI application OAuth access to their corporate account. Depending on the scopes requested, the AI app may now have read access to email, calendar, files, and contacts. This happens entirely outside your CASB visibility window.
For Microsoft 365: run the following in PowerShell using the Graph API or use the Entra admin center under Enterprise Applications > All Applications, filter by User Assigned. Look for applications with permissions including Mail.Read, Files.ReadWrite.All, or Calendars.Read that are not in your approved software catalog. Export the full list: Get-MgServicePrincipal -Filter "tags/any(t: t eq 'WindowsAzureActiveDirectoryIntegratedApp')" | Select-Object DisplayName, AppId, CreatedDateTime.
For Google Workspace: go to Admin Console > Security > API Controls > Manage Third-Party App Access. Sort by data access level. Any app with broad data access that is not in your approved list should be investigated. Google labels these as Trusted, Limited, and Blocked; ensure AI tools not on your approved list are set to Blocked.
Review OAuth grants quarterly as a standing audit task. The goal is to find AI tools that employees have authorized access to corporate data and either ratify them with a data handling agreement or revoke the grant and communicate to the affected users why. For Microsoft, revoke with: Remove-MgServicePrincipalAppRoleAssignment -ServicePrincipalId <id> -AppRoleAssignmentId <assignmentId>.
Incident Response Workflow for Sensitive Data Exposure via AI Tool
When your CASB, DLP, or audit log reveals that sensitive data has been submitted to an AI tool, treat it as a data exposure incident. The key difference from a traditional DLP incident is that you may not be able to determine whether the data was retained by the AI provider or used in training, which affects breach notification analysis.
Step 1, Contain. If the submission was to an unapproved tool with no enterprise agreement, block the user's access to that domain at the CASB layer immediately. If the tool is an approved tool but the data submitted exceeded classification boundaries, document the event without blocking, pending investigation.
Step 2, Identify. Pull the proxy or CASB log for the session. Note the URL endpoint called, the HTTP method (POST to /v1/messages or /v1/chat/completions indicates prompt submission), the payload size, and the user's identity. If TLS inspection was in place, capture the request payload if permitted by your legal and privacy team.
Step 3, Classify the data. Work with the data owner to determine the classification of what was submitted. PII involving customers may trigger state breach notification obligations. Source code submitted to a non-enterprise AI tool may constitute trade secret exposure. Healthcare data submitted externally may create HIPAA obligations.
Step 4, Notify the AI provider. If the tool has an enterprise support channel, submit a data deletion request referencing the session timestamp and user account. Retain the acknowledgment for your incident record. Most AI providers honor deletion requests for enterprise customers; consumer tier tools have no guaranteed deletion SLA.
Step 5, Review and update controls. Identify the control gap that allowed the exposure. Update CASB policy, DLP rules, or acceptable use training accordingly. Close the incident with a control remediation ticket attached.
Acceptable AI Use Policy Template
A governance program without a written policy has no enforcement basis and no training anchor. The policy does not need to be exhaustive; it needs to be clear enough that an employee knows whether a specific action is permitted before they take it.
Include the following sections in your policy:
Approved AI Tools: list specific tools with their permitted use cases and data classification limits. Example: Microsoft Copilot for M365 is approved for internal use cases involving data classified up to Confidential. ChatGPT enterprise tenant is approved for code review involving internal but not customer data.
Prohibited Actions: explicitly list what is never permitted. Pasting customer PII, payment card data, protected health information, source code classified as proprietary, or board-level confidential documents into any AI tool including approved tools is prohibited.
Personal AI Tool Use: address whether employees may use personal AI accounts on corporate devices. Many organizations permit this for non-work content but prohibit using personal AI accounts for any work-related task. State this clearly.
AI-Generated Output Review: require human review before using AI-generated content in customer-facing materials, legal documents, or code deployed to production. Note the risk of AI hallucination and model error.
Reporting Obligations: require employees to report suspected AI-related data exposure to the security team within 24 hours of discovery. Include the reporting channel.
Review the policy quarterly as the AI tool landscape changes. Version it and include the effective date in the document header.
The bottom line
Shadow AI governance is not a one-time project. It requires continuous monitoring of new AI endpoints entering your DNS logs, regular OAuth audits, and a policy that evolves as approved tools expand. Start with visibility: run the DNS query today and find out what AI tools are already in use. The results will almost certainly change your priorities.
Frequently asked questions
Can we block all AI tools at the network layer without a CASB?
Yes, using DNS filtering or proxy category blocking. Most DNS security platforms (Cisco Umbrella, Cloudflare Gateway, Infoblox) allow you to block a custom domain list or an AI-tools category. The limitation is that this is binary: all or nothing per domain. A CASB gives you per-activity control, so you can allow browsing to an AI tool but block upload activity, which is far less disruptive to legitimate use cases.
What if employees use mobile data to bypass corporate network controls?
Mobile bypass is a real gap. Address it through endpoint management: require corporate devices to route all traffic through the VPN or CASB mobile agent. For BYOD, your policy can prohibit work-related AI tool use on personal devices, but enforcement relies on acceptable use policy and training rather than technical controls. Mobile threat defense solutions like Lookout and Zimperium can identify AI tool app installations on enrolled devices.
How do I handle open-source AI models running locally on developer machines?
Local LLM inference (Ollama, LM Studio, locally hosted Llama) bypasses all network-layer controls. Address this through endpoint policy: add local AI inference tools to your approved software list if they are permitted for non-sensitive data, or prohibit installation via application control policy. Include local AI tools explicitly in your acceptable use policy so the prohibition is documented and enforceable.
What data handling questions should we ask AI tool vendors before approving a tool?
Ask: whether submitted prompts are used for model training, the data retention period for prompts and completions, where data is stored geographically, whether a zero data retention option is available, how data is isolated between customers, and whether the vendor has SOC 2 Type II certification. For any tool that will process customer data, require a Data Processing Agreement before approval.
How do we handle the employee who reports their own accidental AI data exposure?
Treat self-reported incidents with the same process as detected incidents but without disciplinary action for the initial report. Self-reporting is the behavior you want to encourage. Document the incident, assess breach notification obligations, submit a deletion request to the AI provider, and close with a reminder of the acceptable use policy. Punishing self-reporters destroys the reporting culture you need for future incidents.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.