Shadow AI: you can't control what you can't see

Your employees found better tools than the ones you approved. A support agent pastes a customer thread into a chatbot to draft a reply. A developer wires an internal service to an LLM API to summarize logs. Neither filed a ticket. Neither meant any harm. And none of it shows up on a dashboard you own. That is shadow AI: real work flowing to AI tools you did not approve, over paths you cannot see.

You cannot govern egress you cannot observe. The data has usually left by the time anyone asks where it went, and it does not send a postcard.

Why it grows

Shadow AI spreads for the same reasons shadow IT did, only faster. The tools are genuinely useful, so people reach for them. The friction is near zero: a browser tab, an API key, a copy and paste. And there is no visibility, so there is no feedback. A blocked request teaches a person something. A silently successful one teaches them nothing, and they do it again tomorrow with a larger payload.

This is not a discipline problem, and an all-hands about it will not fix it. People route around controls that slow them down. If the approved path is slower than the unapproved one, the unapproved one wins, politely and without telling you.

What actually crosses

The risk is specific. Two kinds of data leave, and two kinds of path let them.

The data is secrets and personal information. API keys, access tokens, and internal credentials get pasted into prompts as context. Customer records, health details, and employee data go along with them because they were in the same document someone wanted summarized. Once that content reaches an unapproved provider, you no longer control where it is stored, how long it is retained, or whether it trains a model.

The paths are worse than a person with a browser. A service that fetches a URL for a user can be steered to fetch an internal one instead. That is server-side request forgery (SSRF), and in a cloud environment it points straight at the instance metadata service. A single crafted request to the IMDS endpoint can return temporary credentials for the machine's role. From there the exfiltration is not a paragraph of text, it is programmatic access to whatever that role can touch. An AI feature that retrieves content from a link is exactly the shape of code that gets abused this way.

Why blocklists and policy PDFs fail

The common answers do not sit where the data crosses, so they fail open.

A blocklist enumerates the providers you know about today. The next tool launches next week, and your list has never heard of it. Blocking known bad names leaves everything unnamed permitted by default, which is the wrong default for a control. Enumerating dangers leaves the next danger undetected by construction.

A policy PDF is a sentence. It tells people what they should not do and then relies on every person remembering it under deadline. Most have not read it, and the ones who have were never going to paste the payroll file anyway. A control that requires a human to remember to run it is not a control. When the acceptable-use document and the actual traffic disagree, the traffic is what ships.

Network egress rules help, but most are written for hosts and ports, not for what is inside the request or which provider sits on the far end. They cannot tell an approved model call carrying a redacted prompt from the same call carrying a private key.

Control at the boundary

The place to make the decision is the boundary itself: the point where a request leaves your environment for an AI tool or an external API. Sit there, and decide what data can reach which destination or provider before anything crosses. This is what the Data Control module in Athena is built to do.

• DLP that fails closed. Inspect the payload for secrets and personal data before it leaves. When a control cannot verify a request is safe, it denies rather than passes silently. Fail-open detection is not detection.
• Egress hard-deny for IMDS and SSRF. Requests toward instance metadata endpoints and internal address ranges are refused at the boundary, so a steered fetch cannot reach the credential path in the first place.
• Rules per destination and provider. An approved model with a data agreement is not the same destination as a consumer chatbot, and the decision is made against which provider is on the far end.
• A sealed record of every decision. Each allow or deny is written to a tamper-evident record you can recompute offline, so what was permitted and what was refused is answerable later, not reconstructed from memory.

None of this claims to stop every leak. A boundary control decides on the traffic it sees, and designing it to fail closed means the failure mode is a blocked request, not a silent one. The record produces candidate evidence for the questions auditors and frameworks like GDPR, HIPAA, DORA, and ISO 42001 ask about where data went. We do not issue legal opinions or grant certification.

Assume shadow AI is already happening in your organisation, because it is. Whether to allow AI tools is a decision your staff took for you some months ago. What is left to decide is where the decision about data gets made: at the boundary, before it crosses, with a record you can check, or nowhere at all. Put the control where the data leaves. Everything upstream of that is a suggestion.