CyphrQ
Menu

Shadow AI at Work: How to Find the AI Tools Your Team Already Uses

Shadow AI at work is AI your team uses without approval. How to find it in consent, network and expense records, and what to offer instead.

By CyphrQ.ai

Written with AI assistance and human editorial review. Every figure linked to its source.

11 min read

Shadow AI at work is any AI tool your staff use for work without the company approving it: a personal chatbot account, a writing extension, a notetaker that joins meetings. You can find most of it in records you already keep. You fix it by offering a better approved option, not only by banning things.

Most shadow AI is well-meant. People are trying to get their work done faster. The trouble is that the company can't see where its data went, can't get it back, and can't switch the access off when someone leaves.

This guide covers why it happens, where to look, and what to do once you've found it. For IT and security teams, there's a technical section on discovery logs and enforcement.

What is shadow AI at work?

Shadow AI is the AI version of shadow IT: software used for company work outside the company's approval and view. It usually looks ordinary:

  • A personal chatbot account used to draft client emails or summarise reports.
  • A free AI notetaker someone connected to their work calendar.
  • A browser extension that rewrites text, and reads the pages you visit to do it.
  • An AI feature switched on inside a SaaS tool you already pay for.
  • A "Sign in with Microsoft" or "Sign in with Google" click that gave an AI app access to a work mailbox or drive.

That last click can hand a third-party app ongoing access to work data, and the access stays until someone revokes it.

How common is this? In practice: Microsoft and LinkedIn's 2024 Work Trend Index surveyed 31,000 knowledge workers across 31 markets, including the UK and the US, between February and March 2024. It found that 78% of AI users bring their own AI tools to work, and 80% at small and medium-sized companies (Microsoft WorkLab). The survey doesn't give a separate UAE or GCC figure, and Microsoft hasn't published a newer bring-your-own-AI figure on that page.

Why do people use AI tools without asking IT?

Rarely out of defiance. The usual reasons are practical:

  • There is no approved tool, or the approved one is weaker than the free one on their phone.
  • Approval is slow. If a request takes a month, people stop asking.
  • They don't know it counts. An AI button inside an app they already use doesn't feel like a new tool.
  • It's free and one click away. No purchase order, so no one in finance sees it either.

Treat each unapproved tool as a signal of demand. It tells you a job someone needs done, and that your approved options don't cover it yet.

What are the real risks of unapproved AI tools?

The risk isn't that AI is used. It's that it's used where you have no contract, no logs and no off switch.

  • Data lands outside your control. Work content sits in an account with consumer terms and no agreement between your company and the vendor. What not to paste, and how business and personal accounts differ, is covered in the AI-at-work privacy checklist.
  • Access outlives the person. An app granted access to a mailbox keeps it until the grant is revoked. A personal account keeps its chat history after the employee has gone.
  • Permissions are wider than people think. "Read your calendar" on a notetaker can mean every meeting title, attendee and dial-in link. Notetakers get their own guide: AI meeting notetaker privacy.
  • No evidence when something goes wrong. If a client asks where their data went, you can't answer for a tool you didn't know about.
  • Some tools act, not just answer. Unapproved agents and AI browsers can send, book and buy. See AI agents at work and AI browsers explained, and prompt injection explained for why content these tools read can steer them.

In practice: IBM's Cost of a Data Breach Report 2025 looked only at organisations that had been breached: 600 of them worldwide, with breaches between March 2024 and February 2025. A fifth of those organisations put a breach down to shadow AI. IBM says only 37% have policies to manage AI or detect shadow AI (IBM Newsroom).

IBM's July 2026 press release for the next edition gives no shadow AI figure, so the 2025 numbers are still IBM's latest on shadow AI.

Where does shadow AI show up, and how do you find it?

One term first: app consent is the permission a person gives a third-party app, usually through a "Sign in with Microsoft" or "Sign in with Google" screen, to read data in their work account.

Five places, from cheapest to most technical:

  1. Expense claims and company cards. Search statements for AI vendor names and small recurring subscriptions. This takes an afternoon and needs no new software.
  2. A no-blame question. Ask every team: "Which AI tools do you use for work, and for what?" Promise no one gets in trouble for answering. You'll learn which jobs need covering.
  3. App-consent records. Microsoft 365 and Google Workspace both show which third-party apps people have connected to their work accounts, and how many users each one has.
  4. Browser extensions on company laptops, pulled from your device or browser management.
  5. Web and DNS traffic from your firewall, secure web gateway or cloud app security tool, which shows which AI services company devices reach.

Start with the first two this week. They cost nothing and tell you what people actually need, which the logs can't.

Should you ban unapproved AI tools?

Not as a first step: ban a specific risky tool once people have something better, rather than banning AI tools as a whole.

A blanket ban on its own can push the use onto personal phones and home laptops, where you see nothing at all. Block what is clearly risky, approve what is useful, and make the approved route faster than the workaround.

What should you do once you find them?

Sort every tool you find into one of three groups:

Decision When What happens next
Approve Useful, business tier available, sign-in through your company account Add to the approved list, move users to the company account
Approve with conditions Useful, but only safe for some data Approve for named data types only, for example "public and internal, never client data"
Retire Risky permissions, no business terms, or a duplicate of something approved Revoke access, tell users why, point them to the alternative

For each tool, ask four questions: what data goes into it, who uses it, is there a business plan with a contract, and can it use company sign-in so you can remove access centrally?

