Running Local Doesn't Make You Immune to Prompt Injection. Here's What It Actually Buys You for Privacy.

The premise sounds reasonable: run inference on your own hardware, keep data on your own disk, and privacy problems disappear. The EU AI Act's full enforcement for high-risk systems arrives August 2026, data-residency pressure is real, and local-LLM adoption is surging. But somewhere between "my data never leaves my machine" and "I'm secure," the industry skipped a step. Local deployment solves one problem (where data travels) while leaving the other problem (what a compromised model does with its instructions) completely intact. These are two different threat models, and conflating them is becoming genuinely dangerous.

Key Takeaways

• Prompt injection is an architectural flaw in how LLMs process instructions and data. It exists regardless of whether inference runs locally, in a private cloud, or on a frontier provider's API. Local deployment removes the exfiltration destination, not the vulnerability itself.
• Brave's security research demonstrated real-world indirect prompt injection attacks succeeding against both cloud-based and on-device AI agents, confirming that "local" does not equal "injection-proof."
• OWASP ranks prompt injection as the #1 risk in its 2025 Top 10 for LLM Applications and recommends defense-in-depth (least-privilege tooling, input/output filtering, human approval for high-risk actions) rather than any single deployment choice.
• The EU-driven rush to local and sovereign AI often solves for compliance, not for attackers. Data residency and data sovereignty are different things, and both are different from architectural security.
• What local deployment actually buys you: a narrower blast radius. An attacker who successfully injects cannot phone home to an external server as easily. But a compromised local agent with file, shell, or email access can still act maliciously on-device.

What Is Prompt Injection, and Why Doesn't Deployment Location Fix It?

Prompt injection exploits a structural inability in LLM architectures to enforce a hard boundary between instructions and data. When you ask a model to summarize a webpage, process a PDF, or act on an email, the content of that document enters the same context window as your instructions. If an attacker embeds a malicious instruction inside that content, the model may follow it. This is not a bug in a specific product. It is a property of how transformer-based language models process sequences. The Futurum Group's June 2026 analysis puts it flatly: no deployment model is immune.

Running inference on your own GPU does not change the model's inability to distinguish "this is a user instruction" from "this is an attacker instruction embedded in a document." The weights are the same weights. The attention mechanism is the same attention mechanism. The context window does not gain a permission system because you compiled the model from source on a Linux box in your basement.

What Does the Research Actually Show About Local LLMs and Injection?

The clearest evidence comes from Brave's security team, whose disclosure series across 2025 tested AI-powered browser agents in real-world conditions. Their initial disclosure on Perplexity's Comet browser showed that the agent's core flaw was its inability to differentiate between user commands and untrusted webpage content. When asked to summarize a page, it fed part of that page to the LLM, letting attackers inject payloads the AI executed as commands. Their follow-up research confirmed this was not an isolated implementation mistake. As Brave's own summary states, indirect prompt injection hits cloud and on-device LLMs alike.

Trail of Bits ran a formal pre-launch audit of Comet and found four distinct prompt injection techniques that could exfiltrate private Gmail data. This was a professional threat-modeling engagement, not opportunistic poking. The techniques worked because of how the agent processed untrusted input, not because of where inference ran.

Quantitative data from independent evaluations reinforces this. Researchers measuring instruction-data separation across models found that all tested models exhibit low levels of instruction-data separation, with one widely used frontier model scoring only 0.208 on their separation metric. A score of 1.0 would mean the model perfectly distinguishes instructions from data. 0.208 means it barely tries. Running that model on your own hardware does not change that number.

How Bad Is the Attack-Success Rate in Practice?

Worse than most people assume, especially over repeated attempts. Research analyzing system card data from a frontier model provider showed that indirect prompt injection attack success in agentic coding environments reached 4.7% on a single attempt, 33.6% at ten attempts, and 63.0% at one hundred attempts. Think about what that means for an always-on agent. A 4.7% per-attempt success rate sounds manageable until you realize that a persistent attacker, or an automated payload embedded in a commonly visited resource, gets many more than one shot.

