基本信息

来源摘要/节选

公开展示已截断至最多 800 个字符；请访问原始来源查看完整上下文。

场景：把 AI 助手部署在共享服务器上 前六篇从 Gateway、通道、Agent、插件、模型到 Canvas，一路分析了 OpenClaw 的核心能力。现在，假设你打算把它部署在一台多人共用的 Linux 服务器上——同事小李的账号也在这台机器上，你们共用同一个 Docker 环境。 这立刻暴露了一系列问题： 认证 ：HTTP 端口绑定到 0.0.0.0 ，没有 token，小李的脚本能直接调用 /tools/invoke 执行命令？ 工具过度暴露 ： sessions_spawn 工具暴露在 HTTP 接口上，意味着任何人都能远程派生 Agent，相当于 RCE 入口。 Shell 逃逸 ：Agent 执行 exec 工具时直接在宿主机跑，一个 rm -rf / 就是灾难。 API Key 泄漏 ： openclaw.yml 里写着明文的 Anthropic API Key， cat 一下就能看到。 提示注入 ：把外部邮件内容喂给 AI 处理，邮件正文里夹带 ignore all previous instructions 就能劫持行为。 这五个问题分别对应 OpenClaw 安全模型的五个层次： Gateway 认证 、 工具策略 、 沙盒隔离 、 密钥管理 、 外部内容防护 。再加上贯穿所有层次的 安全审计 框架，构成完整的信任边界设计。 一、Gateway 认证：信任边界的第一道门 问题：谁可以连接 Gateway？ Gateway 提供 HTTP/WebSocket 接口——任何能访问该端口的进程都能发请求。在非 loopback 绑定时，这意味着同一局域网甚至公网上的所有人。…

来源说明

当前只保存了公开页面节选，不代表原文全文。请以原始来源为准。

本页只呈现已做哈希绑定的来源证据，不包含基于旧正文或缺失原文的扩展推断。