没有安全的人工智能避难所

RECODEX · 深度文章 AI

There is no secure AI enclave neo

“没有安全的人工智能避难所，Neo。”

又是一周，又有一款人人热议的 AI 应用。本周似乎是 Clawdbot，这款被描述为 “连接一切、无所不能” AI 代理。

从实际角度看，Clawdbot 很有趣，因为维护者花费时间和精力将其与其“网关”上的大量服务集成：iMessage、WhatsApp、Discord、Gmail、GitHub、Spotify，以及更多。理论上，你可以用手机给它发信息，它会为你制作播放列表、清理收件箱、修剪日历，并在你偏好的通信界面上为那些麻烦的 GitHub 用户做出回应！

但从安全角度来看，这简直是噩梦，我不建议任何人真正去集成它。

撇开个人隐私和安全不谈，仅提示注入攻击就足以让任何人在将具代理能力的系统与更广泛的外部世界连接前三思：一次又一次，红队发现了新颖的方法破坏基于 LLM 的系统，规避其内部护栏，并说服它们去做未被提示的事情（也许有一天 ML 研究人员会解决 alignment problem，但那不是我们今天所处的世界）。

试想我把 Clawdbot 连接到我的电子邮件和 GitHub，目的是自动回复我维护的庞大 Go 开源库 spf13/cobra 中的用户。我在 GitHub 中使用电子邮件接收通知，并尽力使用电子邮件过滤规则来提高信噪比，尽管这些通知常常让人不堪重负。Clawdbot 的工作流程大致如下：

Email notification from GitHub
 --> Gmail filter puts it into "github/spf13/cobra" folder
  --> Clawdbot reads new mail in folder
   --> Clawdbot responds to user with GitHub integration as @jpmcb

想象一下生产力的提升！想象一下自动化！想象一下随之而来的问题！！

如果我想让 Clawdbot 以“我”的身份使用完全集成的 OAuth 应用或个人访问令牌 (PAT) 来回应——这似乎是大多数 AI 集成设置的快捷粗糙方式——任何在互联网上知道我电子邮件的人实际上就获得了针对整个 Go 生态系统的攻击向量：他们可以通过提示注入让 Clawdbot 接受并合并恶意的 PR，发布新版本，并将其发布到超过 200,000 个导入它的 Go 包（包括 kubernetes/kubernetes、几乎所有 Grafana 的 Go 工具、tailscale/tailscale、openfga/openfga 等等）。

他们只需给我发几封电子邮件。

我最近一直在说，这个 AI 时刻感觉在很多方面都很像早期的云原生时代：我们有一种叫做“容器”的新东西，可以放在 pod 上、在云端的计算集群中运行，并可确定性地横向扩展。更重要的是，你可以确保各种容器化服务拥有所需的所有依赖，同时彼此隔离。这是一种全新的软件思维与交付方式。

作为第一性原理，这种新的容器范式实际上只是关于可扩展的 Linux 隔离：一旦你明白同一台电脑上的两个进程可以通过命名空间、cgroups、seccomp、能力（capabilities）和 SELinux 有效隔离，升级思路去在云端部署整个服务集群就是下一步显而易见的选择。

向从业者演示这一点非常简单：运行两个不同的 sleep 命令，先后在不同的命名空间中运行，使用 unshare 进行隔离。

$ unshare --pid --mount --net --fork --mount-proc /bin/bash -c 'sleep 5'

USER  PID %CPU %MEM  TTY      STAT START   TIME COMMAND
root    1  0.0  0.0  pts/0    S+   12:34   0:00 /bin/bash -c sleep 5
root    2  0.0  0.0  pts/0    R+   12:34   0:00 sleep 5

$ unshare --pid --mount --net --fork --mount-proc /bin/bash -c 'sleep 5'

USER  PID %CPU %MEM  TTY      STAT START   TIME COMMAND
root    1  0.0  0.0  pts/0    S+   12:34   0:00 /bin/bash -c sleep 5
root    2  0.0  0.0  pts/0    R+   12:34   0:00 sleep 5

你会立即注意到这两个进程不会“看到”彼此，因为它们处于各自的 PID 命名空间中；我们已将子进程分叉到该命名空间，并为该命名空间中的进程挂载了一个新的 /proc 目录。我们可以将此再进一步，为网络、用户、文件系统等设立单独的命名空间。

但早期的云原生时代也带来了很多挑战。如何管理容器的安全边界？我有日志和指标，放在哪里？我究竟如何在云端获得这样一个神奇的集群，又如何安全地访问它？这个容器编排工具出了新版本，我得把所有东西停掉去升级？你说集群中的工作节点没有向控制平面注册是怎么回事？哦，整个互联网都会访问这个集群，我需要证书、网络、负载均衡器，天哪！

虽然容器和 Linux 隔离本身并不是安全边界，但这使行业具备了创建 Docker、Kubernetes、containerd、Podman 以及基于这些技术构建的无数服务的能力与经验。容器隔离是我们在现代云时代理性扩展计算的方式，并为随后为敏感容器化工作负载构建安全隔离区提供了第一批踏脚石。

就像早期云原生出现容器时一样，AI 和具代理能力的系统带来了全新的思维方式和工作方法：用通俗的话说，你可以交付新功能、定义工作流并连接应用。这一切也带来了自身的问题：我如何确保我的 AI 代理仅能访问完成任务所需的最少服务和资源？直接在笔记本上以“危险模式”循环运行 Claude Code 是个好主意吗？

我们缺少的是像云原生时代那样的“下一步”：我们需要编排器、隔离层、遥测、网络以及安全边界的保障。也许比以往任何时候都更为重要——鉴于这些 AI 工作流看起来如此强大，业界应更多关注这些新技术的影响以及运行它们所需的安全隔离区。在没有隔离的服务器上运行大量未知第三方集成，并将具代理能力的 AI 连接到关键系统而没有基于基础设施的保护措施，都是糟糕的主意。如果仔细观察，这两者在某种程度上开始显得像同一个问题并需要类似类型的解决方案。

在这些防护措施到位之前，我会把 Clawdbot 远远地挡在我的收件箱之外。你也应该这么做。