Find and stop unapproved AI tool use by staff

TL;DR — If staff are using AI tools you never approved, the fastest path is to check your identity provider sign-in logs and your web filtering or DNS logs for known AI domains, then block access and revoke any active sessions or tokens. The most common root cause is simple: there was no explicit allow/block policy in your browser, network, or single sign-on setup, so staff used personal accounts or direct web access. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon and someone from legal forwards you a screenshot: a proposal draft appears to have been pasted into a public AI chatbot. Nobody remembers approving that tool. Your team asks whether customer data, source code, or contracts have already been uploaded, and you need an answer before the end of the day. You do not need a perfect forensic investigation yet; you need a fast, defensible way to confirm what is happening, stop the obvious paths, and preserve enough evidence to follow up.

Symptoms

• Staff mention tools you did not approve in chat, tickets, or meeting notes.
• Browser history, proxy logs, or DNS logs show visits to AI service domains such as:

chat.openai.com
claude.ai
gemini.google.com
perplexity.ai
notebooklm.google.com
poe.com

• Identity provider logs show new app sign-ins or OAuth consent events (OAuth = delegated access token) for AI-related apps.
• Data loss prevention alerts show copy/paste or file upload activity to web apps.
• Endpoint or browser extension inventory shows AI assistants or prompt tools installed without approval.
• Users say things like:

I only used my personal account.
It was just in the browser, not installed.
I clicked "Continue with Google/Microsoft".

• Security logs contain lines similar to:

ALLOW https://chat.openai.com/
CONNECT claude.ai:443
DNS query: perplexity.ai A
OAuth consent granted to application

Likely causes

Step-by-step diagnosis

1. Check whether this is active right now.
   • Menu path: in your DNS filter, secure web gateway, or firewall dashboard, search the last 7 days for one known AI domain, for example chat.openai.com.
   • If you have no network tool, check your DNS provider logs if enabled, or your office router/firewall logs.
   • This is your problem if you see repeated allowed requests such as:

ALLOW chat.openai.com
CONNECT claude.ai:443
DNS query allowed: perplexity.ai

• Jump to Fixes → No web filtering or DNS blocking for AI domains.

1. Check whether staff used work sign-in to access AI apps.

   • Menu path: in your identity provider's dashboard (for example, Microsoft Entra/Google Workspace/Okta equivalent), open Sign-in logs or Authentication logs and filter the last 30 days for app names and domains related to AI tools.
   • This is your problem if you see successful sign-ins, OAuth grants, or "Continue with Google/Microsoft" events tied to those apps.
   • Jump to Fixes → Staff used personal accounts because SSO was not enforced or Fixes → OAuth consent was left open depending on what you find.

2. Check for browser extensions and desktop apps.

   • Menu path: in your browser management console, open Extensions or Apps inventory; in your device management dashboard, open Installed applications.
   • This is your problem if you find AI assistants, summarizers, writing helpers, prompt managers, or unofficial desktop wrappers installed on managed devices.
   • Jump to Fixes → Browser extensions or desktop apps were allowed by default.

3. Check for sensitive data movement.

   • Menu path: in your DLP dashboard, email security tool, or file-sharing audit logs, search the last 30 days for uploads, clipboard events, or file access followed by AI-domain visits.
   • This is your problem if the same user accessed sensitive files and then uploaded or pasted content to an AI site.
   • Jump to Fixes → No DLP or upload controls on sensitive apps and file shares.

4. Check whether unmanaged devices are bypassing controls.

   • Menu path: in your identity provider, filter sign-ins by device trust/compliance; in your MDM/UEM, compare managed vs unmanaged access.
   • This is your problem if sign-ins to work email, docs, or storage came from devices marked unmanaged, unknown, or non-compliant.
   • Jump to Fixes → BYOD or unmanaged devices bypassed company controls.

5. Preserve evidence before broad cleanup.

   ⚠️ Revoking sessions, deleting apps, or wiping devices can remove useful evidence. Export logs first if you may need HR, legal, or customer notification follow-up.

   • Menu path: export sign-in logs, DNS/proxy logs, extension inventory, and DLP alerts for the affected dates.
   • If exports confirm repeated access, proceed with the matching fix below.

[User] ---- 1. visits AI site ----> [Browser/App]
  |                                   |
  | 2. SSO or personal login          | 3. upload/paste
  v                                   v
[IdP Logs] <---- 4. events ---- [AI Service]
  ^                                   ^
  | 5. DNS/proxy logs                 | 6. DLP alerts
  |                                   |
[Network Controls] -------------> [Security Logs]

Fixes

No web filtering or DNS blocking for AI domains

Add an explicit deny list in your DNS filter, secure web gateway, or firewall for the AI domains you do not allow.

• Menu path: in your provider's dashboard (for example, web filter/DNS filter), open Policies → Blocked domains.
• Add domains such as:

