[compliance] DIFC integrity level discrepancy: list_repository_collaborators uses writer vs stated reader intent

[github-actions]

MCP Gateway Compliance Review — 2026-05-16

Summary

During the daily compliance review of commit 96b1b5a (PR #5818), one discrepancy was found between the stated design intent in the PR description and the actual implementation. All previously validated compliance aspects remain passing.

Recent Changes Reviewed

• Commit: 96b1b5a — fix(guard): classify discussion_comment_write; add list_repository_collaborators DIFC rules (#5818)
• Files: guards/github-guard/rust-guard/src/tools.rs, guards/github-guard/rust-guard/src/labels/tool_rules.rs

Important Issues (SHOULD violations)

1. list_repository_collaborators integrity level: PR states reader, code implements writer

Specification Section: DIFC Guard Policy — Integrity Label Assignment
Deep Link: Internal DIFC guard specification (see guards/github-guard/docs/INTEGRITY_TAG_SPEC.md and guards/github-guard/docs/LABELING.md)

Requirement (from PR #5818 description):

list_repository_collaborators: S=S(repo), I=reader — uses reader-level integrity (one level below writer) because the response reveals who holds write/admin access, making it access-sensitive relative to other repo metadata reads

Current State:
In guards/github-guard/rust-guard/src/labels/tool_rules.rs:393, the implementation uses writer_integrity(repo_id, ctx) (approved-level, level 2), and the in-code comment also says I = writer (GitHub-controlled repository access metadata). The unit test at line 946 asserts writer-level integrity.

Gap:
The PR description explicitly justified a reader/unapproved integrity level because this tool reveals who holds write/admin access — access-sensitive data that agents should not freely use to influence write operations. However, the code assigns approved-level (writer_integrity) instead. This is internally inconsistent: either:

• The PR rationale was correct → the code should use reader_integrity to prevent misuse of collaborator data in write decision paths, OR
• The code is correct (GitHub-controlled metadata deserves approved trust) → the PR description was inaccurate and misleading to future reviewers.

Severity: Important — DIFC integrity labeling governs what trust-level agents need to act on this data. An incorrect label could either over-restrict legitimate use or under-restrict a sensitive read that could influence write operations.

File References:

• guards/github-guard/rust-guard/src/labels/tool_rules.rs:387–394 (implementation)
• guards/github-guard/rust-guard/src/labels/tool_rules.rs:929–947 (test)

Suggested Fix:
Resolve the ambiguity by explicitly deciding which integrity level is correct:

Option A — Use reader_integrity (matches PR rationale):

"list_repository_collaborators" => {
    // S = private policy scope — access-controlled even for public repos
    // I = reader (unapproved) — access-sensitive; prevents this data from
    //     directly authorising write operations in agent pipelines
    secrecy = policy_private_scope_label(&owner, &repo, repo_id, ctx);
    integrity = reader_integrity(repo_id, ctx); // changed from writer_integrity
}

Update the test assertion message to "list_repository_collaborators must produce reader-level integrity".

Option B — Keep writer_integrity (matches code comment):
Update the PR description (post-merge note) or add a comment explicitly documenting why GitHub-controlled repository access metadata deserves approved-level trust, referencing how list_tags / get_release_by_tag use the same level.

---

Compliance Status

Section	Aspect	Status
Configuration Format (§4.1)	JSON stdin, required fields, schema validation	✅ Compliant
Containerization (§3.2.1)	stdio servers require Docker, command field rejected in stdin	✅ Compliant
Protocol Behavior (§5)	/mcp/{server}, JSON-RPC 2.0, timeouts	✅ Compliant
Authentication (§7)	Authorization header, 401 on invalid/missing, health exempt	✅ Compliant
Health Monitoring (§8)	/health endpoint, 30s interval	✅ Compliant
Error Handling (§9)	Startup failures, exit code 1, JSON-RPC errors	✅ Compliant
Variable Expansion	Fail-fast on undefined ${VAR}	✅ Compliant
DIFC Guard: discussion_comment_write	Correctly added to WRITE_OPERATIONS with writer integrity	✅ Compliant
DIFC Guard: list_repository_collaborators	Integrity level mismatch between PR intent and code	⚠️ Needs clarification

References

• MCP Gateway Specification
• Commit reviewed: 96b1b5a
• Previous compliance run: c9fd415 (2026-05-15, all aspects passed)

Note

🔒 Integrity filter blocked 1 item

The following item was blocked because it doesn't meet the GitHub integrity level.

• get_file_contents get_file_contents: has lower integrity than agent requires. The agent cannot read data with integrity below "unapproved".

To allow these resources, lower min-integrity in your GitHub frontmatter:

tools:
  github:
    min-integrity: approved  # merged | approved | unapproved | none

Generated by Daily Compliance Checker · ● 1.4M · ◷