智能体被提示注入或模型幻觉带着走、把敏感数据泄露出去，这类事故已经不是假设。Archestra 在 10 月 3 日开源的 OpenAPPA，想用一套确定性的策略引擎把这道口子堵上——它的核心主张是：安全不该靠另一个模型「随机判断」，而该由跑在 agent 循环之外的规则来拍板。
它的做法是 Agentic Permissions Policy Algebra（APPA）：策略写在一个 appa.toml 里，描述数据源、受众（audience）、信任级别与权限。每个工具契约声明「需要什么受众与信任级别、对返回数据施加什么限制、留下什么审计」。标签用格点代数（lattice algebra）组合，且只能越来越严：读了一条受限的 CRM 记录，这条轨迹的受众就收窄到内部；读了一页未经验证的网页，结果被标为可疑，并挡住后续需要可信数据的工具。一旦动作非法，引擎不是简单地「拒绝」，而是中止派发（halt dispatch），并提供修复路径：清洗器剥离个人身份信息、授权路由把单步动作交人工或内部 API 审批、一次性子分支把不可信读取隔离在临时子 agent 里。这种「按需轨迹隔离」避免了传统信息流控制「要么过度拦截、要么一旦摄入就永久污染」的两难。
基准成绩相当硬：在 Bench-Corp（20 个多步企业工作流）与 OWASP AgentThreatBench（2026 版 Agentic 应用前十风险可执行化）上，1,320 次受保护评测里 0 次攻击成功，任务完成率 89%；对照之下 Claude Code 自动模式攻击成功率 10%、完成率 90%，微软 FIDES 放过 31% 攻击、完成率 41%。消融实验里，关掉修复计划后完成率掉到 35%。作者还顺手点名了「用第二个模型当裁判」路线的软肋：分类器本身可被提示注入、且概率设计上限约 99.3%，在百万次调用里 0.7% 也意味着大量泄露；而 APPA 是确定性检查，同一条日志永远得到同一结论。AgentThreatBench 已被并入英国 AI 安全研究所的 inspect_evals 仓库。
也要说清它的边界。所有数字都来自 Archestra 团队自报、尚未被独立复现；它目前是预览版，官方自己也称配置与接口还可能变。把它接进生产前，建议先在隔离环境用真实工作流跑对照，重点看两件事——一是确定性格子规则在你的业务里会不会误伤正常工具链，二是恢复语义（清洗、人工路由、子分支）在高吞吐下是否跟得上。确定性不等于万无一失，但它至少把「安全能不能被验证」从概率黑箱拉回了可审计的规则清单。对已经在用编码 agent 的团队，更实在的落点是：别再让 agent 自己决定什么能发、什么能读，而是把这道关口外置成一个跑在循环之外、每次调用前都拍板的引擎。
它和本站此前覆盖的 T3MP3ST 正好构成攻防一对：一个把编码 agent 武器化成红队框架，一个在 agent 循环外筑确定性防线。对工程团队而言，OpenAPPA 的启发是「把安全决策从模型脑子里搬出来」——别指望让 agent 自己记得别泄密，而该由外部引擎在每次工具调用前用可验证的规则拍板。当然要清醒：所有数字都是 Archestra 团队自报、还没独立复现；它目前是预览版，官方自己也称配置与接口还可能变。把它接进生产前，建议先在隔离环境用真实工作流跑对照，重点看两件事——一是确定性格子规则在你的业务里会不会误伤正常工具链，二是恢复语义（清洗、人工路由、子分支）在高吞吐下是否跟得上。确定性不等于万无一失，但它至少把「安全能不能被验证」这件事，从概率黑箱拉回了可审计的规则清单。