> No, local models won't help you here, unless you block them from the internet or setup a firewall for outbound traffic.

This is the only way. There has to be a firewall between a model and the internet.

Tools which hit both language models and the broader internet cannot have access to anything remotely sensitive. I don't think you can get around this fact.

https://simonwillison.net/2025/Nov/2/new-prompt-injection-pa...

Meta wrote a post that went through the various scenarios and called it the "Rule of Two"

---

At a high level, the Agents Rule of Two states that until robustness research allows us to reliably detect and refuse prompt injection, agents must satisfy no more than two of the following three properties within a session to avoid the highest impact consequences of prompt injection.

[A] An agent can process untrustworthy inputs

[B] An agent can have access to sensitive systems or private data

[C] An agent can change state or communicate externally

It’s still possible that all three properties are necessary to carry out a request. If an agent requires all three without starting a new session (i.e., with a fresh context window), then the agent should not be permitted to operate autonomously and at a minimum requires supervision --- via human-in-the-loop approval or another reliable means of validation.

Not just the LLM, but any code that the LLM outputs also has to be firewalled.

Sandboxing your LLM but then executing whatever it wants in your web browser defeats the point. CORS does not help.

Also, the firewall has to block most DNS traffic, otherwise the model could query `A <secret>.evil.com` and Google/Cloudflare servers (along with everybody else) will forward the query to evil.com. Secure DNS, therefore, also can't be allowed.

katakate[1] is still incomplete, but something that it is the solution here. Run the LLM and its code in firewalled VMs.

[1]: https://github.com/Katakate/k7

And here we have google pushing their Gemini offering inside the Google cloud environment (docs, files, gmail etc) at every turn. What could possibly go wrong?

Why not just do remote model isolation? Like remote browser isolation. Run your local model / agent on a little box that has access to the internet and also has your repository, but doesn't have anything else. Like BrowserBox.

You interact with and drive the agent over a secure channel to your local machine, protected with this extra layer.

Is the source-code the secret you are trying to protect? Okay, no internet for you. Do you keep production secrets in your source-code? Okay, no programming permissions for you. ;)

How will the firewall for LLM look like? Because the problem is real, there will be a solution. Manually approve domains it can do HTTP requests to, like old school Windows firewalls?

Maybe an XOR: if it can access the internet then it should be sandboxed locally and don’t trust anything it creates (scripts, binaries) or it can read and write locally but cannot talk to the internet?

i like how claude code currently does it. it asks permission for every command to be ran before doing so. now having a local model with this behavior will certainly mitigate this behavior. imagine before the AI hits the webhook.site it asks you

AI will visit site webhook.site..... allow this command? 1. Yes 2. No

The sad thing is, that they've attempted to do so, but left a site enabling arbitrary redirects, which defeats the purpose of the firewall for an informed attacker.

yy