The 2025 International AI Safety Report corroborates this: even when attackers are given just ten attempts, attacks still succeed roughly half the time. These numbers come from frontier, heavily-guarded, cloud-hosted models with extensive safety training. A local open-weights model with less safety work is unlikely to perform better.

Why Does OWASP Rank This as the #1 LLM Risk?

Because there is no fix baked into the model itself. The OWASP Top 10 for LLM Applications (2025) lists prompt injection at the top for a second consecutive edition. Their recommendation is defense-in-depth: least-privilege tooling, input/output filtering, human approval gates for high-risk actions, and regular adversarial testing. Not "run it locally." Not "fine-tune it more." Not "use RAG to constrain it." As a separate arXiv analysis of AI-assisted development tools notes, neither RAG nor fine-tuning fully mitigates the vulnerability.

OWASP also released a separate Top 10 specifically for agentic AI systems in late 2025, reflecting that the attack surface for agents that autonomously plan, decide, and execute multi-step tasks is categorically different from a simple chatbot. When your agent can read files, send emails, execute code, and call APIs, a successful injection is not just an embarrassing wrong answer. It is an unauthorized action taken with your credentials.

What Does Local Deployment Actually Buy You?

A narrower blast radius. This is real and it matters, but it is not what most people think they are getting.

When inference runs locally, a successful prompt injection cannot easily exfiltrate data to an attacker-controlled external server. The model has no built-in outbound connection to phone home through. This genuinely reduces one category of harm: the "steal your data and send it to an attacker's server" scenario becomes harder (not impossible, if the agent has network access, but harder).

What local deployment does not prevent: a compromised local agent with file system access can still delete files, modify documents, or overwrite configurations. An agent with email access can still send messages on your behalf. An agent with shell access can still execute arbitrary commands. An agent connected to your local network can still reach other devices. The attacker's injected instruction executes with whatever permissions the agent already has. Local inference does not reduce those permissions. Defense guidance specific to local LLMs converges on the same conclusion: sandboxing, least-privilege access, and output validation are required regardless of deployment topology.

Think of it this way. A guard who cannot be bribed into mailing your files to a stranger can still be tricked into shredding them.

Is the EU AI Act Driving a "Local Equals Safe" Misconception?

Yes, and the mechanism is straightforward. With full enforcement for high-risk AI systems arriving August 2026, organizations across Europe are scrambling to ensure data residency compliance. Compliance guides for EU data residency correctly note that keeping data within EU borders satisfies one set of regulatory requirements. But a 2026 EU compliance guide from Hymalaia warns that a company can achieve data residency without achieving data sovereignty. If an AI workload runs on a US provider's European data center, data may reside in the EU but still fall under US legal jurisdiction.

This is structurally the same category error as conflating "local" with "injection-proof." Fixing where does not fix how. Fixing the geographic location of your data does not fix the architectural behavior of the model processing that data. A Futurum Group survey of 820 decision makers found 53% of organizations cite privacy and security as their top GenAI adoption challenges, but the concern is often directed at deployment location rather than architecture.

Compliance leaders who conflate residency with sovereignty routinely build architectures that satisfy auditors on paper but fail under legal scrutiny. Security leaders who conflate local with injection-proof build architectures that satisfy their intuition but fail under adversarial testing.

What Does Defense-in-Depth Actually Look Like for LLM Agents?

It looks like layers, each catching what the previous one missed. No single layer is sufficient. Here is a concrete breakdown:

Least-privilege tooling. The agent should have access only to the tools and permissions it needs for the current task, and no more. If the user asks for a document summary, the agent should not have shell access during that interaction. This limits what a successful injection can do.

Input filtering and sanitization. Scan incoming content for known injection patterns before it enters the context window. This catches unsophisticated attacks but will not catch novel or obfuscated payloads. Even purpose-built defense products are not airtight: independent evaluation of one commercial prompt injection classifier showed it scores only about 92.5% on its own benchmark, meaning roughly 7.5% of malicious inputs get through.

Output validation. Check the model's proposed actions against a policy before executing them. If the model proposes sending an email, deleting a file, or making an API call that was not part of the user's explicit request, flag it.

