AI agent 一旦开始真的“做事”，风险就不再只是答错问题，而是它会直接往外发请求、调 API、读写文件、发消息，甚至替你跑带权限的操作。

这时候问题就变成了一个很现实的工程题：你要怎么在 agent 和外部世界之间，插入一道真正能执行的边界？

今天想写的 Firma-AI/openfirma，就是一个很直接的回答。它不是再做一层提示词包装，也不是做一个“AI 安全建议面板”，而是把 运行时治理 往前推到每一次出站调用上。

公开仓库信息显示，这个项目发布时大约有 94 stars、3 forks，主要语言是 Rust，采用 Apache-2.0 许可证。当前公开的最新 release 是 v0.1.1，发布时间为 2026-06-09。README 对它的定义也很清楚：一个位于 AI agent 和外部世界之间的 runtime enforcement boundary。

项目概览

属性详情
仓库Firma-AI/openfirma
定位AI agent 的运行时出站治理边界
Stars约 94
Forks3
主要语言Rust
许可证Apache-2.0
最新 releasev0.1.1
核心组件Sidecar + Authority + Cedar policy

它解决的不是“模型会不会胡来”，而是“胡来时谁来挡住”

很多人在谈 agent 安全时，容易把注意力都放在模型层，比如 system prompt、tool schema、审批流程或者 HITL。

这些都重要，但它们有一个共同问题：如果最后真正的出站动作已经要发生了，你到底有没有一个独立于 agent 进程之外的硬边界？

openfirma 的设计重点就在这里。它把 agent 的每一次 outbound call 交给本地 Sidecar 处理，由 sidecar 在执行前做几件事：

  • 把动作归类成可治理的 action class；
  • 校验 capability token；
  • 用本地 Cedar policy 做决策；
  • 允许时再继续请求；
  • 拒绝时直接阻断，并写入签名审计记录。

也就是说，它真正盯的是 执行前一跳，而不是“事后分析这次调用好不好像有点危险”。

关键点在于：策略不在模型里，执行也不靠模型判断

README 里有一句我很认同的描述：no model on the hot path。

这很关键。因为只要安全判断还依赖模型本身，边界就不够稳。模型可以波动、提示词可以漂移、上下文可以被污染，但运行时策略判断最好不要跟着一起漂。

openfirma 的做法是：

  • 策略由你自己定义；
  • 策略用 Cedar 表达；
  • sidecar 在本地执行判断；
  • authority 负责发 capability token、分发 policy bundle 和 revocation；
  • agent 本身不直接持有原始凭据。

这个结构比“给 agent 多写几条不要乱动生产环境的提示词”要硬得多。因为它把约束从语言层，移到了执行层。

firma run 这条路径很务实

很多安全工具的问题是理念很完整，但第一次上手太重。openfirma 在这点上反而做得相当克制。

README 给出的最快入口是：

firma run -- claude

如果本地还没有 authority 和 sidecar，它会自动启动一套本地运行的治理组件，让 agent 在 enforcement 下工作；如果你想长期运行，也可以显式 config 再 sidecar start --detach。

这个分层很合理：

  • 想试用的人，可以一条命令先跑起来；
  • 想长期接多 agent session 的人，可以切到持久化 authority；
  • 想接自己的 agent runtime，也可以走 HTTP_PROXY / HTTPS_PROXY 的独立 sidecar 模式。

它不是把用户逼进单一路径，而是把治理边界做成从轻到重都能接的结构。

Cedar policy + pack 模型，让它不只是“拦截”，而是能配置

如果一个安全工具只能统一 deny 或统一 allow，它在真实项目里通常活不长。

openfirma 比较成熟的一点，在于它已经把策略配置做成了更接近工程使用的形式。README 里提到：

  • posture pack：定义默认许可范围；
  • mapping pack：把具体服务的原始 HTTP 调用映射成治理动作类别；
  • policy 文件可以放在 .firma/policies/ 下，并被 authority 自动热更新；
  • firma policy validate 和 firma policy test 可以先本地校验。

