Trust boundary¶

English | 日本語

Human authority¶

human は material product intent と、secret、setting、deployment、billing、production state、 external publication、destructive ownership、記録済み contract を越える authority を変更する effect を所有します。model capability は effect authority を与えません。

プロジェクトでの有効化¶

プロジェクト単位の Plugin 読み込みは Codex が所有します。ユーザーの既定を無効にし、明示的に選んだ信頼済みプロジェクトでだけ有効にします。AI Teams の管理情報、キャッシュ内の Skill、機能別の opt-in は無効化を上書きしません。設定と新しいセッションでの確認ははじめにを参照してください。

Provider boundary¶

各 provider は authentication、permission consent、transport、実行 primitive を所有します。 AI Teams は semantic selection と interpretation を所有します。credential を provider、candidate、 documentation 間で移送しません。

Workspace / delivery boundary¶

untrusted candidate execution は自身の Issue-linked worktree だけを変更できます。GitHub write authority や publisher filesystem access を与えません。trusted delivery は GitHub effect 前に repository、Issue、branch、revision、candidate schema、exact acceptance evidence を検証します。

この current data-flow view は、untrusted candidate execution から GitHub-authorized publisher へ何を 渡してよいか、という一つの問いへ答えます。

flowchart LR
    subgraph untrusted["Untrusted candidate boundary"]
        runner["Candidate runner<br/>GitHub write authority なし"]
        worktree["Fresh exact-SHA checkout<br/>追加 filesystem input なし"]
        runner -->|"check を実行"| worktree
    end

    evidence["Bounded candidate evidence<br/>revision、result、pre/post inventory"]

    subgraph trusted["Trusted publisher boundary"]
        credentials["Publisher credentials"]
        publisher["Publisher<br/>identity と acceptance を検証"]
        credentials -->|"ここだけで利用可能"| publisher
    end

    worktree -->|"structured evidence のみ"| evidence
    evidence -->|"trust boundary を通過"| publisher
    publisher -->|"authorized exact-revision effect"| github["GitHub"]

candidate code とその filesystem は publisher input としてこの boundary を越えません。structured evidence は exact identity と cleanliness check の後だけ受理されます。

Self-hosted pull-request execution¶

CI workflow は、workflow の既定 activity type に該当して GitHub から配送されるすべての pull_request event と、main への push に対して test job を dispatch します。全 test 成功後に集約 validate job が続きます。workflow には actor、branch owner、fork origin の gate はなく、これらの job はすべて正確な self-hosted、Linux、X64、ai-teams-ci runner label を選択します。

この構成は private source repository で、対象 pull request を作成または更新できるすべての account が trusted repository member / collaborator boundary の内側にいる間だけ受理されます。 現在の author boundary を提供するのは workflow ではなく repository access policy です。 trusted author が作成した場合も candidate content は untrusted workload として扱います。

独立した2つの防御を適用します。

• read-only workflow permission は GITHUB_TOKEN が GitHub API を通じて変更できる effect を 制限する
• 各 job は host mount、Docker socket、host credential directory、delivery secret を持たない fresh disposable container で実行する

read-only GitHub permission は self-hosted host を保護しません。host boundary を保護するのは container isolation、resource bound、disposal、exact runner cleanup です。一方を他方の代替根拠 として扱いません。

public repository への変更、fork 由来 pull request の実行、external contributor が対象 pull request を作成・更新できる access の付与、runner isolation model の弱化は mandatory review trigger です。その job を実行する前に、次のいずれかの containment を受理します。

1. pull-request job を GitHub-hosted runner へ移す
2. self-hosted job の dispatch を fail closed で防ぐ trusted-author gate または maintainer-approval gate を追加する
3. persistent host、credential、control-plane exposure を持たない同等の disposable isolated provider を使う

現在の decision と revisit condition は Issue #670 に記録します。machine-facing runner isolation contract は repository self-hosted CI contractです。

Runner credential diagnostics¶

非公開の Docker env-file が保護するのは外側の起動処理です。コンテナの起動スクリプトも、 固定した GitHub runner の ACTIONS_RUNNER_INPUT_JITCONFIG 環境変数で JIT 設定を渡し、 シェル、補助スクリプト、listener のコマンドライン引数へ値を含めません。設定を読む前に シェルトレースを無効化します。上流の listener がこの入力を取り込み、1ジョブごとの 登録と削除の既存の動作を維持します。

