Keyboard shortcuts

Press ← or → to navigate between chapters

Press ? to show this help

Press Esc to hide this help

id: ADR-018 title: ランタイムのセキュリティと来歴は、ランタイム所有の判断境界を使用する date: 2026-08-17 status: 提案中 relates-to:

  • https://github.com/zeroclaw-labs/zeroclaw/issues/7142
  • https://github.com/zeroclaw-labs/zeroclaw/issues/6971
  • https://github.com/zeroclaw-labs/zeroclaw/issues/6954
  • https://github.com/zeroclaw-labs/zeroclaw/issues/7432
  • https://github.com/zeroclaw-labs/zeroclaw/issues/7141
  • https://github.com/zeroclaw-labs/zeroclaw/issues/7155
  • https://github.com/zeroclaw-labs/zeroclaw/issues/6996
  • https://github.com/zeroclaw-labs/zeroclaw/issues/6909
  • https://github.com/zeroclaw-labs/zeroclaw/issues/3767
  • https://github.com/zeroclaw-labs/zeroclaw/issues/6105
  • https://github.com/zeroclaw-labs/zeroclaw/issues/8583
  • https://github.com/zeroclaw-labs/zeroclaw/issues/8289
  • https://github.com/zeroclaw-labs/zeroclaw/issues/8290
  • https://github.com/zeroclaw-labs/zeroclaw/pull/10425
  • docs/book/src/architecture/request-lifecycle.md
  • I received only the file path docs/book/src/architecture/background-work-lifecycle.md, not its contents, and I can’t read files from here. Please paste the English text you want translated into Japanese.
  • docs/book/src/architecture/tool-execution-lifecycle.md
  • docs/book/src/security/model.md
  • crates/zeroclaw-api/src/ingress.rs
  • crates/zeroclaw-runtime/src/agent/turn/mod.rs
  • crates/zeroclaw-runtime/src/security/ingress.rs
  • crates/zeroclaw-runtime/src/security/audit.rs
  • crates/zeroclaw-runtime/src/approval/mod.rs
  • crates/zeroclaw-runtime/src/cron/scheduler.rs
  • crates/zeroclaw-runtime/src/tools/send_message_to_peer.rs
  • crates/zeroclaw-runtime/src/tools/spawn_subagent.rs

ADR-018: ランタイムのセキュリティと来歴 — ランタイム所有の決定境界を使用する

コンテキスト

ZeroClaw では、セキュリティに関わる複数の経路で、次の 3 つの問いに同じ形式で答える必要があります。すなわち、「この作業を引き起こしたのは誰または何か」「どのポリシーがそれを許可したのか」「効果が発生する前に、その境界が適用されたことを示す証拠は何か」です。ツール呼び出し、シェルコマンド、gateway や RPC による変更、スケジュールジョブ、SOP のステップ、steering メッセージ、peer-agent への dispatch は、これまでこれらの問いへの答えをそれぞれ別の場所で保持してきました。

その分割によって、2つの障害モードが生じます。新しいアクションパスでは、承認、由来情報（プロヴナンス）の付与、最終的な対象の検証、監査証跡の記録などの手順が抜け落ちる可能性があります。また、新しい拡張ポイントは、ポリシーを決定し、正規の証跡を抑制し、インシデント対応を置き換え可能な一つのプロバイダーとして扱えてしまう場合、過剰な権限を持つことになります。

Three accepted RFCs describe the architecture that fixes this at the runtime boundary:

Wait, I need to be careful here. The input is English, so it should be translated to Japanese. Translating:

承認済みの RFC が 3 件あり、ランタイム境界でこの問題を解決するアーキテクチャを説明しています:

  • #7142 は、保護対象アクションに対するランタイム所有のセキュリティ判定パイプラインを受け付けます。このパイプラインは、組み込みポリシー、正規化されたプリンシパル許可、承認要件、サンドボックス制約、制限オーバーレイ、アクションフィンガープリント、単一使用のランタイム許可、正規化された監査イベント、および結果記録を組み合わせたものです。
  • #6971 では、認証情報サーフェスの権限、セキュリティ態勢のレポート、ランタイムが所有する単一のモデル受け入れ経路が採用されています。認証情報の形式を持つ設定フィールドには明示的な取り扱い分類が必要であり、保護対象の値は保存パスおよびプロパティ読み取りパスに含まれないままです。ランタイムの認証情報境界マップは、平文の認証情報が流れうる箇所を特定します。モデルに送られるすべてのターンおよびステアリング注入は、モデルが参照する前に信頼されたイングレスエンベロープを受け取ります。一方、トランスポートエッジの認証と不正利用対策は、この共有のモデル受け入れレイヤーの外側に留まります。
  • #6954 は、ランタイムが管理する来歴情報を内部起動のターンで受け付けます。cron、daemon、SOP、subagent、peer-agent の作業は、内部プリンシパル、会話バインディング、返信の来歴、コンテキスト欠落時の明示的な動作、そして実行・配信・永続化の各結果の分離を備えている必要があります。

