A marketing team needs an AI chat demo for a campaign pitch. A developer stands it up on a spare subdomain over two afternoons, wires it to an LLM provider, and the pitch goes well. Six months on, the subdomain still resolves. The framework behind it has not been patched since the day it was built, the API key is still live, and no change request was ever raised, so the asset appears in no inventory anywhere. That is shadow AI, and no amount of policy writing will find it.

Most coverage of shadow AI measures it from the inside: proxy logs, CASB blocklists, SaaS discovery tools, anonymous staff surveys. Useful, but partial. This article looks at the problem from the public internet, from the same position an attacker occupies, and sets out the external signals that show unapproved AI use is already happening in your organisation.

What Shadow AI Actually Looks Like in a UK Organisation

Shadow AI is any use of artificial intelligence tooling that sits outside your approval, procurement and security processes. The definition has to go further than personal ChatGPT accounts, because that is the smallest part of it.

  • Personal accounts on consumer AI platforms, used from home networks and personal phones.
  • Browser extensions that summarise, rewrite or transcribe, often with permission to read page content.
  • AI features switched on inside SaaS you already approved, where the data processing terms changed under a product update rather than a contract review.
  • Developer API keys for LLM providers, created on a corporate card or a personal one, used in scripts and prototypes.
  • Self-hosted models, vector databases and notebook servers running on cloud accounts nobody is tracking.
  • AI-built prototypes and internal tools that were demoed once and never decommissioned.

Surveys keep finding far more AI usage than IT departments believe exists. That gap is not primarily a compliance failure. It is a discovery problem. People are not hiding this work; they are doing it in places your tooling does not reach, and nobody asked them to register it.

Three Risk Categories Worth Separating

Lumping everything together produces a report the board cannot act on. Split findings into three categories: data leaving the organisation, new internet-facing assets appearing on your perimeter, and new third parties entering your supply chain. Each one has a different owner, a different fix and a different timescale.

Shadow AI overlaps heavily with classic shadow IT, and most of the playbook carries across. The genuinely new element is volume and sensitivity moving in a single action. A staff member can paste a full customer export, a draft contract or a board pack into a free-tier tool in about four seconds, with no file transfer, no email and no DLP event on an unmanaged device.

Why Internal Controls Miss Most of It

Proxy and CASB blocklists only see managed devices talking to known domains. Personal phones on 4G, home broadband, contractor laptops and BYOD tablets all sit outside that view. So does the finance lead signing up to an AI meeting-notes tool from a hotel room.

New AI services launch faster than any blocklist updates, and a growing share of them are not standalone services at all. They are features inside products you already approved, which means your allow-list is quietly expanding without a single procurement decision.

Here is the position worth taking: blocking the obvious platforms buys you quiet logs, not lower risk. When the well-known services are blocked, usage moves to smaller tools with thinner security documentation, vaguer retention policies and no meaningful route to a data processing agreement. You have not removed the behaviour. You have pushed it somewhere you cannot see and the supplier is worse.

Seven External Signals That Reveal Unapproved AI Use

Everything below is visible from outside your network, which means it is visible to attackers performing external reconnaissance on your organisation right now.

1. AI-Themed Subdomains and Demo Environments

Enumerate your subdomains and look for prefixes such as chat, assistant, copilot, llm, rag, bot, agent, ai and demo. Then check each one against your change records. Anything that resolves but was never requested is a prototype that outlived its project. These are textbook attack surface drift: live, unpatched, unowned, and often running a framework that has shipped several security releases since the day it was deployed.

2. Exposed Model Endpoints, Vector Databases and Notebook Servers

Inference endpoints published without authentication, vector stores reachable on their default ports, and Jupyter or similar notebook servers left open to the internet all turn up in routine scanning of cloud ranges. The vector database matters more than teams expect, because it frequently contains chunks of the exact internal documents the prototype was built to search.

3. Leaked AI Provider Keys in Stealer Logs and Paste Sites

API keys for LLM providers are an attractive resale item, because unlike most stolen credentials they carry billable compute that can be used immediately and anonymously. A key harvested by infostealer malware on a developer's personal laptop, or committed to a public repository during a rushed demo, often gets used until the invoice flags it. The mechanics of how stolen AI keys get found and monetised are worth understanding before you decide where these sit in your queue. Treat any credential tied to an AI platform as a priority triage item, not another line in a monthly credential report.

4. Corporate Email Addresses Registered on AI Platforms

Breach data and OSINT routinely show which services a domain's email addresses have been registered against. Developer forum posts, repository activity and community profiles add more. When fifteen @yourcompany.co.uk addresses appear against three AI platforms you have never heard of, you have your answer about adoption rates without running a single survey.

5. Shared Prompts, Public Projects and Demo Links

AI platforms encourage sharing. Public chat links, published projects, template galleries and social posts showing off a workflow regularly contain internal process detail, system prompts referencing real systems, client names and occasionally live data. Staff share these with pride, not malice, which is why they are easy to find.

6. Typosquat and Lookalike Domains Imitating AI Brands

Impersonation domains have followed AI brand popularity closely. The landing page is a convincing sign-in form, the harvested credentials get replayed against corporate SSO, and payment details are collected on the way through. The reason this works better than standard brand phishing is simple: your people are already signing up to unfamiliar AI services with unfamiliar domains, so the instinct that says "that URL looks wrong"is weaker than normal.

7. New AI Vendors in Supplier Footprints and Job Adverts

Your own job adverts and supplier-facing pages give this away. A role asking for experience with a named AI platform, or a case study mentioning an AI tool that appears nowhere in your vendor register, tells you a procurement decision happened somewhere other than procurement.

