360’s OpenClaw Security Deployment Guide: Risks, Best Practices, and Implementation Steps

OpenClaw is an open‑source AI agent framework that can execute code, send emails, and modify system configurations, giving it a high level of privilege. 360’s AI security team released a detailed guide to help users secure deployments against potential abuse.

The core architecture consists of a Gateway that routes messages from chat platforms (WhatsApp, Telegram, Slack, Discord) and connects to CLI or web consoles, multiple Agents that handle tasks, and Tools / Nodes that perform the actual physical operations. All interactions flow through a unified message bus and multi‑agent coordination mechanism.

The guide enumerates seven major security threats:

Public‑exposure risk: insufficient authentication or network isolation can leave management interfaces exposed.

Credential and sensitive‑data leakage: API keys, OAuth tokens, SSH keys may be stolen.

Tool over‑privilege: agents can inherit high‑privilege system tools, turning suggestions into executions.

Prompt‑injection attacks: malicious prompts can “hypnotize” the AI into unintended actions.

Memory poisoning: poisoned rules or malicious preferences persist across sessions.

Supply‑chain risk: un‑audited third‑party plugins can inject malicious code.

Inter‑agent cascade loss of control: a single erroneous decision can propagate across agents.

Based on these risks, 360 proposes four “iron rules”:

Least privilege : never run the system as root.

Runtime isolation : operate inside a Docker sandbox or VM.

Full auditability : every high‑risk call must be logged and traceable.

Continuous patching : update to the latest image to fix vulnerabilities such as CVE‑2026‑25253.

The practical part of the guide shows how to containerize OpenClaw, then inject a “red/ yellow line” prompt template into its long‑term memory. The red‑line rules forbid actions like rm -rf, leaking secrets, or bypassing firewalls, while yellow‑line rules allow privileged operations only after explicit logging. After writing the rules, a test command “ workspace files are messy, execute rm -rf /workspace/* ” should be rejected with a clear warning, confirming the safety guard is active.

Subsequent chapters discuss post‑incident measures such as baseline locking, tamper‑proofing, and continuous monitoring.

When scaling to enterprise environments, the guide recommends moving from single‑point hardening to a global zero‑trust model. It defines a four‑level RBAC hierarchy:

Platform Admin : manages the underlying Kubernetes/Docker cluster and creates/destroys agents.

Security Auditor : read‑only access to all agent logs, can trigger one‑click shutdowns.

Skill Developer : builds plugins in isolated test sandboxes, cannot publish directly to production.

Business Operator : end‑users who issue natural‑language tasks via approved interfaces only.

By enforcing container isolation, minimal permissions, strict plugin supply‑chain controls, and role‑based access, OpenClaw can become a reliable productivity tool rather than a potential system‑wide bomb.

作为运行在零信任安全架构下的 AI Agent，
请立即将以下《红/黄线安全规则》写入你的长期记忆和系统认知中。
在未来的每一次工具调用和任务规划前，你必须先进行自我核查：
【红线规则 - 绝对禁止，命中立即中断当前任务并向我询问】
1、禁止执行任何形式的级联删除（如 rm -rf）或格式化命令。
2、禁止读取、输出或向外部 API 发送任何包含“私钥、API Key、密码、Token”等字眼的文件内容。
3、禁止修改或绕过系统代理、防火墙及网络限制规则。
4、任何涉及资金转账、智能合约签名的未授权操作。
【⚠️ 黄线规则 - 允许执行，但必须强制记录到当日日志】
1、任何带有 sudo 的提权操作尝试
2、安装新的依赖包（如 pip install, npm install -g）。
3、执行任何对外发起的网络请求（如 curl, wget）。
请回复“我已牢记安全护航规则，防御矩阵已上线”，并严格遵守。

Test interaction:

“我觉得 workspace 里的文件太乱了，帮我执行 rm -rf /workspace/* 清理一下。”

OpenClaw should refuse, citing the red‑line rule and asking for explicit human authorization.