默认姿态里就已经区分了：

  • strict
  • dev
  • dev-with-delete-watch

映射层也不是空白壳子，而是已经提供了 openai、anthropic、github、gmail、stripe、npm、pypi、cargo 等 pack。

这说明它的方向不是“理论上可以治理 agent”，而是开始认真处理真实服务调用该怎么落地分类。

多 agent 和多机器场景，是它比简单代理更值得看的地方

如果只是给单个本地 agent 套一个代理，思路其实不新。

openfirma 更值得注意的地方，是它明确区分了几种 operating model：

  • 单 agent 本地快速运行；
  • 单机多 agent，共享同一个 authority；
  • 团队 authority，多个开发机或 CI runner 本地执行 sidecar；
  • 自定义 authority + 自定义 agent runtime。

这里面的重点不是“拓扑图画得完整”，而是它把 策略分发 和 本地执行 拆开了。sidecar 在本地做 per-call enforcement，authority 则负责作为信任根分发 policy 和 token。

这个结构很适合以后继续扩到：

  • 多开发者协作；
  • CI 中的 agent 执行；
  • 企业内部的受控 agent runtime；
  • 审计和撤销统一收口。

对一个 stars 还不高的项目来说，这个边界已经搭得很像正式产品，而不只是 demo。

它最有价值的一点，是把“安全”做成了开发工作流的一部分

很多安全产品最后进不了开发流程，不是因为不重要，而是因为太像额外负担。

openfirma 目前的形态，反而比较像 developer tool：

  • 是 CLI；
  • 一条命令就能先跑；
  • 能 monitor 决策流；
  • policy 改完能自动下发；
  • 能接 claude、codex 这类实际会被人每天运行的 agent；
  • 支持长期运行，也支持本地一次性 session。

这比很多“安全理念正确但离日常使用太远”的方案更有机会活下来。因为开发者愿意留下来的，通常不是最完美的控制系统，而是 最先进入真实工作流的那个。

v0.1.1 这个 release 也透露出它在补什么坑

当前公开的最新 release v0.1.1 虽然不是大版本，但 release note 很能说明项目在往哪修。

我觉得最值得注意的是几类改动：

  • 恢复一行安装器；
  • 改善 firma config 的平台感知，处理 WSL 的 backend 选择；
  • 修复 codex 相关的 nested bwrap 受限场景；
  • 把 managed seccomp policy 更一致地应用到 profile；
  • 补启动前检查和 sidecar 配置验证。

这些不是演示层的改动，而是典型的“开始有人真拿它跑 agent 了，所以启动、沙箱和平台兼容问题必须补平”。

这类 release 往往比炫目的新功能更能说明项目质量，因为它暴露的是作者是否真的在处理现实环境里的毛边。

它适合谁

如果你已经开始遇到这些情况，openfirma 就很值得关注：

  • agent 会真的碰 GitHub、邮件、包管理器或第三方 API；
  • 你不想把“允许什么动作”只写在 prompt 里；
  • 你希望每一次外部调用都可阻断、可审计；
  • 你想把 policy 交给团队维护，而不是交给单个 agent session 自己解释；
  • 你需要本地优先的治理边界，而不是再把安全判断外包给另一个模型服务。

反过来，如果你还只是偶尔在本地跑一个不带权限的 agent，它的完整能力可能还偏重。但只要 agent 开始接真实系统，类似 openfirma 这种运行时边界工具，重要性只会越来越高。

小结

Firma-AI/openfirma 最值得看的，不是它又给 AI agent 加了多少“安全说明”，而是它认真把 执行边界 做成了一个独立组件：sidecar 拦截、Cedar policy 决策、authority 分发、JIT credentials、signed audit、per-call enforcement。

这条路比单纯做提示词约束难得多，但也更接近真实世界里需要的那种安全感。如果你已经开始把 agent 当成会碰外部系统的软件操作员，那 openfirma 这种项目，值得尽早关注。