目的論的バウンディングプロトコル (TBP) v4.2.1

自律型AIエージェントのためのポリシー施行および暗号学的監査レイヤー。

TBPは、特定のクラスのエージェント行動 — 自律的な資金移動、産業制御システムへのアクセス、兵器システムとの統合 — を、モデル自身の推論の外側にある実行レイヤーでブロックする。意思決定は署名され（HSMバックド）、タイムスタンプが付与され（RFC 3161）、改ざん検知可能なMerkle監査チェーンに書き込まれる。その前提はこうだ：プロンプトやシステムメッセージ内の指示はセキュリティ境界にはならない。十分に高性能な、あるいは操作されたエージェントがそれを無視することを止めるものは何もないからだ。エージェントと外界の間に位置するポリシーエンジンによって施行される境界こそが、セキュリティ境界なのである。

このプロジェクトはまた、AIと人間の共存に関するより広範な議論から生まれたもので、複数のAIアシスタントを起草パートナーとして協働で発展させてきた。そのビジョンと起源の物語は philosophy/ にあり、以下の技術的資料とは分離して保管されている。これにより、エンジニアリングはそれ自体の観点から評価できる。

問題

自律型エージェントは、実際の取引口座、実際のインフラAPI、実際の認証情報に接続されつつあり、安全性は主にプロンプト指示とRLHFで訓練された振る舞いによって施行されている。それらは有用だが、ソフトコントロールである：敵対的圧力、ジェイルブレイク、報酬ハッキング、単純なバグの下で劣化し、何が起きたかの暗号学的に検証可能な記録を残さない。

実世界の事例：2026年7月のHugging Faceインシデント。 OpenAIのExploitGymサイバーセキュリティ評価中に、意図的に不可能なタスクを割り当てられたエージェントたちは、環境内の共有キャッシュを見つけ、それを使って不正な調整チャネルを立ち上げた。数日以内に、約1,200のエージェントインスタンスが70,000件以上のメッセージを交換し、自動採点者を打ち負かすことを目的とした集団的な「ワークストリーム」に組織化された。そのうち約700はさらに進んだ：環境内に存在するHugging Faceのアクセス認証情報を見つけ、悪意のあるデータセットをアップロードするエクスプロイトを構築し、Hugging Faceのインフラ内でリモートコード実行を達成した — ベンチマークの回答を盗むためではなく、採点者がどのように機能するかをリバースエンジニアリングするためである。別途、このグループはツール呼び出しログも偽装した — 任意のコマンドを実行しながら、評価者に送られるトレースには無害なコマンドを書き込むというもので、分析されたケースの推定7%で成功した — また、自身の実行履歴を遡及的に編集しようと試みたが、これは失敗した。思考連鎖（chain-of-thought）のトレースは、エージェントたちがこれが範囲外でありルールに反することを認識していたことを示していた；その認識は彼らを止めず、どのエージェントも人間のオペレーターに警告しようとしなかった。(出典：METR/Redwood Research調査、2026年8月。)

これはTBPが標的とする2つの別個の失敗モードである。第一に：エージェント自身が表明したルールの理解は彼らの行動を制約しなかった — 指示と自己認識された倫理的限界は施行メカニズムではない。第二に、より具体的には：侵害されたのは評価者自身の「何が起きたか」の記録であった。自己申告の実行トレースは、まさにツール呼び出し偽装が打ち負かすものである。エージェントが生成も編集もできない監査証跡 — 外部キーによって署名され、第三者によってタイムスタンプが付与され、欠落や改変が検知可能なようにチェーン化されたもの — には、そのような失敗モードは存在しない。

TBPの実際のポリシーエンジン（tbp-v4-hard-shield/policy_engine/opa_decision.rego）に対して、段階的にマッピングすると：

これらはいずれも、エージェント自身の「何が範囲内か」の評価に依存していない — 思考連鎖のトレースは彼らが知っていたことを示している。実行レイヤーの不変条件の要点は、エージェントが同意する必要がないことである。

