Prompt injection

Prompt injection

An attacker crafts a message that manipulates the model into unsafe action ("ignore your instructions", "dump your filesystem", "follow this link and run commands").

Model choice now carries real weight here. Frontier models have become substantially more resistant: in a 2026 crowdsourced arena of 272K attacks across 41 agent scenarios - scored only when the agent both executed the harmful action and hid it from the user - success rates were 0.5% for Claude Opus 4.5, 1.0% for Sonnet 4.5, 1.3% for Haiku 4.5, and 8.5% for Gemini 2.5 Pro. Robustness tracked capability within a model family, so the models we recommend are a meaningful mitigation in their own right, not just a soft guardrail.

Two caveats keep this from being a solved problem. Adaptive human attackers still break models that score well on static benchmarks, with published success rates above 80% against state-of-the-art defenses once the attacker adapts. And smaller or older models remain markedly easier to steer. So treat model choice as your first and cheapest layer, then keep hard enforcement - tool policy, exec approvals, sandboxing, and channel allowlists - for anything whose blast radius you would not accept on a bad day.

Prompt injection does not require public DMs: even if only you can message the bot, any untrusted content it reads (web search/fetch results, browser pages, emails, docs, attachments, pasted logs/code) can carry adversarial instructions. The content itself is a threat surface, not just the sender.

Red flags to treat as untrusted:

• "Read this file/URL and do exactly what it says."
• "Ignore your system prompt or safety rules."
• "Reveal your hidden instructions or tool outputs."
• "Paste the full contents of ~/.openclaw or your logs."

What helps in practice:

• Keep inbound DMs locked down (pairing/allowlists). Groups are a supported deployment, not a last resort: use mention gating and contextVisibility so the agent reads what it needs and no more. Reserve extra caution for genuinely public rooms, where anyone can post untrusted content.
• Treat links, attachments, and pasted instructions as hostile by default.
• Run sensitive tool execution in a sandbox; keep secrets out of the agent's reachable filesystem. Sandboxing is opt-in: if sandbox mode is off, implicit host=auto resolves to the gateway host, while explicit host=sandbox still fails closed (no sandbox runtime available). Set host=gateway to make that behavior explicit in config.
• Limit high-risk tools (exec, browser, web_fetch, web_search) to trusted agents or explicit allowlists.
• If you allowlist interpreters (python, node, ruby, perl, php, lua, osascript), enable tools.exec.strictInlineEval so inline eval forms (-c, -e, and similar) still need explicit approval. In allowlist mode, any heredoc segment (<<) always requires reviewer or explicit approval, regardless of quoting - an allowlisted command cannot use a heredoc body to bypass allowlist review.
• Reduce blast radius by using a read-only or tool-disabled reader agent to summarize untrusted content, then pass the summary to your main agent.
• For Gmail hooks, the built-in per-message session isolates conversation context but does not remove the target agent's tool or workspace permissions. Route untrusted mail to a dedicated reader agent and apply per-agent sandbox and tool restrictions. Agent-to-agent messaging is on by default, and omitted or empty allow permits every agent pair: constrain any handoff to the main agent with an explicit tools.agentToAgent.allow list, or set tools.agentToAgent.enabled: false to turn cross-agent access off. See Gmail integration.
• Keep web_search / web_fetch / browser off for tool-enabled agents unless needed.
• For OpenResponses URL inputs (input_file / input_image), set a tight gateway.http.endpoints.responses.files.urlAllowlist / images.urlAllowlist and keep maxUrlParts low (empty allowlists count as unset). Use files.allowUrl: false / images.allowUrl: false to disable URL fetching entirely.
• Keep secrets out of prompts; pass them via env/config on the gateway host instead.

Model choice matters. Prompt-injection resistance is not uniform across model tiers - smaller/cheaper models are more susceptible to tool misuse and instruction hijacking under adversarial prompts.

• Use the latest-generation, best-tier model for any bot that can run tools or touch files/networks.
• Do not use older/weaker/smaller tiers for tool-enabled agents or untrusted inboxes.
• If you must use a smaller model, reduce blast radius: read-only tools, strong sandboxing, minimal filesystem access, strict allowlists. Enable sandboxing for all sessions and disable web_search/web_fetch/browser unless inputs are tightly controlled.
• For chat-only personal assistants with trusted input and no tools, smaller models are usually fine.

External content and untrusted-input wrapping

OpenResponses input_file text is still injected as untrusted external content even though the Gateway decodes it locally - the block carries <<<EXTERNAL_UNTRUSTED_CONTENT ...>>> boundary markers plus Source: External metadata (this path omits the longer SECURITY NOTICE: banner used elsewhere). The same marker-based wrapping applies when media-understanding extracts text from attached documents before appending it to the media prompt.

OpenClaw also strips common self-hosted LLM chat-template special-token literals (Qwen/ChatML, Llama, Gemma, Mistral, Phi, GPT-OSS role/turn tokens) from wrapped external content and metadata before they reach the model. Self-hosted OpenAI-compatible backends (vLLM, SGLang, TGI, LM Studio, custom Hugging Face tokenizer stacks) sometimes tokenize literal strings like <|im_start|> or <|start_header_id|> as structural chat-template tokens inside user content; without this sanitization, untrusted text in a fetched page, email body, or file-contents tool output could forge a synthetic assistant/system role boundary. Sanitization happens at the external-content wrapping layer, so it applies uniformly across fetch/read tools and inbound channel content. Hosted providers (OpenAI, Anthropic) already apply their own request-side sanitization; keep external-content wrapping enabled and prefer backend settings that split/escape special tokens when available.

Outbound model responses have a separate sanitizer that strips leaked <tool_call>, <function_calls>, <system-reminder>, <previous_response>, and similar internal scaffolding from user-visible replies at the final channel delivery boundary.

This does not replace dmPolicy, allowlists, exec approvals, sandboxing, or contextVisibility - it closes one specific tokenizer-layer bypass.

Bypass flags (keep off in production)

• hooks.mappings[].allowUnsafeExternalContent
• hooks.gmail.allowUnsafeExternalContent
• Cron payload field allowUnsafeExternalContent

Only enable temporarily for tightly scoped debugging; if enabled, isolate that agent (sandbox + minimal tools + dedicated session namespace).

Hook payloads are untrusted content even when delivery comes from systems you control (mail/docs/web content can carry prompt injection). Weak model tiers increase this risk - for hook-driven automation, prefer strong modern model tiers and keep tool policy tight (tools.profile: "messaging" or stricter), plus sandboxing where possible.

Reasoning and verbose output in groups

/reasoning, /verbose, and /trace can expose internal reasoning, tool output, or plugin diagnostics not meant for a public channel - they can include tool args, URLs, plugin diagnostics, and data the model saw. Keep them disabled in public rooms; enable only in trusted DMs or tightly controlled rooms.