Bring Your Own Model: The Shadow AI Threat Your Network Can't See
Meta: Employees are quietly downloading and running powerful AI models directly on their work laptops. No network traffic to monitor. No data leaving the building. No audit trail. Here's why BYOM is the shadow AI blind spot that traditional security tools will completely miss.
---
Picture this: a data analyst at your company downloads Llama 3.3 on a Tuesday afternoon. It takes about ten minutes. The model — a genuinely capable 70-billion-parameter AI — runs entirely locally on their MacBook Pro. They start feeding it customer churn data, internal financial projections, draft contracts. The model processes it all. Your DLP tools see nothing. Your proxy logs are clean. Your CASB reports no anomalies.
Because nothing left the building.
This is the new frontier of shadow AI, and it's catching most organisations completely flat-footed.
Shadow AI just got a whole lot harder to spot
Most enterprise security teams have built their shadow AI defences around a reasonable assumption: if an employee is using an unauthorised AI tool, data has to go somewhere. To OpenAI's servers. To Anthropic's API. To some SaaS platform with a free tier and a privacy policy nobody reads. That outbound data flow is detectable — you can monitor DNS requests, block known AI endpoints, flag unusual API traffic.
But 2026 has handed us a new problem. The models are getting small enough to run locally, and powerful enough to be genuinely useful. Llama 3, Mistral, Phi-3, Gemma — these aren't toy models anymore. They can summarise documents, write code, analyse spreadsheets, draft contracts, and synthesise research. And they run comfortably on a modern laptop with a decent GPU. Or even without one, if you're patient.
The "Bring Your Own Model" trend — BYOM, if you want an acronym — is exactly what it sounds like: employees downloading these models and running them directly on corporate hardware. No cloud API calls. No subscription to flag. No unusual network traffic. Just a process running locally, eating whatever data the employee decides to feed it.
According to recent data, somewhere between 43% and 80% of employees already admit to using unapproved AI tools at work. That number was largely built on cloud-based tools. The local model cohort is smaller right now, but it's the fastest-growing segment — and the hardest to track.
What makes this genuinely different
With traditional shadow AI, the risk model is fairly well understood. An employee pastes client data into ChatGPT, that data potentially goes into a training pipeline, the vendor's data handling becomes your liability. Bad, but at least there's a detectable event.
BYOM breaks that model entirely.
There's no outbound data transfer to detect. The model runs in a local process. If an employee is using [Ollama](https://ollama.com/) — the most popular local model runtime right now — the entire thing looks like any other application running on their machine. Your endpoint security might flag it as unusual software. Or it might not flag it at all, because it's not doing anything traditionally "malicious."
The risks are different in character, not absent:
Uncontrolled local processing of sensitive data. When an employee runs proprietary data through a local model, there's no audit trail. No record of what was processed, what was generated, what conclusions were drawn. If that data includes regulated PII, financial records, or IP — you have a compliance exposure you can't even document, let alone defend.
Model persistence and fine-tuning. Here's the scenario that should keep CISOs up at night: an employee fine-tunes a local model on internal company data. The model literally learns your organisation's patterns, terminology, pricing, strategy. That model then lives on their laptop. When they leave the company, they take it with them.
No governance, no guardrails. Cloud AI providers — the reputable ones — have content policies, output filters, and at least some accountability. A local model has whatever guardrails the developer chose to include, which is often none. Employees using local models to draft communications, generate code, or make recommendations have zero organisational oversight on what's being generated.
Endpoint sprawl. Each local model installation is, effectively, a new AI system operating within your environment. No risk assessment. No acceptable use approval. No vendor evaluation. Just a download and a run command.
Why IT can't just block it
The instinctive response is to block model downloads at the network level or via endpoint management. And yes, you can make it harder. But this approach runs into some uncomfortable realities.
Many local models are distributed through Hugging Face, which is also a legitimate research and development platform used by your data science teams. Blocking it wholesale creates friction for people doing authorised work. The same applies to GitHub, where model weights and tools like Ollama are freely available.
More practically: employees who are motivated enough to run local models are motivated enough to download them on home networks and transfer them via USB, or to use personal devices connected to corporate systems. You're playing whack-a-mole with a technically sophisticated segment of your workforce.
The answer isn't a harder wall. It's better visibility into what's running on endpoints, combined with governance structures that can actually accommodate legitimate local AI use while flagging the risky stuff.
The governance gap is the real problem
Here's the uncomfortable truth: 63% of organisations still lack formal AI governance policies. Of those that have policies, most were written with cloud AI tools in mind. They talk about approved vendor lists, data classification for external tools, acceptable use of SaaS AI platforms.
None of that covers the model running quietly on someone's laptop.
Effective governance for the BYOM era needs to address several things that most current policies don't:
Endpoint-level AI inventory. You can't govern what you can't see. Knowing which AI models are installed and running across your fleet — not just which SaaS tools are being accessed — is the new baseline.
Data handling classification for local inference. Just because data isn't leaving the building doesn't mean its use is uncontrolled. Policies need to specify what categories of data can be processed through local models, and under what conditions.
Approved local tooling. Rather than a blanket prohibition that drives behaviour underground, smart organisations are establishing curated lists of approved local models for specific use cases — and providing legitimate routes for employees to request additions.
Departure procedures. When an employee leaves, standard offboarding processes weren't designed for the possibility that they've fine-tuned a model on your data. That needs to change.
The employees aren't the villains here
It's worth saying: most of the people running local AI models on their work laptops aren't trying to exfiltrate data or circumvent security. They're trying to do their jobs better, often with tools that are genuinely more private than the cloud-based alternatives they might otherwise use.
The analyst who runs sensitive client data through a local Mistral model instead of uploading it to ChatGPT might actually have better privacy instincts than colleagues who haven't thought about it at all. They've identified a legitimate need — AI-assisted analysis — and chosen an option that, in their view, keeps data in-house.
The problem is that "in-house but uncontrolled" isn't the same as "governed and secure." Good intentions don't create audit trails or risk assessments.
The organisations that will handle this well are the ones that meet employees where they are: acknowledging the legitimate productivity value of local AI tools, creating frameworks that allow sanctioned use, and building the visibility to know when the framework is being bypassed.
The organisations that will struggle are the ones treating BYOM as purely a security problem to be blocked, rather than a governance problem to be managed.
What to do now
If your current AI governance programme focuses entirely on monitoring outbound traffic and managing your approved SaaS vendor list, it's time to extend it. Start with an honest assessment of your endpoint landscape — are local AI tools already running in your environment? (Hint: they almost certainly are.)
From there, the work is familiar: classify the risk, build appropriate policies, create legitimate paths for employees who have genuine needs, and build the monitoring capability to detect what's outside those paths.
The models will keep getting smaller and more capable. The barrier to running genuinely powerful AI locally will keep dropping. This trend isn't reversing. The question is whether your governance keeps pace with it.