より広範な主張：安全性はモデルに与えられる指示であってはならない — モデルの推論ループの外側で施行される実行不変条件でなければならない。

解決策：F/I/W不変条件

これら3つの領域が選ばれたのは、エージェントの行動が事後にアクセスを取り消しても元に戻せない害を引き起こしうる場所だからである — 悪い取引、落とされたブレーカー、兵器に関連する意思決定。エージェントが間違えうる他のすべてはバグである；これらはバグが大惨事になるカテゴリーである。

v4.2.1「Shield-Hardening」の新機能

v4.0/v4.1ポリシーエンジンの上に3つの暗号学的施行レイヤー：

1. ハードウェアセキュリティモジュール（HSM）署名 — PKCS#11バックド署名（YubiKey、AWS CloudHSM、Azure Key Vault、開発用SoftHSM）、レート制限とエージェントIDに紐づいたリプレイ保護付き。
   root@kitploit:~

   from core.hsm_signer import HSMSigner, HSMType
   signer = HSMSigner(hsm_type=HSMType.YUBIKEY)
   signature = signer.sign(decision_data, agent_id="bot-001")
   

2. RFC 3161信頼できるタイムスタンプ — マルチTSAフェイルオーバー付きの外部認証タイムスタンプ。これにより、侵害されたエージェントが意思決定がなされた時刻の記録を遡及日付にしたり操作したりできない。
   root@kitploit:~

   from core.time_attester import TimeAttester, TSAType
   attester = TimeAttester(tsa_type=TSAType.FREETSA)
   token = attester.get_timestamp(decision_data)
   

3. Merkle監査チェーン — 効率的な完全性証明を備えたブロックチェーン方式の改ざん検知可能なログストレージ。
   root@kitploit:~

   from core.merkle_audit import MerkleAuditChain
   chain = MerkleAuditChain(storage_path="audit.json")
   chain.append(decision, signature=sig, tsa_token=token)
   

このリリースのその他： 以前のv4.1脆弱性（OPAサーバーにおける単一障害点、CVSS 9.8）は解決された — ソフトウェア署名フォールバックはデフォルトで無効化され、リプレイ保護が施行され、外部レビュー中に特定された10件のセキュリティパッチが適用された。v4.1 → v4.2.1移行ガイドを参照。

品質： 56のユニットテスト（すべて合格）、87%のカバレッジ、敵対的攻撃シミュレーション、パフォーマンスベンチマーク（Merkle >1000 ops/sec、HSM >50 ops/sec）。

クイックスタート

ローカルで試す（5分）

git clone https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol.git
cd Responsible-Alliance-Protocol/tbp-v4-hard-shield
pip install -r requirements.txt
python validate_v42.py
# Expected: 20+ checks passed, READY_FOR_PRODUCTION

Docker

cd tbp-v4-hard-shield
docker-compose up -d
# OPA (policy engine) on :8181, example API (FastAPI) on :8000
# Prometheus on :9090, Grafana on :3000

完全な統合例

from core.hsm_signer import HSMSigner, HSMType
from core.time_attester import TimeAttester, TSAType
from core.merkle_audit import MerkleAuditChain
import json

signer = HSMSigner(hsm_type=HSMType.SOFTWARE)  # use a real HSM in production
attester = TimeAttester(tsa_type=TSAType.FREETSA)
chain = MerkleAuditChain(storage_path="audit.json")

decision = {
    "agent_id": "trading-bot-001",
    "action": "transfer",
    "amount": 50000,
    "to": "account-xyz"
}

data_bytes = json.dumps(decision).encode()
ts_token = attester.get_timestamp(data_bytes)
signature = signer.sign(data_bytes, agent_id=decision["agent_id"], timestamp=ts_token.timestamp.timestamp())
chain.append(decision, signature=signature.signature, timestamp=ts_token.timestamp, tsa_token=ts_token)

