最安全的边界是智能体无法触及的边界

如果一个 AI agent 为多个组织运行基础设施，安全性就会变成一场噩梦。

危险不在于 agent 犯了什么高明的错误，而在于它为错误的对象执行了某些平庸的操作。

为客户 B 而不是客户 A 编写工单或轮换密钥，这就是一次违规。你无法“修补”一次违规，你必须披露它。

大多数人试图通过权限来解决这个问题。他们创建一份 agent 可以触及的列表，并根据该列表检查每一项操作。

这种方法会失败。权限机制假设资源是存在的，只是你拒绝访问。如果你的规则存在漏洞或遗漏了某种情况，agent 就会触及错误的数据。

我使用了一种不同的模型。我让错误的数据在结构上“不存在”。

在客户 A 的会话中，客户 B 的资源并不存在。凭据未加载，端点也不在映射表中。既然没有东西可请求，也就无需拒绝。

规则会有漏洞，但系统的物理结构不会。

我是吃过苦头才明白这个道理的。我曾以为 secrets manager 就足够了，以为隔离了密钥就隔离了租户。我错了。

secrets manager 隔离了密钥，但它没有隔离端点。如果客户 B 的地址在配置中，即使 agent 持有客户 A 的正确 token，仍然可能向客户 B 的地址发送请求。

泄露点不在密钥，而是在路由。

我通过将每个资源绑定到一条记录中解决了这个问题： • 资源 (Resource) • 端点 (Endpoint) • 凭据 (Credential) • 所属租户 (Owning tenant)

如果你拿不到所有者，你就拿不到地址。如果租户与会话不匹配，发送数据的库就会拒绝工作。你无法通过硬编码来绕过这一点，因为只有当地址与其所有者焊接在一起时，它才会存在。

我使用了三层防御：

  • 结构化隔离，使错误的数据不存在。
  • 绕过阻断 (bypass block)，防止 agent 使用原始工具跳过检查。
  • 出站范围限制 (egress scoping)，使会话只能与允许的地址通信。

这构建了一个故障闭锁 (fail closed) 的系统。

在我之前的工作中，我主张故障开放 (failing open)。如果 agent 不确定某个操作是否安全，它应该继续执行。一个在每个疑虑面前都停滞不前的 agent 是毫无用处的。

但租户边界是不同的。如果 agent 不确定自己正在触碰谁的数据，它必须停止。

行动中的不确定性会导致变动。所有权中的不确定性必须导致静止。

不要构建只会说“不”的检查机制。移除那些需要检查的形态。

来源：https://dev.to/artemmatviychuk/the-safest-boundary-is-the-one-the-agent-cant-reach-across-20ad

可选学习社区：https://t.me/GyaanSetuAi