Integrity filter blocks triggering PR read on public repos with auto-approved min-integrity

[lpcox]

Problem

When a workflow runs on a pull_request event on a public repository, the MCP gateway's auto-default policy sets min-integrity: approved. However, the triggering PR itself typically has unapproved integrity (it hasn't been approved yet — that's usually what the workflow is trying to do). This creates a chicken-and-egg problem: the agent cannot read the PR it was triggered to review because the PR does not yet meet the minimum integrity threshold.

Observed Behavior

PR: github/gh-aw#23425
Workflow: Smoke Claude (PR review bot)
Run: https://github.com/github/gh-aw/actions/runs/23707807704
Review: github/gh-aw#23425 (review)

The review posted by the workflow contains:

🔒 Integrity filter blocked 1 item

• feat: integrity-aware cache-memory with git-backed integrity branching and policy-scoped keys gh-aw#23425 pull_request_read: has lower integrity than agent requires. The agent cannot read data with integrity below "approved".

The workflow auto-defaulted min-integrity to approved because gh-aw is a public repository:

Configured min-integrity: (not set)
min-integrity not configured — automatically setting to 'approved' for public repository

Root Cause

The integrity labeling chain works like this:

1. Public repo → no explicit min-integrity → auto-defaults to approved
2. Triggering PR → pull_request_read calls get_pull_request_facts → gets author_association → maps to integrity level
3. Unreviewed PR → has unapproved integrity (no approving review yet)
4. Guard evaluates: unapproved < approved → blocked

The guard logic in tool_rules.rs correctly assigns integrity based on review state:

• merged → merged integrity
• Has approving review → approved integrity
• No approving review → unapproved (or contributor-floor based on author_association)

This is correct behavior for the guard, but creates a usability problem for PR-triggered workflows on public repos.

Impact

Any PR-triggered workflow on a public repo that:

1. Does NOT explicitly set min-integrity in its frontmatter
2. Needs to read the triggering PR (which is almost all PR workflows)

...will have the triggering PR blocked by the auto-applied approved minimum integrity policy. This affects PR review bots, CI check workflows, and any workflow that reads PR content to generate feedback.

Proposed Fix

The fix should be in the MCP gateway (gh-aw-mcpg), specifically in the integrity filtering logic. The triggering context should receive special treatment:

Option A: Exempt the triggering PR from integrity filtering

When the guard evaluates pull_request_read for the same PR that triggered the workflow, it should bypass the min-integrity check. The rationale: the workflow was intentionally triggered by this PR event, so blocking it from reading the trigger defeats the purpose.

Implementation: The gateway already knows the triggering context via GITHUB_EVENT_NAME, GITHUB_EVENT_PATH, and the PR number from the event payload. When pull_request_read targets the same owner/repo#number as the triggering event, skip the integrity floor check.

Option B: Set triggering PR integrity to the workflow's own integrity level

Instead of exempting, set the triggering PR's integrity to match the workflow's configured min-integrity. This preserves the filtering semantics while ensuring the trigger is always readable.

Option C: Lower auto-default for PR-triggered workflows

When a workflow is triggered by pull_request, auto-default min-integrity to unapproved instead of approved. This is the simplest fix but reduces the security posture for all PR-triggered workflows on public repos.

Recommendation

Option A is recommended — it's the most targeted fix. The triggering event is the workflow's reason for existing; blocking it is always wrong regardless of integrity level. Options B and C have broader side effects.

Artifacts

• Review with blocked item: feat: integrity-aware cache-memory with git-backed integrity branching and policy-scoped keys gh-aw#23425 (review)
• Run logs: https://github.com/github/gh-aw/actions/runs/23707807704
• Guard labeling logic: guards/github-guard/rust-guard/src/labels/tool_rules.rs:191-230
• Auto-default logic: gateway auto-applies min-integrity: approved for public repos when not configured

[lpcox]

Additional Finding: Trusted Bot Elevation Gap

The PR author is app/copilot-swe-agent (Copilot's coding agent). The guard's trusted first-party bot list in helpers.rs includes copilot but the actual login for PRs opened by the coding agent is copilot-swe-agent (with app/ prefix stripped).

Current trusted bot list (helpers.rs:868-885):

• dependabot[bot]
• github-actions[bot]
• github-merge-queue[bot]
• copilot

Missing:

• copilot-swe-agent — the login used by Copilot's coding agent when it opens PRs

This means even if the triggering-PR exemption isn't implemented, PRs authored by Copilot's coding agent should still be elevated to writer/approved integrity as a trusted first-party bot — but they aren't, because the login doesn't match.

Secondary fix

Add copilot-swe-agent to is_trusted_first_party_bot() in guards/github-guard/rust-guard/src/labels/helpers.rs.