Security

[autumn junco]

What’s stopping someone from trying to prompt inject into my openclaw and getting the api key or system prompt?

[shy bronze]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[mellow nest]

Short version: prompt injection is a real risk, but it is not supposed to magically expose API keys or the system prompt by itself.

What helps:

• The model does not normally receive raw API keys as prompt text. Secrets should live in auth profiles/env/SecretRefs, not in AGENTS.md, MEMORY.md, pasted prompts, or workspace files.
• System/developer instructions are higher-priority than user/web/attachment text, and OpenClaw wraps extracted external content as untrusted content.
• Tools are policy-gated: if the agent cannot read arbitrary files/env or send arbitrary outbound messages, an injected instruction has much less blast radius.
• Gateway/channel auth, pairing/allowlists, tool allowlists, sandboxing, workspaceOnly, exec approval settings, and secret redaction are the practical controls.

The important caveat: if you let untrusted people talk to one powerful tool-enabled personal agent, they share that agent’s delegated authority. Prompt injection can try to make it use whatever tools it already has. So the answer is mostly “least privilege,” not “the prompt is impossible to trick.”

Hardening I’d do: keep public/team agents separate from personal ones, don’t put secrets in prompts/files, disable exec/filesystem/browser unless needed, use allowlists/pairing, and run openclaw security audit after config changes.

Docs: https://docs.openclaw.ai/gateway/security and the FAQ section on prompt injection: https://docs.openclaw.ai/help/faq#is-prompt-injection-only-a-concern-for-public-bots

[autumn junco]

How do you safeguard public bots?

[mellow nest]

For a truly public bot, I’d treat it as hostile input by default and design for blast-radius containment, not “the prompt will resist everything.”

Practical baseline:

• Run it as a separate OpenClaw gateway/agent, ideally separate OS user/VM/container.
• Use dedicated bot accounts/credentials only. Never sign it into your personal Google/GitHub/browser profile/password manager.
• Disable powerful tools by default: exec, filesystem, browser automation, session tools, device tools.
• If it only needs to answer questions, make it a read-only “reader” agent with web/docs access only, or even no tools.
• Keep filesystem access workspaceOnly, and don’t put secrets in the workspace.
• Use allowlists/deny lists for tools, not broad default access.
• Require mentions in group channels and use pairing/allowlists for DMs where possible.
• Keep Gateway bound privately unless you intentionally expose it, and use token/password auth.
• Turn on approval prompts for anything that can execute, write, browse authenticated pages, or send external messages.
• Log enough to audit, but keep sensitive redaction enabled.
• Run openclaw security audit after changes.

Big conceptual rule: don’t put untrusted public users in the same trust boundary as your personal assistant. A public bot should have boring, narrow permissions and disposable credentials. If someone prompt-injects it, the worst case should be “it says something dumb” — not “it can read my files or act as me.”