Skip to content

Shadow AI Is Not Shadow IT

Published: at 06:05 AMSuggest Changes

One organisation I worked with first measured AI use by accident. A staff survey returned a comfortable picture: a majority on the approved assistant, a handful experimenting with public chatbots, little cause for alarm. Weeks later, the identity team pulled third-party sign-in data and found generative AI services reached through hundreds of personal accounts that no respondent had thought worth mentioning. Nobody had lied. The survey had asked what people were willing to admit, and the logs recorded what they did.

That gap is why shadow AI cannot be handled with the shadow IT playbook. Shadow IT was, at heart, an unmanaged application. You could find it in the SaaS bill or the network flow, decide whether to buy it properly, and move on. The application carried the risk, so controlling the application controlled the risk.

Shadow AI splits that tidy model in two. The tool is often free and the account is personal, so there is no bill to audit and no corporate credential to revoke. What leaves the organisation is the content of a prompt, and what comes back is an output that someone may act on without checking it. An unmanaged app and an uncontrolled data path are different problems, and they call for different responses.

The data leaves through the prompt

The exposure is not abstract. Cisco’s 2025 Data Privacy Benchmark Study found that while 64% of respondents worried about inadvertently sharing sensitive information publicly or with competitors, nearly half admitted to inputting personal employee or non-public data into generative AI tools anyway. Employee names and information went in at 46%, non-public company information at 42%. [Cisco, April 2025]

That is the first half of the difference. The second half is quieter and more dangerous. Work is now being produced on top of outputs nobody validated. A contract clause drafted by a chatbot, a risk summary, a customer reply, a piece of code — each carries an implicit claim of correctness that no one has signed. Shadow IT produced unauthorised tools; shadow AI produces unauthorised conclusions, and those conclusions travel into decisions, documents and systems that look entirely normal.

IBM’s 2025 Cost of a Data Breach Report made the financial case. For the first time it treated shadow AI as a formal breach category, finding that one in five breached organisations traced an incident to it — more than the share involving sanctioned AI. Organisations with high shadow AI exposure carried an average of USD 670,000 in additional breach costs, and 65% of those incidents exposed customer personally identifiable information against a 53% global average. Only 37% of organisations had policies to manage AI or detect shadow AI at all. [IBM, July 2025]

That last figure does not describe a failure of tooling. It describes organisations running an exposure they have not agreed to look for.

Find it in the telemetry, not the survey

Surveys measure attitudes. You need behaviour, and behaviour lives in the systems you already run.

Gartner’s survey of 302 cybersecurity leaders found that 69% of organisations either suspected or had evidence that employees were using prohibited public generative AI tools, and it projected that by 2030 more than 40% of enterprises would experience a security or compliance incident linked to unauthorised shadow AI. [Gartner, November 2025] That is the scale. The confidence problem is separate: Okta’s AI Agents at Work 2026 report found that 90% of executives believed they had visibility into AI tool use, while 52% of knowledge workers admitted to using unapproved tools, often through personal accounts. [Okta, May 2026]

Both numbers can be true at once. Leaders can see the tools they sanctioned; the rest surface only when someone goes looking in the right place. PagerDuty’s Shadow AI Survey found 88% of office professionals had shared work-related information with public AI tools, including 43% sharing emails and correspondence and 34% sharing customer data — and 66% had used AI at work despite believing company policy did not permit it. [PagerDuty, June 2026]

The right place is telemetry you already collect. Start with identity: sign-in and consent logs for third-party AI services, including the OAuth grants that quietly give an app access to mail, files or a CRM. Move to the network: secure web gateway and CASB records of AI destinations, segmented by whether the account behind the session is corporate or personal. Then the SaaS layer, where admin APIs reveal which AI features are switched on and who enabled them. Add data-loss-prevention events for paste and upload, and endpoint data for locally installed assistants and connector processes that never touch a managed gateway.

The gap between a sanctioned tool used correctly and one used through a personal account matters more than most inventories capture. Okta found that 80% of employees using unapproved tools did so because their own accounts were easier, and that employees frequently used the free tier of a company-approved product rather than the paid one. [Okta, May 2026] A blocklist built only from product names will miss both.

Give people a path they will actually take

Every organisation I have seen with a serious shadow AI problem also had an approval process slow enough to guarantee one. The friction is the control gap.