診断でプロセス引数、環境変数、Docker inspect の全出力を取得しないでください。 実行ファイルの識別情報と認証情報を含むフラグの有無だけを、出力前に機密値を除いて確認します。 同一ユーザー、root、Docker 管理者は引き続きプロセス環境を調べられます。引数への露出を 除くことは、これらの権限保持者から認証情報を隠す保証ではありません。

以前の env-file 対応版にも内部の引数露出が残る場合があります。ホスト所有者の承認後、 ジョブが非稼働であることを確認し、受理済み main のインストーラーで更新します。 CI の一時停止を見込み、旧 runner 登録の不存在、新 runner のオンライン状態、子孫プロセス 引数に認証情報を含むフラグがないことを確認します。過去の認証情報を再送して有効性を 試さず、対象登録の削除証拠を使います。有効性が不明なら所有者が判断します。 旧成果物は復旧用に保持しますが、露出する起動経路へ戻した状態を修正完了とは扱いません。

Runner supervisor cadence¶

このリポジトリのランナー常駐処理は、既存の再試行間隔を維持しながら、長いジョブの 正常終了後に固定の待機を追加しないようにします。この開始間隔と GitHub 側の待ち時間は 別のもので、どちらもテストやマージの必須条件を変更しません。

正常終了した場合は、単調時計で測った処理の開始間隔を最低15秒に保ちます。通常のジョブが 既に15秒以上かかっていれば追加の待機は不要です。短時間の正常終了では残りの時間を待ちます。 終了コードがゼロでも GitHub のジョブを実行した証拠にはならないため、空の終了が続いた場合も JIT 登録が無制限に繰り返されないようにします。失敗した場合は、それまでの実行時間に関係なく、 失敗後に最低15秒の再試行待機を維持します。

単一所有者のロック、容量確認、次の登録前に行うコンテナとランナーの正確な削除確認、 終了要求の処理、--once の動作は変更しません。削除が確認できない場合や容量不足は、 既存の安全側に停止する経路で扱います。常駐処理は引き続き一つの直列実行で、容量や スケジューラーを追加しません。導入と再起動にはホスト所有者の承認が必要で、ソースの受理だけ では許可されません。受理済み main を検証する既存インストーラーを使い、旧ユニットと 変更不能な成果物を復旧用に保持し、サービスとランナーの実際の状態を再確認します。 復旧結果が曖昧な場合は運用者へ引き継ぎます。

診断は既存の範囲を限定した実行結果を使い、認証情報や追加の計測情報は出力しません。 テストでは単調時計を制御し、即時・短時間・ちょうど15秒・長時間の正常終了、短時間と 長時間の失敗、削除失敗を確認します。導入後は変更していない Python 全バージョンの CI 全体を計測します。永続状態、ワークフロー名、対応範囲の移行はありません。

Control-plane boundary¶

任意の外部 Qoo257/ai-teams-control surface は作業を開始できるため trusted operator のみに制限します。webhook signature、exact allowlist、control authentication、origin control、scheduling、persistence、worker lifecycle は 外部 Control が所有します。Plugin が公開するのは bounded client だけで、Control credential や runtime ownership を取得しません。外部 Control は code/Issue state の source of truth にならず、 repository effect authority を拡張できません。

Documentation boundary¶

公開 HTML view に credential や mutable project state を含めません。generated reference は tracked machine metadata だけを読みます。build output は disposable で、code、test、delivery、release の trusted input になりません。

運用詳細は human/AI responsibility contractにあります。

ランナー停止と置き換えの確認¶

停止時は重複するシグナルを保留し、対象の Docker クライアントの終了を確認してから、 cidfile で特定したコンテナと登録だけを回収します。クライアントの TERM/KILL 待ちは 合計最大4秒、プロバイダー呼び出しは各最大5秒です。既存の回収処理の待ち時間予算は 74秒で、明示した systemd の停止期限90秒を下回ります。タイムアウトは回収未完了であり、 広範囲の削除を許可するものではありません。

承認済みインストーラーは30秒以内に、新しいオンライン登録、承認済みイメージで動く 新しいコンテナ、および旧登録・旧コンテナの消失を確認します。サービスの active 状態 だけでは成功とせず、確認できなければ既存のユニット復元処理へ進みます。別途承認を受けた 実稼働環境の再起動前に、対象が idle でジョブを中断しないことを確認し、復元用の旧リビジョン のユニットとイメージを保持してください。生のプロセス引数やコンテナ環境変数は取得せず、 対象ID・イメージ・状態だけを確認します。プロセステストが証明するシグナル処理の順序とは 別に、実際の systemd/Docker を通した適用結果の確認が必要です。