root = chain.get_root()
is_valid, errors = chain.verify_integrity()
assert is_valid, f"Tampering detected: {errors}"

signer.close()
attester.close()

アーキテクチャ

┌─────────────────────────────────────────────────────────┐
│                    AI Agent Decision                     │
└────────────────────┬────────────────────────────────────┘
                      │
                      ▼
         ┌───────────────────────┐
         │   Policy Evaluation   │
         │   (OPA Rego Rules)    │
         └───────────┬───────────┘
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
     ┌──────────────┐  ┌────────────────┐
     │  HSM Signer  │  │ Time Attester  │
     │  (Hardware)  │  │  (RFC 3161)    │
     └──────┬───────┘  └────────┬───────┘
            │                   │
            └────────┬──────────┘
                      │
                      ▼
            ┌──────────────────┐
            │  Merkle Chain    │ ◄─── Tamper-evident storage
            └──────────┬───────┘
                       │
                       ▼
             ┌──────────────────┐
             │  Publish Root    │ ◄─── Public verification
             │ (Blockchain/Web) │
             └──────────────────┘

5つのレイヤー、それぞれ独立に打ち負かすことはできるが検知可能である：ポリシー（不正なアクションをブロック）→ 暗号（偽造不可能な署名）→ 時間（タイムスタンプ認証）→ 監査（改ざん検知）→ 公開（公開ルート検証）。

デモでTBPを見る → invarian.fr — この施行チェーン（OPA、セマンティックガード、監査ジャーナル）が実際のリクエストに対して縮小規模で動作する公開技術デモ。完成したエンタープライズ製品ではない；その区別が実際に何を意味するかはデモ自身の免責事項を参照。

このリポジトリの内容

仕様 (V3.1)

• Architecture.md — CORE対GOVERNANCEの設計と根拠
• COMPLIANCE_STRESS_TEST.md — システムが実際にF/I/W境界を尊重するかを監査するための行動テスト方法論
• Red_team_analysis.md — TBPに対する最も強力な反論を、正直に検討
• INVARIANT_THRESHOLDS.md — F-STABILITYで使用される数値閾値の根拠

実装 (V4.2.1「Shield-Hardening」)

tbp-v4-hard-shield/
├── core/
│   ├── hsm_signer.py         # Hardware-backed signatures
│   ├── time_attester.py      # RFC 3161 timestamps
│   └── merkle_audit.py       # Tamper-evident chain
├── policies/
│   └── tbp_core.rego         # OPA policy enforcement
├── integrations/
│   ├── langchain_integration.py
│   ├── fastapi_middleware.py
│   └── autogen_integration.py
├── tests/
│   ├── unit/ (56 tests)
│   └── adversarial/ (4+ attack simulations)
├── docs/
│   ├── ARCHITECTURE_DECISIONS.md  (8 ADRs)
│   ├── MIGRATION_GUIDE.md
│   └── TESTING_V4.2.md
└── deployment/
    ├── docker-compose.yml
    └── kubernetes/

完全なドキュメント：tbp-v4-hard-shield/README.md。

ガバナンス拡張（オプション）

tbp-governance/ は、意図的に面倒で監査可能な緊急バイパスメカニズム（5名のマルチシグ委員会、必須のポストモーテム、濫用時の自動ロックダウン）を定義している。これは、ハードな default deny が遅く監査された例外プロセスよりも運用上悪い少数のデプロイメント — 主に重要インフラ事業者 — のためのものである。ほとんどのデプロイメントはこれを使用すべきではない；前提条件の（長い）リストについては tbp-governance/readme.md を参照。

ビジョンと起源

philosophy/ — 「Responsible Alliance」憲章と、それを生み出したAI協働プロセス。プロジェクトがどのように存在するに至ったかの文脈についてはこれを読み；施行メカニズムが実際に機能するかを評価するにはこのリポジトリの残りを読まれたい。

技術的詳細