chat.openai.com
openai.com
claude.ai
anthropic.com
perplexity.ai
gemini.google.com
notebooklm.google.com
poe.com

• If your firewall supports FQDN rules (FQDN = full domain name), create an outbound deny rule for those hostnames on TCP 443.
• If you manage DNS with a resolver that supports local policy, add local-zone or blocklist entries.

Verify it worked: from a managed device, opening one of the blocked sites should show your block page or fail with a denied DNS/proxy event in logs.

Staff used personal accounts because SSO was not enforced

Restrict access so only approved apps can use work identity, and block direct access to unapproved AI sites.

• Menu path: in your identity provider, open Applications/Enterprise apps → User consent/App access policies.
• Set user assignment required for approved apps where your provider supports it.
• Disable or restrict self-service access to unapproved third-party apps.
• In your web filter, block direct access to the AI domains so users cannot simply switch to personal accounts in the browser.

If your provider supports conditional access (policy-based sign-in rules), create a rule that blocks unapproved cloud apps and requires managed devices for work data access.

Verify it worked: a test user should be unable to sign in with work identity to the unapproved app, and direct browser access should be blocked.

Browser extensions or desktop apps were allowed by default

Move from allow-by-default to allowlist-only for extensions on managed browsers, and remove known AI apps from managed devices.

• Menu path: in your browser management console, open Extensions → Policy.
• Set extension install policy to allow only approved IDs where your browser supports it.
• Add explicit block entries for known AI assistant extensions.
• In your device management dashboard, uninstall unauthorized desktop apps from managed endpoints.

If you use managed Chrome/Edge policies, the setting is typically an extension allowlist/blocklist in the admin console or device policy profile.

Verify it worked: the extension store should show the blocked extension as unavailable on managed browsers, and the app should disappear from managed device inventory after the next check-in.

OAuth consent was left open, so staff connected work data to third-party AI apps

Restrict user consent and revoke existing grants.

• Menu path: in your identity provider, open User consent / API controls / Connected apps.
• Change consent so only admins can approve third-party apps, or limit consent to verified low-risk apps if your policy allows it.
• Review recent grants and revoke any unapproved AI app connections.
• For affected users, revoke active sessions and refresh tokens.

Common admin action names vary, but look for buttons such as Revoke consent, Revoke sessions, or Block application.

Verify it worked: the app no longer appears in connected apps for the user, and a fresh sign-in attempt is denied or requires admin approval.

No DLP or upload controls on sensitive apps and file shares

Create a narrow DLP rule first for your highest-risk data, then expand.

• Menu path: in your DLP tool, open Policies → New policy.
• Start with one rule: detect customer PII (personal information), contracts, source code repositories, or finance exports, and alert/block when uploaded to uncategorized web apps or known AI domains.
• Apply the rule to email, cloud storage, and browser uploads if your tool supports all three.

A practical first rule is: block uploads of files labeled confidential to unapproved web categories, and alert on clipboard paste over a size threshold.

Verify it worked: a test upload of a labeled sample file to a blocked AI site should trigger an alert or be blocked.

BYOD or unmanaged devices bypassed company controls

Require managed devices for access to work email, docs, and file storage.

• Menu path: in your identity provider, open Conditional access / Access policies; in MDM/UEM, open Compliance policies.
• Create a policy: if device is unmanaged or non-compliant, block access to work apps or allow browser-only limited access where available.
• Apply the policy first to a pilot group, then roll out broadly.

⚠️ This can interrupt staff access and create support tickets if rolled out too quickly. Pilot with a small group first.

Verify it worked: a test sign-in from an unmanaged device should be blocked or limited, while a managed compliant device still works.

Prevention

1. Publish an explicit approved-tools policy and enforce it technically.

   • Keep a short allowlist in a shared document and mirror it in your controls: web filter categories, browser extension allowlist, and identity provider app approvals.

2. Add a recurring report for AI-domain access.

   • In your DNS/proxy tool, save a report for top requests to AI-related domains over the last 7 days.
   • Suggested search terms:

openai
claude
anthropic
perplexity
gemini
notebooklm
poe

1. Turn off broad user OAuth consent.

   • In your identity provider, set third-party app consent to admin-only, then create an approval workflow for exceptions.

2. Require managed browsers on work devices.

   • Push browser policies from your device management tool so extension installs, password managers, and data controls are centrally enforced.

3. Add a lightweight CI check for company docs and repos that mention banned AI endpoints.

   • For internal scripts, browser configs, or docs repositories, scan for disallowed domains:

grep -RniE 'chat\.openai\.com|claude\.ai|perplexity\.ai|gemini\.google\.com|poe\.com' .

• Use this in your documentation or policy repo to catch accidental instructions that point staff to unapproved tools.

1. Keep evidence-friendly logs for at least 30 days.
   • Retain identity sign-ins, DNS/proxy logs, browser extension inventory, and DLP alerts long enough to investigate a report after the fact.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.