I mean, clawbots are inherently insecure. Using a better model is defense in depth.

Obviously you should also take precautions, like never instructing it to invoke the browser tool on untrusted sites, avoiding feeding it untrusted inputs where possible in other places, giving it dedicated and locked-down credentials where possible....

But yeah, at this point it's inherent to LLMs that we cannot do something like SQL prepared statements where "tainted" strings are isolated. There is no perfect solution, but using the best model we can is at least a good precaution to stack on top of all our other half-measures.

The "dedicated and locked-down credentials" point is worth expanding. Most of the discussion here focuses on model robustness, but credential scope matters just as much. An agent running with a full-access API key and a scoped one fail very differently under prompt injection.

The pattern that helps most: agents get session-scoped tokens that map to real credentials stored in a vault. The real key never appears in agent context. If the agent gets injected and leaks its token, the token expires after the session. Blast radius is bounded by design, not by model choice.

How we've implemented this: https://www.apistronghold.com/blog/securing-openclaw-ai-agen...