Running a Shadow AI Discovery Sweep in 30 Days

Week One: Ownership, Then Mapping

Confirm which domains, IP ranges and cloud accounts are genuinely yours before anything is scanned. Scanning an asset that looks like yours but belongs to a former subsidiary, a partner or a namesake is both unlawful and embarrassing, and the conversation afterwards is not one you want. Set your scanning boundaries in writing, then map everything internet-facing: domains, subdomains, IP addresses, cloud services, APIs and regional assets that the central team may not know exist. Compare the result against your last inventory and work the drift.

Week Two: Credential and Token Exposure

Pull leaked credential and token exposure for your domains, then triage anything tied to AI platforms, cloud providers or developer tooling ahead of the rest. Coverage matters here, and most teams have gaps they have never tested; the common blind spots in leaked credential monitoring apply directly to this sweep.

Week Three: People and Executive OSINT

Run an OSINT pass across employees and executives, separating corporate identities from personal accounts before anyone is accused of anything. The purpose is exposure mapping, not performance management, and framing it that way from the start protects the whole exercise.

Week Four: Group Findings by Owner

Do not issue a flat list of alerts. Group findings into remediation projects with a named owner: the cloud team gets the exposed endpoints, the development lead gets the keys, procurement gets the unassessed vendors. At the same time, agree a route for sanctioned AI use, because the next tool arrives in a fortnight and it needs somewhere to be registered.

Fixing What You Find Without Turning It Into a Witch Hunt

Triage in this order: internet-exposed AI assets first, then live credentials and keys, then data-sharing behaviour, then policy gaps. An unauthenticated inference endpoint is an active route in. A staff member using a summariser is a conversation.

For AI-branded lookalike domains, collect evidence properly before you act: registrar details, hosting provider, screenshots of the phishing page, timestamps, any associated mail records. Takedowns succeed through registrar and host abuse processes with a documented case, not a single email fired into an abuse inbox and forgotten.

Handle executive findings separately and discreetly. Senior people trial new AI tools with the least oversight and the most sensitive material, and they are the highest-value phishing targets you have. Those findings belong in people and VIP monitoring, raised privately, not in a general report circulated around IT.

One more thing that quietly destroys credibility: duplicate findings. Dual scanning across infrastructure and web applications will surface the same AI-built prototype twice, once as an open port and once as an application issue. Without deduplication and auto-resolution, the shadow AI report lands in front of the board with inflated numbers, and a single challenged figure undoes the whole paper. The same discipline applies to automated triage generally, which is where understanding what an AI security analyst tool can and cannot do saves you from a different kind of noise.

Governance That Survives Contact With Real Users

An allow-list with a fast route to approval beats a ban nobody follows. If a request for a new AI tool takes six weeks, people will route around you, and your next discovery sweep will prove it.

For vendor checks, ask four questions and insist on written answers: is there a training opt-out and is it on by default, what is the retention period for prompts and outputs, who are the sub-processors, and where is the data processed. Pasting customer records into a consumer AI tool is a processing decision, usually with no lawful basis identified, no DPIA and no processor contract behind it. The ICO's guidance on AI and data protection is the reference point for UK organisations, and the NCSC's assessment of large language model risk is a short read worth circulating to engineering. The pattern of everyday mistakes that cause reportable incidents is well documented in ICO breach reporting data, and prompts are simply a new place for an old error to happen.

Annual audits will not hold this. Prototypes and AI subdomains appear between reviews and disappear from memory long before the next one, so continuous asset monitoring with change detection is what keeps the picture current. Four metrics are worth reporting: new unapproved AI assets discovered, time to remove exposed endpoints, credential exposures closed, and AI vendors moved from shadow use into assessed, contracted use.

Shadow AI is an attack surface discovery problem before it is a policy problem. If you want to see what attackers can already see across your domains, cloud estate and people, start with an external view of your organisation's internet-facing footprint and work from the evidence rather than the survey.

Frequently Asked Questions

What is shadow AI, and how is it different from shadow IT?

Shadow AI is the use of AI tools, models and APIs outside your approval and procurement processes. It is a subset of shadow IT, and most of the discovery techniques are the same. The difference is the speed and sensitivity of data movement: a single paste can send an entire customer file to a third party, and AI features now appear inside software you already sanctioned.

Can you detect shadow AI without monitoring employee devices?

Yes, and in many organisations external detection finds more than endpoint tooling does. Subdomain enumeration, exposed endpoint discovery, leaked credential and token monitoring, OSINT on corporate email addresses and lookalike domain tracking all operate from outside the network. That coverage includes personal devices, home networks and contractor laptops, which internal controls never see.

What are the biggest security risks of unapproved AI tools?

Three stand out: sensitive data processed by a supplier with no contract, retention terms or DPIA behind it; new internet-facing assets such as prototypes, inference endpoints and vector databases left live and unpatched; and credential exposure, particularly AI provider API keys that attackers can monetise directly.

How do leaked AI API keys end up on the dark web?

Usually through infostealer malware harvesting credentials and environment files from a developer machine, or through keys committed to public repositories, paste sites and misconfigured storage. They trade quickly because they carry billable compute, which means the attacker gets immediate value without needing to reach your network at all.

Should we block AI tools outright or approve a short list?

Approve a short list with a genuinely fast approval route. Blanket blocking moves usage to smaller services with weaker data handling and removes your visibility entirely. A maintained allow-list, clear rules on what data may never be pasted into any tool, and continuous external monitoring for new AI assets will reduce real risk more than a ban that staff quietly work around.