Summary
The GitHub guard does not fully cover 1 operation from the github-mcp-server. The missing tool has no explicit DIFC labeling rule, meaning its response will not receive proper repo-scoped secrecy and integrity labels.
- MCP tools scanned: 83 (79 standard + 4 additional remote tools)
- CLI write commands scanned: ~30 key write operations
- Guard-covered write tools (tools.rs): 48 explicit entries (40 WRITE_OPERATIONS + 8 READ_WRITE_OPERATIONS), plus prefix patterns (
create_*, delete_*, update_*, merge_*, lock_*, unlock_*)
- Tools with explicit DIFC rules (tool_rules.rs): ~103 match entries
- New gaps found this run: 1 (labeling gap)
MCP Tool DIFC Labeling Gaps (tool_rules.rs)
This MCP tool exists in the upstream server but has no explicit match arm in apply_tool_labels in guards/github-guard/rust-guard/src/labels/tool_rules.rs. It falls through to the _ => { // Default: inherit provided labels } catch-all, which means the response will not have proper repo-scoped secrecy tags or writer-level integrity labels applied.
| Tool Name |
Data Scope |
Suggested Labels |
Risk |
Notes |
create_pull_request_with_copilot |
repo-scoped |
secrecy: S(repo), integrity: writer |
Medium |
Remote-only tool. Creates a PR via Copilot coding agent; response contains repo-scoped PR data. Covered for classification by the create_* prefix pattern in tools.rs, but has no DIFC labeling rule. |
Context: The tool is available only in the Remote GitHub MCP Server (not the local server). Its response is structurally identical to a create_pull_request response (a pull request object with owner/repo context), so it should receive the same DIFC labels.
Suggested fix for tool_rules.rs
Add a match arm to the apply_tool_labels function in guards/github-guard/rust-guard/src/labels/tool_rules.rs, following the pattern of the existing create_pull_request arm:
// === Copilot coding-agent PR creation (remote-only tool) ===
"create_pull_request_with_copilot" => {
// Creates a PR via the Copilot coding agent; response is repo-scoped PR data.
// S = S(repo); I = writer (agent-authored content)
secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
integrity = writer_integrity(repo_id, ctx);
}
This should be placed near the existing create_pull_request arm (around line 571 in tool_rules.rs), for example by extending the existing Issue/PR write operations match arm:
// === Issue/PR write operations (repo-scoped) ===
"create_issue" | "issue_write" | "sub_issue_write" | "add_issue_comment"
| "create_pull_request" | "create_pull_request_with_copilot" // <-- add here
| "update_pull_request" | "merge_pull_request"
| "pull_request_review_write" | "add_comment_to_pending_review"
| "add_reply_to_pull_request_comment" => {
secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
integrity = writer_integrity(repo_id, ctx);
}
No Classification Gaps Found
All 83 upstream tools that perform write or mutating operations are correctly classified in WRITE_OPERATIONS, READ_WRITE_OPERATIONS, or covered by a prefix pattern (create_*, delete_*, update_*, merge_*, lock_*, unlock_*).
No CLI-Only Gaps Found
All major GitHub CLI write operations are pre-emptively covered in WRITE_OPERATIONS (e.g., archive_repository, transfer_issue, pin_issue, enable_workflow, set_secret, cancel_workflow_run, etc.) or fall under existing delete_* / create_* / update_* patterns.
No Stale Guard Entries Found
All entries in WRITE_OPERATIONS and READ_WRITE_OPERATIONS correspond either to current upstream MCP tools or are clearly marked as pre-emptive entries for anticipated future tools.
References
Generated by GitHub Guard Coverage Checker (MCP + CLI) · ● 1.7M · ◷
Summary
The GitHub guard does not fully cover 1 operation from the github-mcp-server. The missing tool has no explicit DIFC labeling rule, meaning its response will not receive proper repo-scoped secrecy and integrity labels.
create_*,delete_*,update_*,merge_*,lock_*,unlock_*)MCP Tool DIFC Labeling Gaps (tool_rules.rs)
This MCP tool exists in the upstream server but has no explicit match arm in
apply_tool_labelsinguards/github-guard/rust-guard/src/labels/tool_rules.rs. It falls through to the_ => { // Default: inherit provided labels }catch-all, which means the response will not have proper repo-scoped secrecy tags or writer-level integrity labels applied.create_pull_request_with_copilotcreate_*prefix pattern intools.rs, but has no DIFC labeling rule.Context: The tool is available only in the Remote GitHub MCP Server (not the local server). Its response is structurally identical to a
create_pull_requestresponse (a pull request object with owner/repo context), so it should receive the same DIFC labels.Suggested fix for tool_rules.rs
Add a match arm to the
apply_tool_labelsfunction inguards/github-guard/rust-guard/src/labels/tool_rules.rs, following the pattern of the existingcreate_pull_requestarm:This should be placed near the existing
create_pull_requestarm (around line 571 intool_rules.rs), for example by extending the existing Issue/PR write operations match arm:No Classification Gaps Found
All 83 upstream tools that perform write or mutating operations are correctly classified in
WRITE_OPERATIONS,READ_WRITE_OPERATIONS, or covered by a prefix pattern (create_*,delete_*,update_*,merge_*,lock_*,unlock_*).No CLI-Only Gaps Found
All major GitHub CLI write operations are pre-emptively covered in
WRITE_OPERATIONS(e.g.,archive_repository,transfer_issue,pin_issue,enable_workflow,set_secret,cancel_workflow_run, etc.) or fall under existingdelete_*/create_*/update_*patterns.No Stale Guard Entries Found
All entries in
WRITE_OPERATIONSandREAD_WRITE_OPERATIONScorrespond either to current upstream MCP tools or are clearly marked as pre-emptive entries for anticipated future tools.References