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 を与えません。

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-hostedLinuxX64ai-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です。

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にあります。