Trust boundaries¶

English | 日本語

Human authority¶

Humans own material product intent and effects that change secrets, settings, deployment, billing, production state, external publication, destructive ownership, or authority beyond a recorded contract. A model capability never grants effect authority.

Provider boundary¶

Each provider owns authentication, permission consent, transport, and the primitive it performs. AI Teams owns semantic selection and interpretation. Credentials do not move between providers, candidates, or documentation.

Workspace and delivery boundary¶

Untrusted candidate execution can modify only its Issue-linked worktree. It must not receive GitHub write authority or access the publisher filesystem. Trusted delivery verifies repository, Issue, branch, revision, candidate schema, and exact acceptance evidence before a GitHub effect.

This current data-flow view answers one question: what is allowed to cross from untrusted candidate execution into the GitHub-authorized publisher?

flowchart LR
    subgraph untrusted["Untrusted candidate boundary"]
        runner["Candidate runner<br/>no GitHub write authority"]
        worktree["Fresh exact-SHA checkout<br/>no extra filesystem inputs"]
        runner -->|"runs checks"| worktree
    end

    evidence["Bounded candidate evidence<br/>revision, results, pre/post inventory"]

    subgraph trusted["Trusted publisher boundary"]
        credentials["Publisher credentials"]
        publisher["Publisher<br/>verifies identity and acceptance"]
        credentials -->|"available only here"| publisher
    end

    worktree -->|"structured evidence only"| evidence
    evidence -->|"crosses trust boundary"| publisher
    publisher -->|"authorized exact-revision effect"| github["GitHub"]

Candidate code and its filesystem never cross this boundary as publisher inputs. The structured evidence is accepted only after exact identity and cleanliness checks.

Self-hosted pull-request execution¶

The CI workflow dispatches its test jobs for every GitHub-delivered pull_request event covered by the workflow's default activity types, and for pushes to main. The aggregate validate job follows successful tests. The workflow does not contain an actor, branch-owner, or fork-origin gate: all of these jobs select the exact self-hosted, Linux, X64, and ai-teams-ci runner labels.

This configuration is accepted only for the private source repository while every account able to open or update an eligible pull request is inside the trusted repository-member or collaborator boundary. Repository access policy, not the workflow, currently supplies that author boundary. Candidate content is still treated as untrusted: a trusted author does not make candidate code a trusted workload.

Two independent defenses apply:

• read-only workflow permissions limit what GITHUB_TOKEN can change through GitHub APIs;
• each job runs in a fresh disposable container with no host mount, Docker socket, host credential directory, or delivery secret.

Read-only GitHub permissions do not protect the self-hosted host. Container isolation, resource bounds, disposal, and exact runner cleanup protect that boundary. Neither defense may be cited as a substitute for the other.

Conversion to a public repository, execution of pull requests from forks, granting external contributors a path to create or update eligible pull requests, or weakening the runner isolation model requires review and acceptance of a replacement before such jobs run. Accepted containment options are:

1. move pull-request jobs to GitHub-hosted runners;
2. add a fail-closed trusted-author or maintainer-approval gate that prevents self-hosted job dispatch; or
3. use an equivalently disposable isolated provider with no persistent host, credential, or control-plane exposure.

The current decision and its revisit conditions are recorded in Issue #670. The machine-facing runner isolation contract remains the repository self-hosted CI contract.

Control-plane boundary¶

The optional external Qoo257/ai-teams-control surface can start work and therefore is restricted to trusted operators. It owns webhook signatures, exact allowlists, control authentication, origin controls, scheduling, persistence, and worker lifecycle. The Plugin exposes only a bounded client and does not gain Control credentials or runtime ownership. External Control does not become a source of truth for code or Issue state and cannot expand repository effect authority.

Documentation boundary¶

The public HTML view contains no credentials or mutable project state. Generated references read only tracked machine metadata. Build output is disposable and does not become a trusted input to code, tests, delivery, or release.

Operational detail belongs to the human/AI responsibility contract.