Local LLM Prompt Injection: Why Ollama Agents Get Hijacked

Bottom Line

• A local model has no provider safety filter. The OpenClaw docs say this directly: “Local models do not provide hosted providers’ safety filters.”
• Small models are the easiest to hijack. OpenClaw’s prompt-injection guide says: “Do not use older/weaker/smaller tiers for tool-enabled agents or untrusted inboxes.”
• The attacks are real. A GitHub issue made agents leak private repos. A hidden Morse-code message drained a wallet. A fake MCP server copied every email it sent.
• The fix is to remove one leg of the “lethal trifecta”: private data, untrusted content, or a way to send data out.
• In OpenClaw, five settings do most of the work. They are in the config block below.

Why a Local Model Changes the Risk

When you use a hosted model, the provider runs its own filters before and after the model. Those filters are not perfect, but they are one more layer.

When you point OpenClaw at Ollama, llama.cpp or LM Studio, that layer is gone. The OpenClaw local-models page says “local models skip provider-side filters” and gives one instruction: “Keep agents narrow and compaction on to limit the damage from prompt injection.”

Two more facts make the default setup riskier than people expect:

• Sandboxing is opt-in. With sandbox mode off, host=auto resolves to the gateway host. The agent runs commands on your real machine.
• Agent-to-agent messaging is on by default. An empty allow list permits every agent pair.

Most people who run a local model also give it file and shell tools, because local is “private”. Private is not the same as safe. Your data stays home, but an injected instruction runs there too.

The Lethal Trifecta

Simon Willison named the dangerous combination. An agent is exposed when it has all three:

One injected sentence in the untrusted content can use the other two legs. Remove any one leg and that attack fails. That is the whole strategy.

Real Attacks, Not Theory

None of these needed a model jailbreak. They used the permissions the agent already had.

The OpenClaw Settings That Contain It

This block combines the OpenClaw hardened baseline with the prompt-injection guidance for small models:

{
  agents: { defaults: { sandbox: { mode: "all", workspaceAccess: "ro" } } },
  tools: {
    deny: ["web_search", "web_fetch", "browser"],
    fs: { workspaceOnly: true },
    exec: { security: "deny", ask: "always", strictInlineEval: true },
    elevated: { enabled: false },
    agentToAgent: { enabled: false },
  },
}

What each line does:

1. sandbox.mode: "all" runs every session in the sandbox, so host=auto no longer means your real machine.
2. workspaceAccess: "ro" mounts the workspace read-only. Use "none" (the default) if the agent does not need your files.
3. deny: [web_search, web_fetch, browser] removes the main source of untrusted content and the main way data leaves. The OpenClaw guide says to disable these on small models “unless inputs are tightly controlled.”
4. exec.ask: "always" puts you in front of every command. strictInlineEval makes python -c and node -e style commands need approval even if you allowlist the interpreter.
5. agentToAgent.enabled: false stops one compromised agent from handing work to another.

Check the result with openclaw security audit and openclaw policy, which the OpenClaw security docs list for checking drift and testing the tool policy.

When the Agent Must Read the Web

Sometimes the job is to read untrusted content: summarize email, triage issues, research a topic. Use the reader agent pattern from the OpenClaw docs:

1. A separate agent with no tools, or read-only tools, reads the untrusted content and writes a summary.
2. Your main agent, which has tools, reads only the summary.

The summary is still untrusted. The docs warn that it can still carry an injected request. The pattern reduces the risk; it does not remove it. Keep exec approval on in the main agent.

Should You Use a Bigger Model?

Yes, if the agent has tools and reads untrusted input. OpenClaw’s guidance is to use the best-tier model for those agents. On local hardware, that means the largest model you can run at a usable speed, not the fastest small one.

Our best local models for OpenClaw page ranks models by tool-calling ability. A bigger model does not replace the settings above. The Bankr loss happened with a frontier model. The fix there was authorization, and it is the same fix here.

Honest Caveats

1. We did not run a red-team test against specific local models. The claims about small models come from the OpenClaw docs, not our measurements.
2. Config keys change between OpenClaw versions. Check the current docs, linked below, before you paste the block.
3. exec.security: "deny" blocks shell commands. If your agent needs a shell, keep ask: "always" and use an allowlist instead.
4. The download count for postmark-mcp is The Hacker News’ total, not a weekly figure.

Sources

• OpenClaw: local models: no provider filters, “keep agents narrow”
• OpenClaw: prompt injection: small-model guidance, sandbox opt-in, reader agent, agentToAgent, strictInlineEval
• OpenClaw: hardened baseline: exec, fs and elevated settings
• OpenClaw: tool permissions: sandbox scope and workspaceAccess values
• OpenClaw: security overview: openclaw security audit, openclaw policy
• Invariant Labs: GitHub MCP vulnerability: private repo leak via an issue
• Cointelegraph: Grok and the Bankr wallet: Morse-code injection
• The Hacker News: first malicious MCP server: postmark-mcp
• Orca Security: s1ngularity: AI CLIs abused for secret hunting
• The Hacker News: 341 malicious ClawHub skills: ClawHavoc

See Also

• AI agent security with Docker: what a container does and does not isolate
• OpenClaw security checklist: the full hardened config, line by line
• Binance lost $6.3B through one laptop: agents near exchange keys and wallets
• How to run OpenClaw free and offline with Ollama: the local setup this page hardens
• Muse Glimmer + OpenClaw offline: a local agent model that calls tools well