
TBPプロトコルの理論と実装による、小規模ネットワークからオープンWebネットワークにおけるネットワーク化されたAIの保護
Teleological Bounding Protocol (TBP) のネットワークレベル実装 — 単一マシンから WWW 規模までのエンタープライズ展開に至るまで、ネットワーク上の AI エージェントの行動を証明付きでガバナンスする。
« 既存のアクセス制御は、あなたが中に入れるかどうかを決める。TBP は、中に入った後で何を許されるかを決める — そしてそれを証明する。我々がガバナンスするのはモデルではなく、ケイパビリティである。 »
信頼によるパートナーシップは決してない — あるのは証明付きハンドシェイクのみ。 それが目標である。エンティティ間ハンドシェイク(仕様 §3)により、互いを信頼しないエンティティ同士が、ポリシー、履歴、生存性を互いに証明できる。ハンドシェイク自体はまだ実装されていない(#33)。このリポジトリに現在含まれているのは、その前段階と、それが依拠するもの — PEP、セルブローカーとレジストリ、NAC、監視、デプロイガイド — であり、これにより TBP のガバナンスは単一マシンから、単一組織下の小規模なマシンネットワークへと拡張される。
本番環境向けではない。 使い捨ての鍵、失ってもよいマシン、実データなし。本番リリースが TBP を壊す前に、あなたが TBP を壊してみるために存在する。
TBP-NETWORK は、本番リリースが存在する前に実行して攻撃するためのシンプルなデプロイを提供する。3 台のマシン、それぞれ 1 つのスクリプトでデプロイされる: M1 はセル(brokerd とその OPA)、M2 はアプリケーションサーバ(pepd と小規模なアプリケーション)、M3 はエージェント。これは全体が機能することをテストする — 証明書によって登録されたエージェント、相互 TLS を介した決定、サーバによって検証されるトークン、コントローラによってガバナンスされるサーバのポスチャ — 実際のバイナリと実際の強制を用いて。簡略化されているのは鍵のセレモニーだけである。1 台のマシンでの変種では、セル単体を眺めることができる。
すべては deploy/dev-test/ にある: 各マシンの目的と理由、まっさらな Debian 12 マシンからの正確な手順、テストするシナリオ、どこを攻撃するか、それが何を証明し何を証明しないか — そして、あなたが試す各環境ごとに、あなたの数値とコメントを我々に送る方法。我々はそれを望んでいる。悪用可能なものは公開 issue ではなく SECURITY.md を通すこと。
TBP はすべての穴を塞ぐのではない。すべての穴を監査するのだ。 これは回避すべき制約ではなく、創設上の公準である(仕様 §1: 「我々はすべての穴を塞ぐのではない。穴を影響度で順位付けし、比例的に緩和する — ガバナンスとは配分であり、完全性ではない」)。TBP は自己完結型のセキュリティシステムではない — SELinux、ファイアウォール、IAM、OS レベルのサンドボックスを置き換えるものではなく、設計上決してそうならない。それが行うことはより狭く、かつ譲れない: ガバナンス対象の行動は、暗号学的に証明可能な決定なしには実行されず、いかなる決定も — 許可であれ拒否であれ — 証明不能・非改ざんのまま監査チェーンを逃れない。TBP は、デプロイがすでに持つ強制スタックの上に載るガバナンスと証明の層であり、その代替ではない。
TBP がどれだけ制限するかはデプロイの選択であり、プロトコルの性質ではない。 全許可(監視モード、すべて記録、何もブロックしない)と全拒否の間には、広いスペクトルが存在し、それはセルがどの OPA ルールパックを読み込むか、どのスケール(下記)で動作するか、そしてプラン契約、クォーラム、(計画中の)リスクスコアリング層(#177–#181)をどこまで推し進めるかによって形作られる。個人のラボと規制対象の本番セルは、同一のプロトコルをそのスペクトルの非常に異なる点で実行できる。それは設計によるものであり、欠落ではない — スケール別管理コンソール向けに計画されているルールパック/ポスチャプリセットについては、下記の「次に計画されている作業」を参照。
そのスペクトルのどの点においても動かないものが、ちょうど 2 つある:
tbp4.2.1/README.md を参照。
これらは、事後にアクセスを取り消しても悪い行動が可逆的でないカテゴリである。いかなるデプロイポスチャ、ルールパック、スケールもこれらを緩めない。それ以外のすべて — 許可されるエンベロープがどれほど広いか、オペレータがどれほどの摩擦を受け入れるか、どの構成が人間の署名を要求するか — は、複雑さ、運用上の必要性、そして特定のデプロイが実際に実行できるものの間の選択であり、プロトコル自体の性質ではない。
言語に関する注記: 参照仕様は現在 docs/spec-en-v1.0.md(英語)である — これがコードと監査が依拠すべき文書である。そのバージョン番号が意図的に 1.0 にリセットされているのは、引用可能でバージョン管理された文書へのクリーンな再出発(§13: 「保守的にバージョン管理され、変更は署名付きの証明済み遷移を経る」)であり、ワーキングノート自身のカウントの継続ではない — 番号の大きいワーキングノートが新しい文書ではない。著者のワーキングノート — より密で、より非線形で、設計根拠の掘り下げには有用だが、引用すべきものではない — は 2 言語で存在する: docs/spec-v1.4.10.md(英語)と docs/spec-v1.4.10.fr.md(オリジナルのフランス語)。同じ慣例がリポジトリ全体に適用される: もともとフランス語で書かれたすべての文書は、元のパスに英語の主文書を持ち、フランス語のオリジナルは <name>.fr.md としてその隣に保たれる。用語集(docs/glossaire.md)は依然としてフランス語を出典とし(フランス語文書の §14 がその用語の信頼できる情報源)、読みやすさのために英語の注釈列を持つ — これは変更されていない。
完全な仕様は docs/spec-en-v1.0.md である — これはこのリポジトリにおけるあらゆる設計または構成の決定の信頼できる情報源である。この README は方向づけに必要なものだけを要約している。疑わしいときは仕様が支配する。ワーキングノート(docs/spec-v1.4.10.md、フランス語オリジナルの英訳)は内容的に取って代わられたものではない — 同じプロトコルであり、そちらで先に発展した — が、今後引用すべき参照ではない。
読む際の有用な道標:
docs/glossaire.md — 概念ごとに 1 つの正規用語。このリポジトリのコードとドキュメント全体で一貫して使うこと(CONTRIBUTING.md を参照)。プロトコル自体 — 仕様、形式的ドクトリン、敵対的監査、コア実装(HSM 署名、Merkle 監査チェーン、OPA ポリシーエンジン) — は Responsible-Alliance-Protocol にあり、Apache 2.0(オープン)でライセンスされ、ここでは tbp4.2.1/ に特定のコミットに固定された git サブモジュールとしてツリー内にベンダリングされている — ポインタであり、フォークではない: このリポジトリは、そのコードに対して issue や PR を提出する場所では決してなく、下記のネットワーク展開の部分に対してのみである。このリポジトリは、同じプロトコルのネットワーク規模の展開である: NAC、ローカル PEP、セルレジストリ(エンティティ間ハンドシェイクが目標であり、まだ実装されていない) — TBP を単一のガバナンス対象マシンからガバナンス対象ネットワークへと引き上げるために必要な部分。本通知時点で、このリポジトリ自身のコードも Apache 2.0 である(下記のライセンスを参照) — コアプロトコルと同じライセンスであり、2 つのリポジトリで 1 つのライセンスであり、2 つではない。以前は初期パイロット段階でクローズドライセンスを使用していたが、その段階は終わった。
サブモジュールを最新に保つ: tbp4.2.1/ は自動更新されない — Responsible-Alliance-Protocol のより新しいコミットへバンプすることは、意図的でレビューされた行動(cd tbp4.2.1 && git checkout <commit> && cd .. && git add tbp4.2.1 && git commit)であり、決して自動ではない。上流のセキュリティ修正に黙って遅れる固定サブモジュールは、サブモジュールがまったくないより悪い — バンプは他のあらゆる依存関係の更新と同じ注意をもって扱い、まずコアリポジトリ自身の変更履歴を確認すること。
TBP は 21 の外部セキュリティ、AI ガバナンス、規制フレームワークに対して管理項目ごとに照合されている — マーケティング上の主張としてではなく、何がカバーされ、何が部分的で、何が構造的に TBP のスコープ外かを正直に述べるギャップ分析として。完全な内訳(標準ごとに 1 ファイル、すべての ✅ の背後にある正確なメカニズムへの引用付き)は tbp-compliance/ にある。この表はその要約である。