Use collaborator permission level instead of author_association for integrity filtering

[lpcox]

Problem

Integrity filtering currently determines a user's trust level based on the author_association field from GitHub API responses. This field is unreliable for org admins who haven't been explicitly added as collaborators on a specific repository.

How it works today

The Rust guard maps author_association to integrity levels in helpers.rs:960-980:

author_association	Integrity Level
OWNER, MEMBER, COLLABORATOR	approved (writer)
CONTRIBUTOR, FIRST_TIME_CONTRIBUTOR	unapproved (reader)
FIRST_TIMER, NONE	none

The bug

GitHub's author_association field reflects the user's direct relationship with the repository, not their effective permissions. An org admin who:

• Has full admin access to a repo via org ownership
• But hasn't been explicitly added as a collaborator

...gets author_association: "CONTRIBUTOR" (if they've contributed before) or "NONE" (if they haven't). This maps to unapproved or none integrity, causing their issues, PRs, and comments to be filtered out by the integrity filter.

This is a fundamental limitation of the GitHub API's author_association field — it doesn't know about org-level permissions.

Impact

• Org admins' content is silently filtered from agentic workflow results
• Users must work around this by explicitly adding themselves as collaborators, using min-integrity: none, or configuring trusted-users
• The workarounds defeat the purpose of integrity filtering or require per-user configuration

Upstream issue

See github/gh-aw#23565

Proposed Solution

Supplement author_association with a call to the collaborator permission endpoint:

GET /repos/{owner}/{repo}/collaborators/{username}/permission

This endpoint returns the user's effective permission level, which correctly includes inherited org permissions:

{
  "permission": "admin",
  "user": {
    "login": "example-user",
    "id": 12345
  }
}

Permission-to-integrity mapping

Collaborator Permission	Integrity Level
admin, maintain, write	approved (writer)
read (triage)	unapproved (reader)
none	none

Implementation approach

Option A: Gateway-side enrichment (recommended)

Add a new enrichment call in the gateway proxy (internal/proxy/proxy.go) alongside the existing pull_request_read and issue_read enrichment paths:

1. When the Rust guard needs to determine integrity for an issue/PR author, the gateway calls GET /repos/{owner}/{repo}/collaborators/{username}/permission using the enrichment token
2. Pass the permission field to the guard alongside (or instead of) author_association
3. The guard uses permission as the primary signal, falling back to author_association if the permission call fails (e.g., insufficient token scopes)

This fits naturally into the existing restBackendCaller pattern in proxy.go:274-341.

Option B: Guard-side callback

Extend the WASM guard's backend callback interface to support a new get_collaborator_permission call. The guard would call this from tool_rules.rs when labeling issues/PRs, similar to the existing get_pull_request_facts() and get_issue_author_info() callbacks in backend.rs.

Key considerations

1. Token permissions: The GET /repos/{owner}/{repo}/collaborators/{username}/permission endpoint works with the standard GITHUB_TOKEN in Actions as long as the query is scoped to the same repository (see gh-aw#23565 comment). No additional token scopes needed.

2. Caching: Permission lookups could be cached per (repo, username) pair for the duration of a session to avoid redundant API calls.

3. Fallback: If the permission endpoint returns an error (403, 404), fall back to the existing author_association logic so the feature degrades gracefully.

4. Existing precedent: The gh-aw compiler already uses github.rest.repos.getCollaboratorPermissionLevel() for /slash_command permission checks (see checkRepositoryPermission in gh-aw's check_membership.cjs).

Files that would need changes

• internal/proxy/proxy.go — Add enrichment call for collaborator permission
• guards/github-guard/rust-guard/src/labels/backend.rs — Add get_collaborator_permission callback and data structure
• guards/github-guard/rust-guard/src/labels/helpers.rs — Add collaborator_permission_floor() mapping function
• guards/github-guard/rust-guard/src/labels/tool_rules.rs — Use permission-based integrity as primary signal for issues/PRs

[lpcox]

MCP Gateway Mode: Implementation Details

The proposed solution in the issue body focuses on proxy mode, but the MCP gateway mode (routed/unified) has a fundamentally different enrichment architecture that needs its own approach.

How enrichment works today in MCP gateway mode

The WASM guard is sandboxed — it can only communicate with the outside world through a single host function: call_backend (defined in internal/guard/wasm.go:158-184). This routes through:

WASM guard → call_backend(tool_name, args) → hostCallBackend()
  → guardBackendCaller.CallTool() → executeBackendToolCall()
  → GitHub MCP server container → GitHub API

Today the guard calls exactly 3 MCP tools for enrichment:

• pull_request_read → extracts author_association (backend.rs:284-356)
• issue_read → extracts author_association (backend.rs:408-461)
• search_repositories → checks repo visibility

The problem

There is no MCP tool in the GitHub MCP server that wraps GET /repos/{owner}/{repo}/collaborators/{username}/permission. The WASM guard cannot make arbitrary REST API calls — it is strictly limited to MCP tool calls through the call_backend interface.

Proposed solution: Synthetic tool interception

The guardBackendCaller.CallTool() implementation in unified.go can intercept a synthetic tool name and handle it as a direct REST API call instead of forwarding to the MCP server:

WASM guard calls: invoke_backend("get_collaborator_permission", {owner, repo, username})
  → hostCallBackend() reads tool name from WASM memory
  → guardBackendCaller.CallTool() sees "get_collaborator_permission"
  → instead of MCP forward, makes direct REST call:
    GET /repos/{owner}/{repo}/collaborators/{username}/permission
  → returns {"permission": "admin"} to WASM guard

This keeps the WASM interface (call_backend) unchanged — it is already generic over tool names.

Token requirement

The gateway needs a GitHub token for the direct REST call. Options:

• Reuse GITHUB_PERSONAL_ACCESS_TOKEN (already in the gateway's environment for passing to containers)
• Add a new enrichment_token config field
• The endpoint works with the standard GITHUB_TOKEN in Actions when querying the same repository (confirmed in gh-aw#23565)

Changes needed (MCP gateway mode)

Layer	File	Change
Gateway	internal/server/unified.go	guardBackendCaller.CallTool() intercepts get_collaborator_permission and makes direct REST call
Gateway	internal/server/unified.go	Add HTTP client + token access for enrichment
Rust guard	src/labels/backend.rs	Add get_collaborator_permission() function using existing invoke_backend callback
Rust guard	src/labels/helpers.rs	Add collaborator_permission_floor() mapping: admin/maintain/write → approved, read → unapproved, none → none
Rust guard	src/labels/tool_rules.rs	Call get_collaborator_permission() first, fall back to author_association if it fails

Caching consideration

Permission lookups should be cached per (repo, username) pair for the session duration. The guard already extracts author_login from PR/issue responses, so the username is available. A simple in-memory cache in either the gateway or the WASM guard would avoid redundant API calls when the same author appears in multiple items (e.g., list_issues returning 30 issues by the same org admin).