これらの決定は、#7141 の正規プリンシパルに関する決定、#7155 のコマンド/ツール確認に関する決定、#6996 のファイルシステムサンドボックスに関する決定、および #6909 などのコンシューマー固有のターゲット検証に関する決定と隣接するものであり、それらの代替ではありません。

現在のコードベースには、完成形ではなく重要な基盤があります。IngressContext、TurnOrigin、IngressDecision は既に存在します。ターンエンジンはループ開始時と steering drain 時に ingress ポリシーを呼び出します。デフォルトのポリシーは Loop を返します。AuditLogger は再利用可能なハッシュチェーンの基盤です。正規化された principal の基盤も着手されています。内部 principal と結果の分離というスライスは #10425 でレビュー中です。この ADR は目標アーキテクチャを記録するものであり、以下のゲートを満たすまでは提案段階のままとします。

決定

ランタイムを必須のセキュリティ上の権限として維持する

保護対象のアクションは、実行または変更の前に、ランタイムが所有する単一のセキュリティ判定パイプラインを経由します。このパイプラインは、信頼されたランタイムコンテキストから型付きリクエストを構築し、組み込みポリシーと正規のプリンシパルへの付与を解決し、権限昇格の禁止とサンドボックス制約を適用し、制限的なオーバーレイを合成し、必要に応じて信頼された承認を収集し、効果の発生直前に鮮度を再検証し、正規の監査証跡を作成し、単一使用のランタイムパーミットを発行して、そのパーミットを所有された実行境界で消費します。

permit は判断と効果の間の引き渡しを担う。正規化されたアクション、プリンシパル、ポリシーの世代、ランタイムのエポック、ターゲットID、承認の有効期限、フィンガープリントスキーマに紐づけられている。シリアライズすることはできず、引数から再構築することもできず、兄弟アクションのために複製することもできず、2回以上消費することもできない。

セキュリティ上重要な作業は、ランタイムがそれを分類できない場合には拒否されます。新しい保護境界は、所有者、リクエストコンストラクタ、実行境界、必須のポリシーレイヤー、監査分類を明示するアクションインベントリ、または機械的に同等の構造に登録しなければなりません。

拡張機能によってポリシーを狭めることはできても、最低限の基準(フロア)を置き換えることはできないようにする

Restrictive overlays may deny an action, narrow its resources, or require stronger or fresher approval. They may not convert a denial into an allow, broaden principal grants, weaken sandbox or risk-profile limits, choose themselves from untrusted request data, suppress canonical audit events, or mark baseline incident response complete.

Optional audit sinks and responders are separate extension points. They can receive redacted projections or add containment and notification behavior, but they cannot remove, rewrite, delay, or replace the runtime-created canonical event and baseline runtime hooks.

将来の公開プラグイン、WIT、リモートポリシー、動的ライブラリ、またはインシデント対応者向けAPIには、それぞれ独自の実装およびトラストレビューが必要である。本ADRは権限境界を承認するものであり、推測に基づくサードパーティ製セキュリティプロバイダーABIを承認するものではない。

Ճ認証情報を扱う箇所は、機密区分を明確にし、適切に保護し続ける

認証情報の形をした設定フィールドには、明示的な取り扱い分類を設ける必要があります。分類の例は、暗号化されたシークレット、パスのみの参照、公開値、外部認証ストア、互換性のための環境変数パス、フォローアップが必要、です。分類テスト、監査、または機械的に同等のラチェットがない限り、新しい認証情報の形をしたフィールドをスキーマに追加することはできません。

Protected credential values must stay out of save and property-readback paths. 保護された認証情報の値は、保存パスおよびプロパティ読み戻しパスに含まれてはなりません。分類レイヤーは値がどのように保存または公開されるかを示しますが、平文を受け取る可能性のあるすべてのランタイムコンポーネントを単独で決定するものではありません。

