AI agent が本当に「作業する」ようになると、リスクは答えを間違えることだけではなくなります。API を叩き、file を読み書きし、message を送り、権限付きの操作まで実行し始めるからです。

そうなると問題はかなり現実的です。agent と外の世界の間に、実際に効く境界をどう置くか が問われます。

今日取り上げたい Firma-AI/openfirma は、その問いにかなり真っ直ぐ答えている project です。Prompt をもう一段重ねるのでも、後から危険そうな挙動を眺める dashboard を作るのでもなく、runtime enforcement を outbound call ごとに差し込もうとしています。

公開情報ベースでは、公開時点でこの repository はおよそ 94 stars、3 forks。主要言語は Rust、license は Apache-2.0 です。現在の最新 release は v0.1.1 で、公開日は 2026-06-09。README でも AI agent と外部世界の間に置く runtime enforcement boundary と説明されています。

Project overview

項目内容
RepositoryFirma-AI/openfirma
位置づけAI agent 向け runtime outbound governance boundary
Stars約 94
Forks3
主要言語Rust
LicenseApache-2.0
Latest releasev0.1.1
主要構成Sidecar + Authority + Cedar policy

解いているのは「model が暴走するか」ではなく「暴走したとき誰が止めるか」

Agent の安全性を話すとき、注意は system prompt、tool schema、approval flow、HITL に寄りがちです。

もちろんそれらは大事ですが、共通する弱さもあります。最終的な outbound action が実行される直前に、agent process の外側で強制できる境界があるか という点です。

openfirma はそこに重心を置いています。Agent の outbound call は local の Sidecar を通り、実行前に次の処理を受けます。

  • action class への正規化;
  • capability token の検証;
  • local Cedar policy による判定;
  • ALLOW のときだけ続行;
  • DENY のときは遮断し、署名付き audit event を残す。

つまり見ているのは「危なそうに見えるか」ではなく、実行前の一跳びを止められるか です。

重要なのは、policy も判定も model に依存させていないこと

README で印象的なのが no model on the hot path という考え方です。

ここはかなり重要です。安全判定まで model に依存すると、model の揺れ、prompt のドリフト、context 汚染の影響をそのまま受けます。実行境界は、できるだけそういう不安定さから切り離した方が良いです。

openfirma の構成はかなり明快です。

  • policy は自分で定義する;
  • policy 言語には Cedar を使う;
  • 判定は local sidecar が行う;
  • authority は capability token、policy bundle、revocation を配る;
  • agent は生の credential を直接保持しない。

これは「危ないことをしないで」と prompt に書くやり方より、ずっと硬い境界です。制約を language layer ではなく execution layer に置いているからです。

firma run が用意されているのはかなり実務的

安全系 tool は、考え方が良くても最初の導入が重すぎて使われなくなることがあります。

その点 openfirma は入口をかなり現実寄りにしています。README の最短ルートはこれです。

firma run -- claude

まだ authority や sidecar がなければ local に起動し、その session のあいだだけ enforcement を有効化します。継続的に使いたいなら firma config と firma sidecar start --detach に移ればよい、という設計です。

この分け方はかなり良いです。

  • まず試したい人は 1 command で始められる;
  • 複数 session を束ねたい人は persistent authority に進める;
  • 自前 runtime で使いたい人は HTTP_PROXY / HTTPS_PROXY の sidecar モードに行ける。

単一の使い方に固定せず、軽い導入から本格運用までつながっているのが強みです。

Cedar policy と pack モデルがあるので、ただの proxy で終わっていない

もし安全 tool が「全部 deny」か「全部 allow」しかできないなら、実案件では長続きしません。

openfirma はその点でも少し進んでいます。README では次の構成が明示されています。

  • posture pack: 既定で何を許すかを決める;
  • mapping pack: 個々の service の HTTP call を治理 action に写像する;
  • policy file は .firma/policies/ に置き、authority が自動で hot reload する;
  • firma policy validate と firma policy test で事前確認できる。

Posture もすでに

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

に分かれていますし、mapping も openai、anthropic、github、gmail、stripe、npm、pypi、cargo が用意されています。

ここを見ると、単に「agent を管理できるはず」という idea ではなく、実際の service call をどう分類して policy に落とすか まで考え始めていることが分かります。

単純な local proxy より面白いのは、多 agent / 多 machine を前提にしている点

単一 agent に proxy を噛ませるだけなら、発想としてはそこまで新しくありません。

openfirma がより面白いのは、README で operating model をちゃんと分けているところです。

  • 単一 agent の local quickstart;
  • 1 台で複数 agent が同じ authority を共有する形;
  • team authority を使って複数開発機や CI runner に配る形;
  • custom authority と custom runtime を組み合わせる形。

ここで重要なのは、policy distribution と local enforcement を分離していることです。Sidecar は自分の machine 上で per-call enforcement を行い、authority は信頼の根として policy と token を配ります。

この構成なら、

  • 複数開発者の協業;
  • CI 上の agent 実行;
  • 企業内の controlled runtime;
  • revoke や audit の集中管理;

にも広げやすいです。

Stars がまだそこまで多くない project としては、かなり product 的な境界設計が見えます。

開発 workflow に入り込みやすい形なのも強い

安全製品が開発現場に残らない理由は、価値不足より「作業の流れに入ってこない」ことの方が多いです。

今の openfirma はむしろ developer tool 的です。

  • CLI である;
  • 1 command で試せる;
  • monitor で判断を追える;
  • policy 更新を自動反映できる;
  • claude や codex のような実際に回される agent を前提にしている;
  • 単発 session と常駐運用の両方を持っている。

この性質はかなり大事です。最終的に残るのは、理論上もっとも正しい制御機構より、最初に現実の workflow に入れたもの だからです。

v0.1.1 の release note からも、どこを磨いているかが見える

現時点の最新 release v0.1.1 は派手な大型機能ではありませんが、release note はかなり示唆的です。

特に目についたのは次のあたりです。

  • one-line installer の復元;
  • firma config の platform-aware な scaffold 改善と WSL backend 選択の修正;
  • codex 実行時の nested bwrap 制限への対応;
  • managed seccomp policy の適用整理;
  • startup 前チェックと sidecar config validation の改善。

どれも demo 向けではなく、実際に agent を走らせたときに出る痛みを潰している変更です。こういう release の方が、project が現実の環境差分に向き合っていることをよく示します。

どんな人に向いているか

次のような状況なら、openfirma はかなり見る価値があります。

  • agent が GitHub、mail、package registry、外部 API に本当に触れる;
  • 何を許すかを prompt だけに委ねたくない;
  • 外部呼び出しを call 単位で止めたいし audit したい;
  • policy を team の資産として管理したい;
  • 別の model service に安全判断を再委託するのではなく、local-first に境界を置きたい。

逆に、まだ権限のない軽い local agent を時々動かすだけなら、ここまでの構成は少し重いかもしれません。ただ、agent が本当に外部システムを触るようになるほど、この種の runtime boundary の重要性は確実に上がります。

まとめ

Firma-AI/openfirma の価値は、「AI agent に安全説明を足した」ことではなく、実行境界そのものを独立した部品として用意した ところにあります。sidecar interception、Cedar policy、authority distribution、JIT credentials、signed audit、per-call enforcement が 1 つの筋として通っています。

Prompt や approval だけで片付けるより難しい道ですが、必要なのはむしろこういう種類の硬さです。Agent を本当に software operator として扱い始めるなら、openfirma のような project は早めに追っておく価値があります。