Archestra发布OpenAPPA，在两大安全基准测试中实现0%攻击成功率

Archestra 发布了名为 OpenAPPA 的开源安全引擎，目标是阻止由提示注入或模型幻觉导致的数据外泄。团队报告称，在 Bench-Corp 与 AgentThreatBench 两项安全基准上运行 OpenAPPA 时实现了零次成功攻击；同一对比中，Claude Code 的 auto 模式攻击成功率为 10%，微软 FIDES 为 31%。Bench-Corp 基准包含 20 个多步骤企业工作流。

这组数字的吸引力在于它把“智能体安全”从概率问题改写成了确定性问题。但需要先划清边界：0% 攻击成功率与 10%、31% 的对比数字均来自 Archestra 团队自行报告，来源中未见第三方独立验证。因此它们目前只能作为厂商自报的基准结果来读，而不是已复现的结论。

OpenAPPA 文档给出的批评对象很具体：行业应对审批疲劳的办法，是再上一个模型去裁判每一次工具调用，例如 Claude Code 的 auto 模式、Codex 的 auto-review 等自动模式。文档认为这类方案存在两个设计层面的缺陷。

第一是数据流追踪。文档指出，第二模型裁判在设计上无法跨工具调用追踪数据流；又因为分类器本身可被提示注入，执行框架会对其隐藏工具输出，导致裁判根本看不到数据。第二是概率上限。文档称，由于概率性设计，最好的模型裁判准确率上限也只有 99.3%，在数百万次调用下 0.7% 意味着大量泄露。

这两点都是 OpenAPPA 文档的自我论证，属于来源方主张。它们解释了 OpenAPPA 为什么要换一条路，但本身并不构成对竞品的独立评测。

OpenAPPA 的核心思路是把策略执行放在智能体的提示与执行循环之外。按来源描述，这一位置选择使得底层语言模型无法检查、协商或绕过策略规则。换句话说，安全判定不再由被约束的模型自己参与，而是由循环外的可插拔引擎完成。

这一取舍也解释了为什么简单的工具允许列表或拒绝列表不够用。文章指出，智能体已证明能绕过这类简单机制，例如被拒绝的 rm -rf 可被等效的 Python 脚本替代。允许列表约束的是工具名，而智能体可以在语义等价的工具之间迁移。

OpenAPPA 实现的是其论文提出的 Agentic Permissions Policy Algebra（APPA），作者包括 Arseny Kravchenko、Vadim Liventsev、Innokentii Konstantinov、Ildar Iskhakov 与 Matvey Kukuy。策略以单个 appa.toml 配置文件形式呈现，其中定义数据源、受众、信任级别与权限。

其机制是同时标注并监控受众（获授权的消费者集合）与信任（数据验证程度）。标签通过格代数单调组合，只能变得更严格：读取受限记录会收窄受众，读取未经审查的外部网页会降低信任。这种单调性是确定性的来源——标签不会因为模型的说辞而放宽。

每个工具契约定义三个主要操作属性：requires（运行该工具所需的受众成员资格与信任级别）、delta（工具返回数据时施加的限制）与 effects（成功操作的审计轨迹）。工具调用因此受 requires 条件约束，例如 process_internal_data 要求受众在 internal 之内，apply_db_migration 要求数据为 trusted。

OpenAPPA 具备显式恢复语义。当智能体尝试非法操作时，引擎会停止派发并提供结构化路径，包括可编辑载荷的 Sanitizer、将请求路由给人工操作员或内部验证 API 的 Authority，以及按需隔离的 Disposable Child Branches。

这一设计回应的是安全与可用性的张力。OpenAPPA 的 GitHub 仓库提醒开发者，智能体安全有两个轴：允许未授权流动的智能体不安全，而拒绝有效工作的智能体则无用。过度收紧策略会降低实用性——智能体虽不泄露数据，但因限制而无法成功完成任务。

需要说明的是，来源摘要末尾关于 Disposable Child Branches 的描述被截断，其完整机制与适用条件不明，因此这里只能确认它被列为恢复路径之一，无法进一步展开。

即便接受“循环外执行 + 单调标签”这一架构逻辑，仍有若干问题在来源中没有答案。0% 攻击成功率仅为 Archestra 团队自报，缺乏第三方独立复现或验证；10% 与 31% 的对比数字同样来自厂商自报，其测试条件与可比性不明。

基准本身也不透明。Bench-Corp 与 AgentThreatBench 两项基准的具体构成、难度与评测方法在来源中未完整披露。99.3% 这一概率性裁判上限的具体出处与评测范围同样未说明。

更关键的是生产环境。OpenAPPA 在真实生产环境、而非基准测试中的实际防护效果尚不清楚。基准上的零次成功攻击，与在长周期、多工具、真实数据流的生产系统里保持零次泄露，是两件需要分别证明的事。

把上述线索串起来，OpenAPPA 真正押注的不是某个基准分数，而是可审计性。文档提到，规则集若过紧会破坏智能体，若过于复杂则无人能审计其许可范围。单个 appa.toml 加上 requires、delta、effects 三个属性，试图把“这个智能体被允许做什么”压缩成一份人能读完、能复核的配置。

这也是它与概率性裁判路线的根本分歧：后者把判定权交给一个同样可被注入、且看不到完整数据的模型；前者把判定权交给循环外的确定性规则，代价是规则必须由人写清楚、并承担写错的风险。

因此，对 OpenAPPA 的合理态度是：架构方向值得认真对待，0% 这个数字则应当被当作待验证的厂商主张。在第三方复现与生产环境数据出现之前，它证明的是“这条路可能走得通”，而不是“这条路已经走通”。