別途作成されたランタイムの認証情報境界マップは、プロバイダーおよびチャネルクライアント、ツール、MCPサーバー、委任された作業、CLIラッパー、ゲートウェイハンドラー、ログ、レシート、イベント、エラーパスの間で平文が流れうる箇所を明示します。このADRは、そのマップを必須の実装ゲートとして記録し、それに基づく限定的なハードニングを認めますが、完全な認証情報ブローカーや新しいデフォルトの分離プロファイルは採用しません。

受信コンテンツには、モデルへの受け入れ経路を1つだけ使用する

モデルに送信される各ターンは、モデル実行の前に共有の ingress ポリシーを経由します。各ステアリング注入は、元のターンから古い送信者、メッセージ、トランスポート、信頼に関する情報を引き継ぐのではなく、それ自身の信頼された ingress エンベロープを受け取り、そのエンベロープに基づいて評価されます。

インバウンドポリシーは Loop、Annotate、Gate、Drop のいずれかを出力します。既定値の Loop は現在の動作を維持し、管理対象の SOP 作業は割り当てません。Annotate は、処理を続ける前にコンテンツを信頼できないデータとして扱います。Gate は、ターンを管理対象の人間または SOP の判断経路に引き渡します。Drop はターンを拒否し、その理由を記録します。

トランスポート境界の制御は引き続き必須であり、共有レイヤーとは分離されています。チャネルのペアリング、送信者の許可リスト、署名検証、ペイロード検証、レート制限、プロトコル固有のフィルタリング、リソースの濫用対策は、共有のモデル受け入れレイヤーの前に実行されます。共有レイヤーが判断するのは、正規化されたコンテンツをモデルに入力してよいかどうかだけであり、トランスポートの認証は行いません。

設定可能な非Loopポリシーに到達可能になる前に、未実装の非Loopの処理区分はフェイルクローズ（安全側に失敗）させる必要があります。設定でGateを選択できるようになった後は、LoopとしてフォールスルーするGate分岐はこの決定と両立しません。

実行時の事実から来歴情報を付与する

来歴は、信頼されたランタイムのエントリーコードによって付与され、メッセージの内容やツールの引数によって付与されることは決してありません。起点と信頼性は別の事実です。内部、スケジュール済み、委任済み、または中継された作業は外部のコンテンツに由来する場合があり、直接の呼び出し元が内部であるというだけで信頼されるわけではありません。

Canonical principals from #7141 は、外部または認証済みのアクターが存在する場合に、認証済みのアクター ID と権限付与を提供します。Internal principals from #6954 は、cron ジョブ、デーモンタスク、SOP ステップ、ピアエージェントへのディスパッチ、入れ子になったサブターンなど、ランタイムが所有する開始元を識別します。これらの internal principals は来歴に関する事実であり、外部ピアではありません。また、トランスポートのユーザーであるかのように、ピアグループや権限付与テーブルに現れることは決してありません。

サブターンは親の由来情報を保持するか、親チェーンを記録して、委任された作業が、その作業を引き起こした ID と信頼に関する事実を失わないようにします。SOP 由来とデーモン由来のターンは、トレースと実行記録において、それぞれの具体的なタスクソースを区別できる名前を使用する必要があります。

Bind internal work to conversations without transferring authority

Translation:

内部の作業を会話に紐付けるが、権限は移譲しない

内部的に開始されたターンには、ランタイム内部の会話バインディングを1つ含められます。このバインディングは、履歴の読み込み元と、完了したターンの追記先を示します。ただし、通常のトリムおよび永続化のルールに従います。Cronの session_target = "main" は、エージェントのメインの対話型セッションにバインドされます。一方、isolated は意図的にバインディングを持ちません。

Binding（バインディング）は配信でも記憶の呼び出しでもありません。バインディングは、どの会話がコンテキストと追記の所有者であるかを決定します。配信は、ユーザーにお知らせや返信が表示される場所を決定します。記憶の呼び出しは、引き続き記憶注入ポリシーによって制御されます。

ピアエージェントの返信は、共有セッションではなく不透明な返信の来歴（provenance）を用いる。送信側のターンは、送信前に相関ID、送信者のID、送信者の会話バインディングを取得する。受信側は自身のエージェントとして実行され、送信側のセッションハンドルを読み取ったり参照解決したりすることはできない。完了時に、ランタイムは受信側の最終テキストを、その来歴に沿って追記または配信する。