Human approval for high-risk actions. Some actions (sending money, deleting data, accessing credentials) should require explicit human confirmation regardless of what the model thinks the user wants. This is the last line of defense and the hardest one for an attacker to bypass.

Adversarial testing on a regular cadence. Not once before launch. Continuously. The attack surface evolves as models update, as tools are added, and as new injection techniques are discovered. Security guidance for developers in 2026 emphasizes that static defenses degrade over time.

Does Fine-Tuning or RAG Help?

Partially, and less than you would hope. Fine-tuning can make a model slightly more resistant to known injection patterns by training it to recognize and refuse them. But an attacker who knows the model was fine-tuned against pattern X will try pattern Y. RAG constrains the model's knowledge base but does not constrain what it does when injected instructions appear in retrieved documents. In fact, RAG can make things worse: if your retrieval pipeline pulls in a poisoned document, the injection payload arrives with the apparent authority of your own knowledge base. The OWASP guidance is clear that neither approach is a standalone mitigation.

How We Think About This at Selina

We build a personal AI assistant. People tell it things they would not tell their therapist. The threat model for that kind of product is different from a coding assistant or a search engine. We spent a long time thinking about what "safe" means when the product's entire value proposition depends on remembering context about a person's life.

We do not run inference locally. We use a stack of frontier models, routed per task. That means a slice of each request reaches a frontier provider at inference. Memory is encrypted at rest, but memory is NOT end-to-end encrypted. We state this plainly because the honest limit matters more than a comforting fiction. Files and transfers via SelinaSEND are end-to-end encrypted, zero-knowledge. Memory is not. That distinction is real, and we think users deserve to know it rather than guess.

Operational metadata is kept for a short retention window, not permanently, but also not zero. Your account is protected. Your content is encrypted.

On the injection side, we treat prompt injection as an ongoing adversarial problem, not a checkbox. We apply defense-in-depth: input filtering, output validation, tool-permissioning that scopes what actions the model can take in a given context, and automated bounding of potentially harmful operations. We do not claim these defenses are perfect. No one's are. The 92.5% benchmark score for a purpose-built injection classifier tells you everything about the state of the field. What we do claim is that we treat injection resistance as an operational concern (continuous testing, continuous improvement) rather than a deployment decision you make once.

The reason we bring this up is not to sell you on our approach over local inference. It is because the decision tree most people use is wrong. They ask, "Should I run local or use a cloud provider?" when the real question is, "What happens when the model follows an attacker's instructions instead of mine, and what systems are in place to limit the damage?" If your local setup has no answer to that second question, you have privacy without security. Which is like having a lock on your front door but no walls.

What Should You Actually Evaluate When Choosing an AI Stack?

Start with the threat model, not the deployment topology. Ask these questions:

1. What tools and permissions does the agent have? More tools equals more blast radius if injection succeeds.
2. What happens when the model proposes an action the user did not request? Is there a validation layer, or does it execute immediately?
3. How is untrusted content (webpages, documents, emails) separated from user instructions in the prompt? If the answer is "it's all in the same context window with no separation mechanism," you have the standard vulnerability.
4. What is the adversarial testing cadence? If the last red-team was before launch, the defenses are already stale.
5. Does the system enforce least-privilege per task, or does the agent always have full access to everything?

These questions apply equally to a 7B parameter model running on your laptop and to a frontier model accessed via API. The answers matter more than the IP address of the inference server.

Two Threat Models, One Confused Industry

The exfiltration-destination problem and the instruction-following problem are genuinely different. Local deployment addresses the first. Defense-in-depth addresses the second. Neither addresses both. The industry's current conversation treats them as one problem, and the result is that organizations are making deployment decisions based on a threat model that does not match their actual risk.

If you are adopting local inference for data residency compliance, do that. It solves a real regulatory requirement. If you are adopting local inference because you believe it makes prompt injection impossible, you are solving for the wrong threat. The attack surface exists in the architecture, and it follows the model wherever you run it.

Local narrows the blast radius. It does not close the wound. Know what you are buying and build accordingly.

If you want to try a personal AI that treats both problems as real, 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