Then make the approved route easy:

  • Publish an approved-tools list. One page: tool name, what data it's approved for, how to get access, and who owns it.
  • Offer the alternative before you block. If people used a free notetaker, give them an approved one first.
  • Set a quick request route. A named person and a target answer time, so the next tool comes to you instead of around you.
  • Write the rules down once. What the policy itself should say is in the AI-at-work privacy checklist.

Going deeper: for security and IT teams

The threat model is unmanaged data flow and standing access, not intrusion. The actors are employees and the third-party apps they authorise. The assets are mailbox, file and meeting data. The failure modes are an OAuth grant that persists after offboarding, content held under consumer terms, and no audit trail. An attacker benefits too: a malicious app that tricks a user into granting consent gets the same standing access.

OAuth and app consent in Microsoft Entra ID. By default, all users can consent to apps for permissions that don't require admin consent, such as access to their own mailbox. Settings live at Identity, then Applications, then Enterprise apps, then Consent and permissions, then User consent settings. The built-in policy microsoft-user-default-low allows user consent only for apps from verified publishers or registered in your tenant, and only for permissions you classify as low impact. Microsoft recommends allowing user consent only for verified publishers.

Pair the restriction with the admin consent workflow so users can request review instead of giving up. One catch: changing consent settings only affects future consent. Existing grants remain, so review permissions already granted to enterprise applications as a separate step (Microsoft Learn).

Google Workspace. Go to Security, then Access and data control, then API controls, then Manage App Access. The Accessed apps list shows each app that has accessed Google data, with a Users count and the requested services. Details usually appear 24 to 48 hours after authorisation. Configured apps can be set to Trusted, Limited, Specific Google data or Blocked. For unconfigured third-party apps, the default is "Allow users to access any third-party apps". The stricter setting, "Allow users to access third-party apps that only request basic info needed for Sign in with Google", lets through only apps that ask for basic sign-in details (Google Workspace Admin Help).

Network discovery and blocking. In Microsoft Defender for Cloud Apps, Cloud Discovery lets you tag discovered apps Sanctioned or Unsanctioned. Tagging an app Unsanctioned doesn't block it by itself; it makes the app easier to monitor. Before blocking, Microsoft lists three prerequisites: Cloud Protection and Network Protection in Defender for Endpoint, plus the Microsoft Defender Browser Protection add-on in non-Microsoft browsers. Where a manual tag and a discovery policy conflict, the last operation applied takes precedence (Microsoft Learn). How blocking works depends on what the tenant runs:

Tenant uses Unsanctioned apps blocked? Device-group scoping, warn and educate
Microsoft Defender for Endpoint Yes, automatically Yes
Zscaler NSS, iboss, Corrata, Menlo or Open Systems Yes No
A supported on-premises appliance Once you import the generated block script Not covered on the page
Anything else Once you export the unsanctioned domains and block them on your appliance Not covered on the page

DNS, extensions and expenses. DNS resolver logs catch lookups from devices that bypass the proxy, but they show a domain, not the account or the data. Use them for coverage, not attribution. For browser extensions, export the inventory from your browser or device management and review anything allowed to read and change data on all sites, then move to an allowlist. Finance data closes the gap for tools bought on cards.

Egress controls. Once the sanctioned tool is in place, add DLP on paste and upload to AI sites. The Microsoft Purview pattern is set out in the privacy checklist's technical section.

Detection signals. Alert on new consent grants to apps requesting mail, file or calendar scopes; a jump in users on a newly discovered generative AI app; and blocked connections to an app that was supposed to be retired.

In practice: IBM's 2025 report found that 63% of breached organisations either don't have an AI governance policy or are still developing one. Of those with a policy, only 34% perform regular audits for unsanctioned AI (IBM Newsroom). So even among organisations with a policy, most don't audit for unsanctioned AI.

What to verify. Who can consent to apps today, and on what policy? How many existing grants have mail or file scopes, and does each have an owner? On a managed test device, open an app you've tagged Unsanctioned: is it blocked, and did the event reach your SIEM? What covers unmanaged and personal devices? For each sanctioned tool, ask the vendor: SSO and SCIM support, audit log contents and retention, and whether business data is excluded from training.

Key takeaways

  • Shadow AI is AI used for work without approval. It's common and usually well-meant.
  • The biggest blind spot is often an app connected to a work account, not a chatbot tab.
  • Expenses and a no-blame survey find a lot before you open any log.
  • Sort each tool: approve, approve with conditions, or retire.
  • Offer the sanctioned alternative before you block.
  • For IT: restrict user consent, review existing grants, and test that unsanctioned tags actually block.

Checklist: a 30-day shadow AI review

  • [ ] Week 1: search expense claims for AI subscriptions and send the no-blame survey.
  • [ ] Week 1: name one owner for AI tool approvals and a target answer time.
  • [ ] Week 2: export connected third-party apps from Microsoft Entra or Google Workspace.
  • [ ] Week 2: list browser extensions on company devices.
  • [ ] Week 3: pull AI services from web, DNS or cloud app security logs.
  • [ ] Week 3: sort every tool into approve, approve with conditions, or retire.
  • [ ] Week 4: publish the approved-tools list and move users to company accounts.
  • [ ] Week 4: revoke retired grants, restrict user consent, and set alerts for new grants.
  • [ ] Every quarter: repeat the review.

Sources