V1 では、peer reply provenance はプロセスローカルです。ライブプロセスの受信側ターンが完了した場合は、provenance に従って配信するか、失敗した配信結果を記録する必要があります。一方で、プロセスに紐付けられていない処理中の degrade ディスパッチは、crash をまたぐと失われる可能性があります。永続的なディスパッチ行または永続的なキューは別途のフォローアップであり、この V1 の決定には含まれません。

欠落したコンテキストは明示的に扱われます。isolated はバインディングを想定しないことを意味し、require は必須の返信の由来を導出できない場合にディスパッチを拒否し、degrade はバインディングなしで実行しつつ機能低下を記録します。受信者やメッセージ内容によって require を degrade に弱めることはできません。

結果とステータスの根拠は分けて保持する

実行、配信、永続化、監査の永続性は、それぞれ独立した結果です。互換性ステータスはこれらを要約することができますが、独立した各軸から導出される必要があり、競合する信頼できる唯一の情報源として記述してはなりません。

セキュリティ態勢レポートでは、設定上の意図、解決済みまたはプローブ済みの機能、ランタイムで検証された強制力を区別します。active や enforced といった語は、境界を実際に適用したランタイムインスタンスに紐づく証拠に対してのみ使用します。オプションのプロジェクション、ログ、オブザーバーイベント、レシートは有用な証拠を示すことができますが、それ自体が別のセキュリティ上の権威になることはありません。

When the canonical durable audit sink is enabled, the pre-execution event is committed before the protected mutation. If that commit fails, the mutation is denied and security status reports the degraded or unavailable state. Outcome-write failure after an effect records an explicit unknown or degraded audit state, because an action that already ran cannot be undone by audit persistence.

ロールアウトを段階的に分割し、元に戻せる状態を保つ

実装は、ルーティングトラッカー #7432 と、ソースRFCからリンクされた個別の実装Issue・PRに従います。ランタイムセキュリティパイプライン、正規の監査シンク、認証情報サーフェスの分類、ランタイム認証情報境界マップ、インジェスト時のスタンプ付与、非Loopポリシー、内部プリンシパルエンベロープ、会話バインディング、ピア返信の来歴、耐久ディスパッチのフォローアップは、それぞれ独立してレビュー可能なスライスとして取り込まれる必要があります。

単一の PR で、すべてのアクション、すべてのトランスポート、すべての監査シンク、内部ターンのすべてのコンシューマーを、完全なターゲットへ一度にルーティングしようとしてはなりません。各スライスは、そのスライスが互換性の変更を明示的に担当する場合を除き、既存のデフォルト動作を維持しなければなりません。

受け入れゲート

