传统的 AI Agent 安全通常依赖于“环境权限”。在这种模型中,程序仅仅因为其所处的环境而行使权力:一个进程可能因为以特定的 Unix 用户身份运行而能够读取目录,或者一个 AI Agent 可能因为环境变量中存在 token 而能够访问 GitHub 仓库。这造成了巨大的风险;如果 Agent 受到提示词注入或依赖项漏洞的攻击,攻击者将继承与该广泛凭证相关的所有权限。Edera 主张,与其试图约束一个已经拥有权限的工作负载,安全工作的起点应该是确保工作负载在被明确授予特定能力之前没有任何权限。

Edera 的方法基于对象能力(OCAP)模型,该模型将“指定”(你正在与哪个对象通信)和“权限”(你被允许对该对象做什么)合并为一个不可伪造的引用。在能力导向的系统中,Agent 不需要通用凭证;它只需持有代表执行特定操作权限的句柄,例如 `github.write(repository="acme/payments")`。这是通过持有实际凭证的“能力经纪人”来实现的。例如,在 Edera 的 `capcurl` 概念中,经纪人管理 GitHub token 并向 Agent 提供受限权限。Agent 永远看不到 token,而经纪人在执行请求之前会强制执行特定的约束——例如允许的路径、速率限制或特定的 HTTP 方法。

展示普通凭证共享与 OCAP 模型之间差异的对比图。
侧向对比图说明了 OCAP 模型如何通过能力经纪人取代直接的凭证共享,以提供受限权限。edera.dev

该图表展示了从 Agent 持有广泛凭证到使用能力经纪人获取狭窄范围句柄的转变。

这种模型特别适合 AI Agent,因为它们的行为是动态的,且难以用静态策略来预测。由于能力是可组合且细粒度的,Agent 的实际权力是其被授予的特定权限的总和。例如,一个 Model Context Protocol (MCP) 服务器可以被限制为仅执行三个特定命令,而不是被授予通往整个基础设施的特权桥梁。虽然 OCAP 并未取代身份——Edera 仍使用 SPIFFE/SPIRE 来建立工作负载是“谁”——但它提供了更清晰的关注点分离。身份建立主体,而能力管理该主体被允许执行的特定、最小权限的操作。这创建了一个双层安全模型:microVMs 提供与宿主机的隔离,而受限权限提供 Agent 在该沙箱内所能执行的操作的隔离。

显示服务被分解为 GitHub、Kubernetes、HTTP 和命令等离散受限能力的树状图。
一个服务如何被分解为特定、细粒度的能力,而非单一广泛权限授予的示例。edera.dev

此视觉效果展示了能力的细粒度,其中 Agent 的权力是如 'git-diff' 或 'restart-deployment' 等特定权限的总和。