Shadow AI Has Moved to the Device: What "Bring Your Own Model" Means for Security and Data Governance

The security blind spot your IT team built its defenses around no longer exists in the place they're looking. For most of 2024 and 2025, shadow AI meant employees pasting proprietary data into browser-based chat interfaces. Your DLP tools caught some of it. Your URL filters flagged some more. But the 2026 reporting tells a different story: shadow AI has migrated from the browser tab to the local process, from the cloud to the endpoint, from something you could see on the wire to something you cannot. The "Bring Your Own Model" trend is not a forecast. It is already happening on your employees' laptops, and the governance tooling most organizations rely on was never designed to detect it.

Key Takeaways

• Shadow AI usage on corporate devices tripled to 45% in the past year, with two-thirds of that activity occurring through personal accounts invisible to IT, according to the 2026 Verizon DBIR.
• Locally-run quantized models (via tools like Ollama and llama.cpp) generate no network egress event, making them invisible to URL filtering, browser-based DLP, and OAuth audit logs.
• The most common data type flowing into ungoverned AI tools is source code, not PII, which means regulatory-driven DLP programs are looking for the wrong thing.
• Roughly half of all PCs shipping in 2026 are "AI PCs" with dedicated neural processing units, making on-device inference a default hardware capability rather than a niche developer setup.
• Banning local models will fail. The viable path is sanctioned BYOM: give employees a governed, audited local inference option that meets them where they already are.

How Bad Is the Shadow AI Problem Right Now?

Worse than most security teams assume, and the data is unambiguous. The 2026 Verizon DBIR found that employee use of unapproved AI tools tripled to 45% over the twelve-month reporting period. That number alone would be concerning. The structural detail is worse: 67% of those users are accessing AI services from non-corporate accounts on corporate devices, meaning they are completely outside the identity layer your IT team controls.

Shadow AI is now the third most common non-malicious action in enterprise DLP datasets, a fourfold year-over-year increase. And more than 15% of users had unauthorized AI browser extensions installed, extensions that collect and retain browsing context from internal sites, creating an exfiltration pathway that operates independently of traditional DLP controls.

These are the numbers for the shadow AI you can still see. The part you cannot see is the subject of this piece.

What Changed in 2026 That Moved Shadow AI to the Device?

Two things converged: the models got small enough, and the hardware got capable enough.

Quantization techniques (4-bit, 5-bit formats like Q4_K_M and Q5_K_M) have compressed capable open-weight models to the point where a 30-billion-parameter model runs in roughly 18 GB of RAM instead of 60 GB. Tools like Ollama, LM Studio, and llama.cpp have made local inference accessible on consumer-grade laptops. The quality tradeoff is marginal: for chat, coding assistance, and summarization tasks, quantized models are nearly indistinguishable from full-precision versions.

On the hardware side, industry projections from IDC, Canalys, and Gartner converge on a striking number: roughly half of all PCs shipping in 2026 are "AI PCs" with a dedicated neural processing unit, and Gartner projects 100% of new enterprise PCs will carry AI chips by the end of the year. The silicon required to run local inference is no longer a developer luxury. It is standard issue.

One useful nuance here: as of mid-2026, most local-LLM runtimes do not actually route workloads to the NPU. They run on the integrated GPU or CPU. So the NPU hype from PC vendors is somewhat ahead of the software reality. The models still run locally, though. They just use the GPU. The governance gap is identical regardless of which chip does the math.

HPCwire framed this directly: the rise of powerful small language models has moved shadow AI from the cloud to the device, and this "Bring Your Own Model" trend bypasses traditional network firewalls entirely, creating a blind spot for IT departments that rely solely on URL filtering to monitor usage.

Why Can't Existing DLP and URL Filtering Catch Local Models?

Because there is nothing on the network to catch. The architecture of your current defenses assumes a specific threat model: sensitive data leaves the corporate perimeter via an HTTP request to an external API endpoint. URL filtering blocks known AI service domains. Browser-based DLP inspects clipboard content before it reaches a SaaS interface. OAuth inventories track which third-party apps employees have authorized.