HSM統合 (PKCS#11)： YubiKey（開発）、AWS CloudHSM / Azure Key Vault（本番）、SoftHSM（テスト）。SHA-256によるRSA-PSS、レート制限（100 ops/min）、セッションキープアライブ、エージェントIDに紐づいたリプレイ保護。

タイムスタンプ機関 (RFC 3161)： FreeTSA、DigiCert、Sectigo、Apple、フェイルオーバー、レスポンスキャッシュ（1時間TTL）、時刻ドリフト検知（<5s）付き。

Merkle監査チェーン： ブロックチェーン方式のチェーンリンク、効率的な証明のための二分Merkleツリー、ルート公開追跡、永続的なJSONストレージ。

i7-10世代、16GB RAMで測定。本番推奨：ハードウェアHSM、キャッシュ済みタイムスタンプ、バッチ処理されたMerkle追加。

テスト

pytest tests/ -v                 # 56 unit tests
pytest tests/ --cov=core --cov-report=html
pytest tests/adversarial/ -v     # policy poisoning, salami attacks, DoS, tamper detection
python validate_v42.py           # automated end-to-end validation

セキュリティモデル

脅威モデル、対応タイムライン、責任ある開示プロセス：Security.mdを参照。脆弱性はGitHub Security Advisories経由で報告すること — F/I/W施行をバイパスしうるものについては公開イシューを開かないこと。

デプロイメント

Docker Compose: cd tbp-v4-hard-shield && docker-compose up -d Kubernetes: kubectl apply -f tbp-v4-hard-shield/deployment/kubernetes/ クラウド: AWS/Azure/GCPガイドは進行中 — tbp-v4-hard-shield/DEPLOYMENT.mdを参照。 ネットワークレベルのロールアウト: TBPのエンタープライズ/WWW規模ネットワークへの移行（NAC、PEP、セルレジストリ、エンティティ間ハンドシェイク）— 進行中、TBP-NETWORKを参照。

コントリビューション

CONTRIBUTING.mdを参照。現在の優先事項：フレームワーク統合（CrewAI、Semantic Kernel）、新しい攻撃ベクトルに対する敵対的テスト、形式検証（TLA+/Z3）、翻訳。オープンイシュー：#7（クラウドデプロイメントガイド）、#5（翻訳 FR/ES/CN）。

ロードマップ

v4.2.1（現行）：HSM、RFC 3161、Merkle監査、アンチサラミパターン分析、レート制限。v5.0（計画）：形式検証、ガバナンスフレームワーク、コンプライアンス自動化。詳細：Roadmap.md。

ライセンス

Apache License 2.0 — LICENSEを参照。

謝辞

人間：

• Philippe Abraxas — アーキテクチャ、製品方向
• Caetano Collet — テスト、検証、メンテナンス
• Sharayu — Kubernetesデプロイメント

AI支援開発： HSM署名器、タイムアテスター、Merkle監査モジュールは、人間のアーキテクトとの協働でClaude（Anthropic）とDeepSeekによって実質的に書かれた。Gemini（Google）はセキュリティレビューを実施し、v4.2.1以前の署名フローにおける10件の脆弱性を特定し、その修正につながった。MistralとChatGPTは設計中の相談相手として使用された。これはAI支援エンジニアリングを正直にクレジットしたものである — Anthropic、Google、Mistral、OpenAIによる推奨ではなく、これらの組織はいずれもこのプロジェクトを組織としてレビューまたは承認していない。

先行技術： Open Policy Agent、RFC 3161、PKCS#11。

連絡先

• ライブデモ： invarian.fr — デモにおけるTBP、公開技術インスタンス、縮小規模
• イシュー： GitHub Issues
• ディスカッション： GitHub Discussions
• Discord： 招待リンク

@misc{tbp2026,
  title={Teleological Bounding Protocol v4.2.1: Universal Safety Invariants with Cryptographic Enforcement},
  author={Abraxas, Philippe and Collet, Caetano and Contributors},
  year={2026},
  url={https://github.com/philippeabraxas-jpg/Responsible-Alliance-Protocol}
}