The evidence is consistent. In Okta’s survey, 57% of employees who bypassed controls said the approval process was too slow or difficult, and 49% said the approved tools did not meet their needs. [Okta, May 2026] PagerDuty found that 77% believed company restrictions were limiting their professional growth or career mobility. [PagerDuty, June 2026] People are not routing around governance for sport. They are routing around a queue.

The corrective is unglamorous. Put a published service-level commitment on new AI tool requests — two weeks, measured and reported. Offer provisional access to a sandbox for anything that touches only public or internal data, so experimentation has somewhere legitimate to happen. Fund licences for the five use cases that generate the most demand, because an approved tool nobody can get is not an approved path. And measure the request queue like a product: time to decision, time to provisioning, percentage rejected and why. A path that is slower or narrower than the shadow alternative will be ignored, however well written the policy.

Classify the data, not the tools

The instinct to publish a banned-tools list is understandable and mostly wrong. Product names change monthly; data classes do not. A policy that names what may never enter an unapproved tool survives the next launch cycle, and a policy that bans apps does not.

A workable version has four classes. Public and marketing material can go almost anywhere, including consumer tools. Internal-only content can go to approved tools on corporate identities. Confidential content — unreleased financials, contracts, source code, customer lists — goes only to enterprise-tier tools with training disabled and retention configured. Regulated content, including personal data under privacy law and anything under NDA, stays inside the governed environment and never enters a consumer model. On top of that, one account rule does most of the work: company data moves only through corporate identities and single sign-on, so a personal account is out of scope by definition rather than by good intention.

Then close the assurance loop that shadow AI opened. Wherever an AI output feeds a decision, a customer communication or a system of record, name the human who validates it. The control is not the model’s accuracy; it is that someone owns the result. That single requirement catches more real risk than any blocklist, because it forces teams to notice when unvalidated output has quietly become an input to something that matters.

Bring the business-built agents into the portfolio

The hardest part of discovery is no longer the tool. It is the agent. Low-code platforms, productivity suites and automation tools now let a business analyst build something that reads documents, calls an API and writes back to a system — and none of it appears in an application inventory, because nobody thinks of it as software. It looks like a workflow.

Bring those into the same register you use for sanctioned agents, but expect to find them first through telemetry rather than disclosure. Each entry needs four fields to be useful: a named business sponsor, a one-line purpose, the action authority stating what it may do without human approval, and a retirement trigger. An agent that writes to a customer record, sends an external message or moves data between systems needs the same treatment as any other privileged integration, whether or not IT built it.

The point is not to punish the people who built it. A business team that automates its own paperwork has found a real gap in what central delivery provides. The register converts an unmanaged capability into a decision you can make: keep it, harden it, or fold it into a funded platform service.

Block, tolerate or enable

With discovery and classification in place, the leadership decision becomes tractable, because it is no longer one decision about all AI. It is three, applied per use case.

Block narrowly. A short list of hard stops earns its authority: regulated data into unapproved tools, company data on personal accounts, and unregistered agents with write access to systems of record. Keep this list short enough that people believe it, and enforce it through identity and network controls rather than through policy language alone.

Tolerate with visibility. Low-risk, public-data tasks — summarising a published report, drafting internal notes, exploring a new model — can proceed with monitoring and a stated logging disclosure. Tolerating what you can see is not the same as ignoring what you cannot.

Enable deliberately. For the use cases that generate the most demand, fund an approved path and staff it. This is where the return sits: the demand is already proven, and the only question is whether it runs inside your boundary or outside it.

Do discovery first, with telemetry. A thirty-day read across identity, network, SaaS admin and endpoint data tells you more than a quarter of surveys, and names the identity behind each finding. Then publish the data-class policy, stand up the fast approval path, and add the agent register to the portfolio review you already run.

The leadership test is simple, and it is not a survey. Ask for the list of every AI tool and agent that touched your confidential or regulated data in the last thirty days, the identity behind each, and whether a named person validated what it produced. If assembling that list requires asking staff what they use, you have a belief about your exposure, not a control over it. And if you have not decided whether your default posture is to block, tolerate or enable, you have already chosen to tolerate everything — unmanaged.


Next Post
Who Pays When the Agent Is Wrong?