A quantized model running via Ollama on localhost has no egress event. No HTTP request to an external domain. No OAuth token. No SaaS audit log. The inference happens entirely within the process space of the employee's machine. Your network security tooling sees nothing because there is nothing to see on the wire.

A June 2026 Delinea analysis described this plainly: a well-meaning developer installs a local LLM on their workstation because "it's faster than waiting for IT." The activity is largely invisible to IT. No cloud service to block. No URL to filter. No browser extension to inventory.

This is not a behavioral problem. It is an architectural one. Your DLP stack was built to monitor egress. Local inference has no egress. The blind spot is structural.

What Makes the Agentic Layer Even More Dangerous?

Local models are concerning. Local models with agentic capabilities and file system access are a different category of risk entirely.

A 2026 analysis from Strac documented what this looks like in practice: engineers standing up local MCP (Model Context Protocol) servers running with no authentication, on localhost SSE transports, accessible to any process on the machine. These servers act as undocumented brokers that can read SSH keys.env files, browser cookies, and Slack DMs, then stream that context to a remote LLM. There is no SaaS audit log recording the tool invocations. The agent is local. The LLM call (if there even is one) may be external, but the context collection happens entirely on the endpoint.

The agentic escalation is significant because it compounds the data exposure. A local chat interface is a one-query-at-a-time risk. A local agent with MCP connectors and file system access can operate autonomously for hours, ingesting context from across the employee's entire working environment. Any employee with a $20/month subscription to a popular desktop agent framework can run this without any visibility from their parent organization.

Why Is Source Code the Real Data Governance Story Here?

Most data governance programs are calibrated around PII and regulated data categories (HIPAA, GDPR, PCI). The DBIR data tells a different story. The most common data type moving into ungoverned AI tools is source code, not PII.

