Review the read-only governance agent threat model and permissions #2599

Problem

The accepted Base governance implementation plan assigns this existing issue to package 21a. Its previous scope no longer matches the accepted review-loop and automation boundaries, so this issue has been reconciled to a bounded deliverable and remains in Triage/Backlog until independently reviewed.

Expected behavior

Narrow the old broad agent-loop authority proposal to the read-only governance reviewer in package 21. Threat-model issue/PR/comment text, repository files, diffs, CI output, artifacts, branch names, model output and API failures as untrusted input. Define minimum GitHub read permissions plus comment-only finding publication, exact revision binding, provenance, redaction, provider disclosure and failure-closed behavior. Explicitly exclude code execution, repository writes, fixes, Project/status mutation, secrets, push, merge, release and policy changes.

Scope and non-goals

Scope: Narrow the old broad agent-loop authority proposal to the read-only governance reviewer in package 21. Threat-model issue/PR/comment text, repository files, diffs, CI output, artifacts, branch names, model output and API failures as untrusted input. Define minimum GitHub read permissions plus comment-only finding publication, exact revision binding, provenance, redaction, provider disclosure and failure-closed behavior. Explicitly exclude code execution, repository writes, fixes, Project/status mutation, secrets, push, merge, release and policy changes.

Non-goals: Do not use the rejected Agent Assignment/autonomy state machine; do not expand authority or silently change the accepted design; do not activate enforcement or make status/merge changes before the required gates.

Affected areas

• docs/security and reviewer automation permission contract, workflow permissions, audit/provenance schema.
• Accepted source: governance design and implementation plan, PR #2664
• Parent tracker: #2665

Impact and evidence

1. Product intent: Implements the accepted governance design; no product-requirement change is authorized here.
2. Architecture and contracts: Destination: package 21a of the accepted plan in PR Revise the Base ecosystem governance design and implementation plan #2664, plus the named issue contract.
3. User guidance: Likely destinations: docs/security and reviewer automation permission contract, workflow permissions, audit/provenance schema.; the implementation PR must name exact paths or provide a change-specific no-impact reason.
4. CLI/API and reference: Update the applicable reference if behavior/commands change; otherwise the implementation PR states why no CLI/API surface is affected.
5. Operations and safety: The scope states its authority boundary and rollback; no merge/release authority is implied.
6. Validation and testing: Validation steps are listed below; the PR records executed evidence and explains unavailable checks.
7. Examples and downstream use: The PR identifies affected examples/consumers or gives a scoped repository search as evidence of no impact.
8. Governance and contributor process: This issue applies the accepted process rule and does not duplicate Project fields in the body.
9. Decision records: No new decision is accepted by this issue; any deviation requires explicit maintainer approval and a superseding record.
10. Release notes: The PR includes a release-note line or a reasoned none; no user-facing release claim is pre-approved here.

These are issue-stage dispositions; refine exact paths and evidence in Triage before Ready. The implementation PR repeats the ten categories against the actual diff.

Open questions

• None beyond the scope-specific gates above. If evidence changes the accepted contract, return to Triage and obtain a separate maintainer decision.

Plan

• S1: One focused PR for this issue. Use Fixes #N if single-PR; if a maintainer approves more than one PR, name slices S1…Sn before opening them and use Part of #N.
• Dependencies: #2666, #2680
• Acceptance criteria:
• Threat model and permission matrix cover prompt injection, malicious repository content, CI artifacts, secret-shaped text and API ambiguity.
• Reviewer reads only the exact issue/PR/code revision and may publish evidence-backed findings through comments; no code or policy write is possible.
• No secrets or release credentials are available; logs redact sensitive values and record tool/model/session, rules version and reviewed SHA.
• Fixtures prove untrusted content cannot expand scope, execute code or grant authority.
• Any automated fix or draft-PR capability remains deferred to a separate maintainer-approved authorization model.
• Validation:
• Add offline prompt-injection, secret-redaction, denied-path, stale-SHA, API-failure and authority-escalation fixtures.
• Verify token scopes and workflow permissions in a non-secret test repository.
• Review threat model with maintainer before the read-only pilot.
• Risks and rollback: Comment-only credentials still write to GitHub discussions; scope them to the target PR/issue comment surface and disable the pilot on any unexpected mutation.
• Decision impact: No decision is accepted by implementation alone; record accepted decisions and file a superseding ADR if a change is approved.