DEV Community

Cover image for Shadow AI: What Your Team Is Already Pasting Into ChatGPT
Framz
Framz

Posted on • Originally published at framz.io

Shadow AI: What Your Team Is Already Pasting Into ChatGPT

Right now, somewhere in your org, someone is pasting a stack trace, a customer record, or a chunk of the codebase into ChatGPT to get unstuck. You know it. I know it. The person doing it half-knows it's sketchy and is doing it anyway — because it works.

That's shadow AI, and the reason it's so hard to stamp out is that it's not laziness or malice. It's people trying to do their jobs faster. Send the "don't use ChatGPT" email and you don't stop it — you just make it quieter.

So don't start with a ban. Start with knowing what's actually leaving the building.

The four things that leak (roughly in order of how often I see it)

  1. PII. Names, emails, addresses — worse if it's health or financial — tucked inside "help me reply to this customer" prompts. This is the one with legal teeth.
  2. Secrets. API keys, tokens, connection strings, a stray .env, private keys — pasted into "why is this failing?" debugging prompts. High blast radius, and usually the person has no idea it was even in there.
  3. Proprietary code. Internal logic pasted in for a refactor. It doesn't come back out, sure — but you've just handed it to a third party.
  4. Client-confidential stuff. Contracts, engagement letters, case notes. For a regulated firm that's not an "oops," that's a reportable breach.

The one everyone quotes is the reported case of engineers pasting proprietary source into ChatGPT. What made it nasty: the data was just gone, unretrievable, and no DLP tool flagged it — because to a network monitor, an AI chat looks like any other encrypted web request, not a file leaving.

It's a governance problem wearing a tech-problem costume

The reflex is to buy a blocking proxy. But blocking just recreates the original problem: people route around it (personal laptop, phone, copy-paste on their own account), and you lose the productivity you were trying to protect.

The thing that actually holds is a compliant path — an approved way to get the same AI help without the data leaving your boundary — plus a short, human-readable policy on what's fair game and what isn't. And detection, because you can't govern what you can't see.

How to check — without leaking it to check it

You can scan for this yourself: regexes for key formats, entropy for secrets, NER for PII. The irony is that most "paste your text here to check it" tools ship your text off to their server or their model — which is the exact thing you were trying to avoid.

So we built the Shadow AI Data Leak Scanner with one rule we refused to break: it runs on our own hardware, and your text never touches a third-party AI. Paste something in, see the PII, secrets, and code it contains, and whether it's safe for a public model. It's heuristics, not magic — treat it as a fast first pass, not a certificate.

Shipping AI features yourself? The mirror-image risk is your own app getting jailbroken — poke at that with the Prompt Injection Tester.

FAQ

What is shadow AI? Staff using AI tools with no approval or oversight — pasting in whatever gets the job done, usually without clocking that the data leaves the org.

What leaks most? PII in "draft this reply," secrets in "why does this break," code in "refactor this," and client-confidential docs.

How do you stop it without a ban? A compliant in-boundary path, a one-page policy people can actually follow, and detection so it's enforceable.


Honest question for the room: has your company actually written down what's OK to paste into an LLM — or is everyone just quietly winging it? I suspect I know the answer. Tell me in the comments.

Top comments (0)