This matters for several reasons. Source code contains business logic, proprietary algorithms, API keys, infrastructure patterns, and sometimes hardcoded credentials. It is intellectual property, and its leakage is largely invisible to regulatory-driven DLP programs because no regulation requires you to report source code exposure the way you report a PII breach. When the "leak" happens locally (a developer pastes proprietary code into a local model's context window), there is no cloud upload to detect, no API call to log. The code and the model's response sit in an unaudited chat log on an unmanaged endpoint.

If your governance program is built around compliance checklists for regulated data types, you are defending the wrong perimeter against the wrong data category using tools that cannot see the channel where the exposure actually happens.

How Are Vendors Responding, and Where Are the Gaps?

The tooling is catching up, but most of it still targets the browser and SaaS layers. Microsoft's Agent 365, which reached general availability around May 2026, focuses on detecting agents running on managed Windows devices via Defender and Intune, letting admins view which devices are running them and apply blocking policies. Delinea's Privilege Manager added pre-built monitoring rules to identify leading AI tools running on endpoints.

These are steps in the right direction. But browser-focused vendors like LayerX, Push Security, and Strac explicitly acknowledge that their visibility stops at the browser and OAuth layer. Local model runtimes fall outside their detection surface. The gap between "we can see what employees do in Chrome" and "we can see what processes employees run on their local machine" is wide, and most organizations have not bridged it.

Endpoint detection and response (EDR) tools could theoretically detect local inference processes, but few have rules tuned for it. Knowing that an employee is running an Ollama process is different from knowing what data that process is ingesting. Process-level visibility tells you the model is running. It does not tell you what the model is reading.

Should You Ban Local Models?

No. You will fail, and you will lose the employees who are most productive.

PagerDuty's 2026 survey found that 66% of office professionals have used AI tools at work despite believing they were not permitted under company policy. Two-thirds of your workforce is already doing the thing you told them not to do. A blanket ban on local models will have the same effect: it will be ignored by the people who most need the tools, and it will push the activity further underground, making it harder to govern rather than easier.

The pattern here is identical to every previous wave of shadow IT. Employees adopt tools because the tools solve a real problem faster than the sanctioned alternative. The organizations that handle this well are the ones that provide a governed version of the thing employees are already doing, rather than pretending prohibition works.

What Does a Governed BYOM Architecture Look Like?

Enterprise software vendors are already building this. UiPath, Palantir, Cribl, and Azure have all rolled out sanctioned BYOM capabilities in 2026, for exactly the reasons employees are doing it themselves: enabling AI within compliance mandates, allowing organizations in air-gapped or internet-restricted environments to run inference within their approved architecture rather than shared infrastructure.

A governed BYOM architecture has a few core properties:

• Approved model weights are distributed through a managed channel, not downloaded ad hoc from Hugging Face.
• Inference processes run in a sandboxed environment with defined file system access, not with the full permissions of the user account.
• Context ingestion is logged. You may not inspect the content of every query (and probably should not), but you know which files and data sources the model accessed.
• Model versions and quantization formats are pinned and auditable.
• Output persistence (chat logs, generated code) follows the same retention and classification policies as any other corporate data.

This is not hypothetical architecture. It is what the enterprise BYOM vendors are shipping. The question is whether your organization adopts a governed version before the ungoverned version becomes entrenched.

Where Does This Leave Us as a Company Building a Privacy-First AI Product?

We think about this problem from a slightly different angle, because we are a product that handles user data for AI inference, and we have to be honest about where the trust boundaries actually are.

At Selina, we route requests through a stack of frontier models, routed per task. That means content is encrypted at rest, but memory is NOT end-to-end encrypted, because a slice of each request reaches a frontier provider at inference time. We state that plainly because the distinction matters. Files and transfers via SelinaSEND are zero-knowledge encrypted. Memory is not. If we blurred that line, you should not trust us with anything else we say.

Non-content operational metadata is kept for a short retention window. Your account is protected. Your content is encrypted. Delete means gone. Actually gone. These are specific, bounded claims, and we are deliberate about not overclaiming beyond them.

Why spell out our own limitations in a blog post about someone else's problem? Because this is the core lesson of the shadow AI phenomenon: employees go around IT when they do not trust the sanctioned tools. And they do not trust the sanctioned tools when vendors make vague, expansive claims about privacy that fall apart under scrutiny. Publishing what you do not do is, in our experience, more useful for building trust than a marketing page full of what you do.

The BYOM trend is driven by a legitimate instinct. Employees want to use AI without sending their data to a cloud service they do not control. The instinct is correct. The execution (unaudited local models with unrestricted file system access) is where the risk lives. The answer is not to fight the instinct. The answer is to build products and architectures where the privacy properties employees are seeking are real, verified, and plainly stated, including the parts that are not private.

What Should You Do This Quarter?

Five concrete things, in order of effort:

1. Inventory your endpoints for local inference runtimes. Check for Ollama, LM Studio, llama.cpp, and similar processes. Your EDR tooling can probably detect process names today if you write the rules. You will be surprised by the count.
2. Audit your source code exposure. Your DLP program is almost certainly oriented around PII. Add source code.env files, SSH keys, and API credentials to your classification taxonomy. These are the data types actually moving into ungoverned AI tools.
3. Assess your MCP surface. If your engineering teams use agentic tools, check for local MCP servers running on developer workstations. These are the highest-risk configuration: unauthenticated, localhost-bound, with broad file system access.
4. Stand up a sanctioned BYOM path. Pick an approved set of model weights. Distribute them through a managed channel. Define a sandboxed runtime with logged context access. Give your employees the thing they are already building for themselves, with guardrails.
5. Rewrite your acceptable use policy. The policy that says "do not use AI tools" is already being ignored by two-thirds of your workforce. Replace it with a policy that says "use these approved tools, in this way, with these data types." Specificity is governance. Prohibition is theater.

The window between "employees are experimenting with local models" and "local models are entrenched, unaudited infrastructure" is closing. You are probably already past the first phase. The question is whether you shape the second one or discover it in an incident report.

If you are rethinking how your own AI interactions are governed, start a free 7-day trial, no card required.

Michael C.

Founder & Principal Engineer, Selina Labs

Michael builds Selina, a privacy-first AI that remembers you across conversations. He ships security-sensitive AI in production — real attacks, real fixes, measured in minutes and dollars — and writes about privacy, security, and LLMs from that seat. Top Rated Plus and expert-verified on Upwork.

• www.upwork.com
• x.com
• medium.com
• selinalabs.io