この ADR は、以下の条件をすべて満たすまで提案中のままです：

  • ランタイムのアクションパイプラインには、型付きのリクエストおよび判定の語彙、保護された境界のためのアクション棚卸し（または同等のラチェット機構）、単一使用かつ偽造不可能な許可（permit）、世代およびランタイムエポックの鮮度チェック、そして所有する実行またはミューテーション境界での最終的なターゲット再検証があります。
  • direct、nested、scheduled、delegated、SOP、gateway、RPC、および security-sensitive なツールパスは、登録済みのパイプライン境界を迂回できず、未知または未分類の保護対象アクションはフェイルクローズドで拒否されます;
  • 組み込みポリシー、#7141 のプリンシパル権限付与、権限昇格の禁止、#7155 の承認来歴、#6996 のサンドボックス制約、そして #6909 などコンシューマー固有の再検証は、制限オーバーレイによる制御の対象外にある必須レイヤーのまま残ります;
  • credential 形式の設定フィールドには明示的な取り扱い分類があり、新たに追加された未分類のフィールドを検出して失敗させるスキーマ監査、テスト、またはそれに相当する仕組み（ratchet）が存在する。
  • protected credential values remain absent from save and property-readback paths, with non-exposure coverage where applicable; 保護された認証情報の値は、保存パスおよびプロパティ読み取りパスに引き続き含まれず、該当する場合は非露出のテストカバレッジを含む;
  • ランタイムの認証情報境界マップは、プロバイダーおよびチャネルクライアント、ツール、MCPサーバー、委任作業、CLIラッパー、ゲートウェイハンドラー、ログ、レシート、イベント、エラーパスを対象としており、その結果判明したハardening上のギャップは、認められた認証情報ブローカーとして扱うのではなく、個別の対応タスクとして切り出されています。
  • 標準の最小化されたセキュリティイベントは実行時に生成され、ポリシー判定と結果の証拠を含みますが、シークレットのペイロードは含みません。また、有効化された永続化シンクは、変更の前に実行前イベントをコミットするか、永続化に失敗した場合は変更を拒否します。
  • optional（任意）の監査シンクとインシデント対応担当者は、プロジェクションやレスポンスを追加することはできるが、正規の証跡やベースラインのランタイムフックを抑制、置換、遅延、または書き換えることはできない。
  • すべてのモデル向けターンおよびステアリング注入には、それぞれ専用の信頼されたインジェスト・エンベロープが付与されます。エンベロープには、トランスポート、送信者またはプリンシパル、利用可能な場合はメッセージ ID、発生元（origin）、および信頼に関する情報が含まれ、これらはメッセージ内容ではなく、エントリーコードによって刻印されます。
  • configurable Annotate、Gate、Drop の動作は、未実装の非 Loop ディスポジションが監査証跡とテストを伴ってフェイルクローズするまで有効化できません。
  • トランスポート境界での認証、ペアリング、許可リスト、署名検証、ペイロード検証、レート制限、自己/ボットのフィルタリング、不正利用対策は、正規化されたモデルへの受け入れの前に引き続き適用されます。
  • internal principals は cron、daemon/SOP、peer-agent、subturn のエントリポイントに実装されており、テストによって、それらが出所（プロビナンス）に関する事実であり、peer-membership の付与では決してないことが証明されています;
  • conversation binding は直列化された会話ごとのオーナーを通じて履歴を読み込み、追記します。cron の session_target = "main" は次の対話ターンで表示され、isolated は意図的にバインドされないままです。
  • peer reply provenance は、完了したライブプロセスの受信者出力を、送信者のセッションハンドルを受信者に公開せずに配信または記録します。また、require は受信者やメッセージ内容によって弱められることはありません;
  • execution、delivery、persistenceの各結果は、それぞれ独立して保存または出力され、互換性のための集約値はこれら各軸から導出される。
  • セキュリティ態勢、リリース、常設ドキュメントにおいて、configured、resolved/probed、runtime-verified という証跡表現を正確に使用すること。フェーズ1の足場にすぎなかった従来の active-enforcement に関する主張の訂正を含む；および
  • #7432 およびフォーカスされた実装トラッカーで、残りのスライス、担当者、テスト、リリースまたはロールバックに関する注記を特定してから、この ADR を承認済みとしてマークしてください。

結果

肯定的な結果:

  • Reviewers get one runtime-owned question for protected effects: did this action receive a current decision and consume a valid permit at its boundary?

    Wait — I should be careful about the output. Translating this into Japanese:

    レビュアーは、保護対象の副作用について、ランタイムが管理する質問を1つだけ受け取ります。すなわち、そのアクションは境界において、現行の判断を受け取り、有効な許可（permit）を消費したか、という問いです。

  • セキュリティ拡張機能は、範囲を絞り込んだり投影したりできる一方で、必須の最低限の基準（フロア）を置き換えることはできないため、危険性は低くなります。

  • 受信コンテンツの判断、ステアリングメッセージ、スケジュールされた作業、ピアエージェントからの返信は、ローカルで独自の信頼ストーリーを作るのではなく、共通の由来(provenance)の語彙を共有します。

  • 運用者は、設定済みのポリシー、解決済みの機能、実行時に検証された強制を区別できるため、すべてのステータス出力を同じ程度に証明された情報として読む必要がありません。

  • 内部処理は会話履歴や返信ルーティングに参加できますが、cron ジョブ、SOP ステップ、ピアエージェントを偽の外部チャネルピアとして扱うことはありません。

否定的な結果:

  • ランタイムは、アクションとターンの境界をまたいで、より多くの構造化されたコンテキストを引き継ぐ必要があります。
  • 現在有用なコードパスの一部は、実装スライスが上記で挙げたラチェットとテストを追加するまで、部分的にしか検証されていないままです。
  • デフォルトの動作を維持する段階的なロールアウトは、単一の広範なセキュリティ書き換えより時間がかかります。
  • Loop 以外のイングレス動作と永続的な peer へのディスパッチは、安易にリリースできません。まず、失敗時の挙動、来歴（provenance）、互換性について裏付けとなる根拠が必要です。
  • Audit durability では、有効化するとファイル I/O と fail-closed の動作が加わるため、互換性とロールバックを明示的に扱う必要があります。

参照