Shadow AI: Finding the Tools Your Staff Already Pasted Data Into
Blocking it does not work and the data has usually already gone. How to find out what is in use and provide a route people will actually take.
GuardsArm Team
Security Experts
Shadow AI is the same phenomenon as shadow IT, moving faster. Staff use tools that help them do their work, the tools are free and require no installation, and the data goes with them.
The important difference from shadow IT is what gets shared. Nobody pasted a patient record into an unapproved project management tool. People paste them into a chat assistant, because that is how the tool is used.
What is actually being shared
From the incidents and assessments that surface this, consistent patterns:
- Customer and patient information pasted in for summarisation or rewording
- Source code, for debugging or explanation
- Contracts and commercial terms, for review or comparison
- Internal strategy documents, for summarisation before a meeting
- Personal information of staff, in HR contexts
- Credentials, occasionally, embedded in a pasted configuration file
The motivation is never malicious. It is somebody trying to finish a task faster, which is exactly why prohibition alone does not work.
Finding it
Network and proxy logs show which services are being reached, and from how many users. This is the fastest route to a factual picture.
Expense and card records surface paid subscriptions bought individually.
Browser extension inventory on managed devices shows tools embedded into everyday workflows, which are the ones handling the most data.
Just asking works better than expected when framed as understanding rather than enforcement. Staff will tell you what helps them if they do not expect a sanction.
Identity logs reveal sign-ups using work email addresses.
Why blocking fails
It fails for three reasons, each sufficient on its own:
- Personal devices. Blocking on the corporate network moves the activity to a phone, where you have no visibility at all and the same data still goes.
- The need is real. The tool was solving a genuine problem. Removing it without an alternative leaves the problem.
- New services appear constantly. A blocklist is out of date the week it is written.
Blocking has a place — for specific services with genuinely unacceptable terms — but as a whole strategy it converts a visible problem into an invisible one.
What works instead
Provide a sanctioned option. An enterprise arrangement with defined data handling, ideally one where inputs are not used for training, removes most of the demand. People use the approved tool when it is as good and as easy.
Write a policy about data, not about tools. Tools change weekly; categories of data do not.
| Data category | Guidance |
|---|---|
| Public or already published | No restriction |
| Internal, non-sensitive | Sanctioned tools only |
| Customer, patient or personal information | Sanctioned tools with appropriate terms, or not at all |
| Regulated data — health, financial, CUI | Only where a specific assessment permits it |
| Credentials, keys, secrets | Never, anywhere |
Train on the specific mistake. Most staff do not know that inputs may be retained or used for training. That single fact changes behaviour more than a policy document.
Review contractual terms for the tools you do approve — retention, training use, sub-processors, deletion, and where processing occurs. For Canadian organisations that last point interacts directly with Quebec Law 25 transfer rules and PIPEDA accountability.
If sensitive data has already gone
Assume it has. Practical response:
- Establish what was shared and by whom, without making it a disciplinary exercise, or you will not learn anything
- Check the provider's terms on retention and training use, and whether deletion can be requested
- Assess whether it constitutes a privacy breach under your applicable regime. See breach notification in Canada
- Rotate any credentials that were exposed
- Fix the underlying need so it does not recur
Writing a policy people will follow
Most AI policies fail because they are written to be defensible rather than to be used. A usable one is short and answers the questions staff actually have:
| Question staff ask | What the policy should say |
|---|---|
| Can I use this at all? | Yes, here is the approved tool and how to get it |
| What can I put in it? | The data categories, with examples from our work |
| What if the approved tool cannot do what I need? | Here is who to ask, and they will answer quickly |
| Do I have to say I used it? | Where output is client-facing or clinical, yes |
| What happens if I get it wrong? | Tell us; we will help, not discipline |
That last row does more work than the rest combined. A policy that promises sanctions produces silence, and silence is how a paste of customer data becomes a breach nobody reports for six months.
Review it on a short cycle
Unlike most policies, this one ages in months. New features appear inside software you already own, vendor terms change, and the approved tool gains or loses capability.
A quarterly review that checks three things is enough: what new services are appearing in the logs, whether the approved tool still meets the demand, and whether any vendor terms have changed materially. See AI vendor risk.
Where to start
Pull a month of proxy or DNS logs and count distinct AI services reached, and by how many users. It takes an afternoon and it converts an argument about policy into a conversation about a number.
GuardsArm helps organisations assess AI use and build workable policy. See security programme reviews or book a scoping call.
Written by GuardsArm Team
Our team of cybersecurity experts brings decades of combined experience in penetration testing, compliance auditing, and incident response. We're dedicated to helping organizations strengthen their security posture.
Take the next step on this topic
Talk to the GuardsArm team about how these services apply to your environment.
