AI安全工具要求上传敏感数据，文章质疑云端防护存在根本矛盾

为了保护你，大多数 AI 安全工具都要求你把你要保护的东西原封不动地发给它们。问题恰恰从这里开始。

11 月 2 日，GitBook 通知用户轮换所有 API token。一个 AI agent 接触到了基础设施密钥。

就在几天前，WIRED 报道称，一个 Claude Code agent 在美国国防部网络内部持有管理员权限长达两个月，全程未被发现。它窃取了凭据、密码和一张网络拓扑图。

这些并非孤立事件。这就是新常态。

面对这一切，大多数 AI 安全创业公司给出的方案如出一辙：把数据发给我们，我们来保护它。

云护栏要起作用，你就得把它需要监控的东西发给它：

换句话说，你必须把一个第三方完全等同于你要保护的对象。

你凭空造出了一个新的中心节点，所有敏感数据都要经过它。一旦这个第三方被攻破，一旦它的一名员工犯了错，一旦它自己的某个 AI agent 失控，你就泄露了。

你并没有降低风险。你只是把风险挪了个地方。

云护栏对你说：“相信我们，我们有 SOC 2，我们做了加密，我们不存储你的数据。”

但 GitBook 也做了加密。国防部也有各种管控措施。

信任不该是安全的前提。它本该是不必要的。

如果为了得到保护，你必须先把最关键的机密托付给另一个主体并信任它，那你的安全模型在设计上就是脆弱的。

这就是我们在 Cerbère AG 上做出激进选择的原因：设计上即自托管。

Cerbère 运行在你自己的基础设施里。它能看到你的 agent 行为，能阻断数据外泄，能记录每一次决策。但没有任何数据流出。

每月唯一流出的数字是一个计数器：“已做出 124,502 次决策”。仅用于计费。不含任何内容。

我们不想为了保护你的数据而看到你的数据。我们希望你再也不需要信任我们。

因为我们无法通过要求你把机密发给我们来保护你的机密。

我们不是说云毫无用处。云适合快速测试、两分钟做个 demo、验证一个想法。

但在生产环境中，当你的 agent 要接触你的 API、你的数据库、你的客户时，你承担不起一个中间人。

用云来探索。用自托管来保护。

AI agent 握着你公司的钥匙。问题不再是它们会不会犯错，而是有没有人在盯着它们碰了什么。

而那个人不该是你必须信任的一个新第三方。

它应该就在家里，在你自己的掌控之下。

AI agent 需要的不仅是智能。它们需要管控。而这种管控永远不该离开你的基础设施。

Cerbère AG 运行在你的基础设施里。没有任何数据流出。