Threats

Shadow AI: Finding Unsanctioned AI Use

Oconee Runtime TeamPublished 4 min read

Short answer

What is shadow AI, and how do you find it without surveilling people?

Shadow AI is the use of AI tools for company work without the organization's knowledge or approval. It is discovered by instrumenting the surfaces where work happens — browsers and development environments — and recording which AI tools are used, how often, and what categories of sensitive data are involved. Doing that responsibly means recording classifications and metadata rather than prompt contents, so the organization learns its exposure without reading its employees' work.

Definition

Shadow AI
Shadow AI is the use of artificial-intelligence tools or services for organizational work outside approved channels, without security review, procurement, or oversight.

Diagram

From unknown usage to a governed inventory

Each step narrows an unbounded question — 'what AI is everyone using?' — into something an organization can actually answer and then act on.

  1. Step 1

    Instrument the surfaces

    Browser and IDE, where AI tools are actually used, rather than the network perimeter.

  2. Step 2

    Identify the tool

    Which AI service, on which surface, by how many people, how often.

  3. Step 3

    Classify the exposure

    Whether credentials, source code or regulated data are involved — the category, not the content.

  4. Step 4

    Decide and enforce

    Approve, restrict or prohibit each tool, and apply that decision at the surface.

Why network-level discovery finds less than it appears to

The obvious approach is to look at egress: pull the proxy logs, list the AI domains, count the connections. It is a reasonable first pass and it has three structural gaps.

It misses everything off the corporate network, which after several years of hybrid work is most of it. It misses AI capability embedded inside tools that are already approved, where the traffic is indistinguishable from ordinary use of that tool. And it tells you a connection happened, not what went through it — a developer reading documentation and a developer pasting a production database dump produce the same log line.

Instrumenting the surface where the interaction happens closes all three, because the observation point is next to the action rather than several layers away from it.

The privacy constraint is a design input, not an afterthought

A discovery program that reads employees' prompts will be resisted, and in several jurisdictions it creates obligations of its own. It also produces a body of data that is itself a liability: a store of everything the workforce typed into AI tools is a high-value target.

The workable position is to record the facts needed for governance and not the content behind them. That means storing that a credential pattern was detected, not the credential; that source code was involved, not the code; which repository, or a stable identifier for it, rather than its contents.

This is also better engineering. Classification-level records are smaller, retainable for longer, and answer the questions a governance program actually asks.

  • Record: tool, surface, timestamp, user, detection category, severity, policy decision.
  • Do not record: prompt text, model responses, file contents, the matched secret itself.
  • Publish the distinction to the workforce before deployment, not after the first question about it.

What the inventory is for

Discovery is not the goal. The output should be a decision about each tool found: approved, approved with limits, restricted to specific teams, or prohibited. A list nobody acts on becomes stale within a quarter and teaches everyone that the exercise was theatre.

The second output is a baseline. Once usage is measured, the effect of a policy becomes measurable too — whether prohibited tools actually stopped being used, whether blocked attempts fell over time, whether use migrated to an approved alternative or simply went further underground.

Why prohibition alone tends to fail

Shadow AI is overwhelmingly not malicious. It is people using a tool that makes their work faster because no approved equivalent exists or the approved one is worse.

Programs that respond with a blanket ban usually see usage move to personal devices, where the organization has neither visibility nor control — a strictly worse position than the one they started from. The more durable pattern is to approve something adequate, make it easy, and enforce the boundary on the rest.

Examples

  • A marketing team is using an AI writing tool nobody in security has heard of, pasting in unreleased product plans.

    Discovery surfaces the tool and the classification of what reaches it. The decision that follows is a procurement and data-handling question, and it can now be made with the actual usage in front of it.

  • Usage of a prohibited AI service drops to zero on managed machines the week after a policy is announced.

    That is a result worth verifying rather than celebrating. Compare against overall AI usage: a fall in one tool with no corresponding rise elsewhere may mean the work moved to unmanaged devices.

  • Two engineers account for most of the detected source-code exposure in a month.

    Treat it as a workflow signal before a conduct one. Concentrated usage usually indicates a task the approved toolchain handles badly, and the durable fix is upstream of the individuals.

Frequently asked questions

Is shadow AI just shadow IT with a new name?
It is the same shape of problem with a materially different consequence. Unsanctioned SaaS typically creates an access and data-residency problem. Unsanctioned AI additionally means company data becomes input to a third-party system, and, with coding agents, that an unreviewed tool can take actions in your environment.
Do we need to monitor personal devices to get a complete picture?
No, and attempting it usually costs more in trust than it returns in coverage. Instrument what you manage, be explicit that the picture covers managed surfaces, and treat the unmanaged remainder as a policy and culture problem rather than a detection one.
What is the difference between discovery and enforcement?
Discovery answers what is being used. Enforcement decides what happens next time. They are usually deployed in that order, because a policy written before the usage is understood tends to prohibit things nobody does and permit things everybody does.
How do you measure AI usage without identifying individuals?
Most governance questions are answerable at the level of team, tool and detection category. Attribution to an individual is needed for a small number of investigative cases, so it is worth designing access to that layer separately and gating it, rather than making every dashboard identify people by default.

Sources

  • Shadow AI
  • AI governance
  • Data loss
  • Browser AI