为什么安全值得单独一篇
AgentDock 的能力和它的风险是一体两面：它能读写文件、跑命令、管 Git——意味着配置失误时，AI（以及冒充 AI 客户端的任何人）也能做同样的事。让 AI 拿到你电脑的钥匙之前，先把锁装好。
好消息是 AgentDock 的安全模型设计得比较克制：默认认证开启、能力按工作区隔离、管理权限单独凭证。 你需要做的是理解每个开关的含义，然后按自己的暴露面正确配置。
第一层：认证体系
AgentDock 的认证围绕三类凭证展开，权限从低到高：
| 凭证 | 用途 | 给谁用 |
|---|---|---|
AGENTDOCK_TOKEN | MCP 客户端调用工具 | 你的 AI 客户端 |
AGENTDOCK_ADMIN_TOKEN | 管理接口（状态、配置类操作） | 你自己的运维工具 |
AGENTDOCK_NO_AUTH=1 | 关闭认证 | 仅本机调试 |
三条使用纪律：
- Token 用长随机串。
openssl rand -hex 32生成 64 位十六进制。不要用「test123」这种——公网扫描器对常见弱 Token 是有字典的。 - Admin Token 与普通 Token 分离。 日常 AI 客户端只需要工具调用权限，管理接口凭证单独存放。万一客户端凭证泄露，攻击面也限制在工具层。
AGENTDOCK_NO_AUTH的使用场景只有一个：本机 loopback 调试，且机器不提供任何网络服务。这个开关等于把门卸了，任何能路由到你 8765 端口的人都是「管理员」。
第二层：来源控制与传输安全
AGENTDOCK_ALLOWED_ORIGINS 是来源白名单，主要约束浏览器侧客户端的跨域请求。配置原则：精确到你的域名，不用通配符。比如只允许 https://chat.openai.com 和你自己的 Web 面板域名。
传输层没有商量余地：只要跨出了本机 loopback，就必须 HTTPS。三种实现路径：
- Cloudflare Tunnel：AgentDock 官方文档推荐的方案。机器上跑一个 cloudflared，把 8765 隧道出去，自动获得 HTTPS 域名，路由器一个端口都不用开。家庭宽带/NAS 部署的首选。
- Caddy 反代：VPS 部署的顺手选择，自动证书。本站的雷池配合 Caddy 防护方案里 Caddy 的配置模式可以直接复用，把后端换成
127.0.0.1:8765。 - Nginx + certbot：传统组合，也没问题，只是配置量多一点。
第三层：工作区边界
AgentDock 的文件操作全部限制在配置的工作区内。这是最重要的「爆炸半径控制」设计，配置时记住三条：
- 工作区宁小勿大。 给 AI 处理项目就只开项目目录。整盘开放是新手最常见的自杀式配置——AI 一个递归删除的误判，你连后悔的机会都没有。
- 敏感目录永不入区。 SSH 密钥（
~/.ssh）、云凭证（~/.aws、~/.config/gcloud）、浏览器 Profile、密码库——这些目录和你的工作区物理隔离，最好连父目录都不重叠。 - 容器隔离是终极方案。 拿不准的操作交给 Docker 节点跑：容器内的 AgentDock 就算被完全控制，损失的也只是容器那一层。官方镜像自带 GPU 支持，「算力任务进容器、敏感操作留在受控环境」是稳妥的分工。
第四层：公网部署的额外防线
如果你的 AgentDock 必须暴露公网（比如给 ChatGPT 这类云端客户端直连），在前面两层之上再加：
IP 侧收口。 云服务器的安全组/防火墙尽量限制来源。客户端 IP 固定的（比如只有你办公室出口），直接白名单 IP；来源不固定的（ChatGPT 服务器），这一层防不了，靠 Tunnel 和 Token 扛。
_fail2ban 或等效限速。 8765 端口放在公网上一定会被扫。对反复携带无效 Token 的来源限速拉黑，把噪音挡在应用层之外。
审计习惯。 定期看 AgentDock 的任务日志（agentdocks task logs），陌生的任务记录就是入侵信号。这一点和运维任何公网服务的习惯一致——VPS 运维实战里会展开日常巡检的完整清单。
NexusDock 侧的权限设计
多设备场景下中心服务 NexusDock 的安全模型同样值得展开：它提供统一 MCP 入口（OAuth + Access Token 两级认证），节点文件下载走中心代理。设计上的关键点是数据不搬家——Recall 记忆、任务状态、Skills 都留在各节点 AgentDock 上，NexusDock 只做编排视图。这把「中心被攻破」的损失上限压到了编排层，而不是数据层。
部署 NexusDock 时官方镜像同样走了安全强化路线：只读根文件系统、无 Linux capabilities、以 UID 10001 非特权用户运行。你只需要做好两件事：管理端口（18777）不裸暴露公网，以及 Access Token 按客户端分发而不是共用。
疑似泄露时的应急四步
Token 疑似泄露（误提交公开仓库、发错群、客户端设备失窃）时按这个顺序处理：
- 立即换 Token。 生成新的
AGENTDOCK_TOKEN并重启 AgentDock，让旧凭证全部失效。Docker 部署就是改环境变量后重建容器。 - 查任务记录。
agentdocks task list翻历史任务，可疑的用agentdocks task logs看完整日志——陌生的任务记录就是证据，重点核对时间线和操作对象。 - 核对工作区。 工作区里的 Git 仓库用
git status、git diff快速暴露被动过的文件；非仓库目录按修改时间排序检查。 - 连带轮换。 工作区里出现过的任何凭证——数据库密码、API Key、部署密钥——一律视为已泄露并全部轮换。宁可惜一轮，不可漏一个。
处理完把成因写下来：泄露路径是什么、哪道防线该挡没挡住。绝大多数「差点出事」都指向同一个原因——Token 出现在了不该出现的地方。
三个常见误区
「不开公网就不用配认证。」 内网不等于可信：一台中了钓鱼邮件的办公电脑，就足以从内网摸到一个没设防的 8765。AGENTDOCK_TOKEN 在内网照常配上。
「Tunnel 域名够隐蔽。」 域名会进证书透明日志，扫描器找得到。Tunnel 解决的是加密和不开端口，认证仍要靠 Token 自己扛。
「AI 会自己拒绝危险操作。」 模型侧约束是概率性的，提示词注入能让它「改变主意」。边界建在配置层：工作区范围、凭证分离、来源白名单——这些不依赖 AI 的觉悟。
一张自查清单
部署完成后过一遍这份清单，全绿再让 AI 上岗：
-
AGENTDOCK_TOKEN为 64 位随机串，未提交进任何仓库 - Admin Token 与普通 Token 不同值
- 非本机访问全部走 HTTPS（Tunnel 或反代证书）
- 工作区目录最小化，
~/.ssh与凭证目录确认不在工作区内 -
AGENTDOCK_ALLOWED_ORIGINS精确配置（有 Web 客户端时） -
AGENTDOCK_NO_AUTH确认未在任何联网机器上开启 - 公网部署已有限速/审计措施
- 每个节点独立 Token（多设备场景）
安全没有银弹，但有明确的边界。把边界画清楚，AI 操作电脑这件事才能安心地自动化下去。