Summary
The GitHub guard does not fully cover 1 operation from the github-mcp-server. The missing tool has correct write-classification (covered by the create_* prefix pattern in is_create_operation) but lacks an explicit DIFC labeling rule in tool_rules.rs, meaning its response data inherits caller-provided baseline labels rather than having the correct repo-scoped secrecy and writer-level integrity explicitly applied.
- MCP tools scanned: 83 (from github/github-mcp-server, including 4 remote-only)
- CLI write commands scanned: ~40 (from cli/cli — all covered by pre-emptive entries or patterns)
- Guard-covered write tools (tools.rs): 47 (
WRITE_OPERATIONS + READ_WRITE_OPERATIONS)
- Tools with explicit DIFC rules (tool_rules.rs): 67 match arms covering all 83 tools except 1
- New gaps found this run: 1
MCP Tool DIFC Labeling Gaps (tool_rules.rs)
The tool below is documented in the upstream github-mcp-server README (available on the remote/hosted Copilot MCP server at https://api.githubcopilot.com/mcp/x/copilot) and is correctly classified as a write operation via the create_* prefix pattern in is_create_operation. However, it has no explicit match arm in apply_tool_labels in guards/github-guard/rust-guard/src/labels/tool_rules.rs. It therefore falls through to the _ default arm, which only inherits caller-provided baseline labels — it does not explicitly apply repo-scoped secrecy (apply_repo_visibility_secrecy) or writer-level integrity (writer_integrity).
| Tool Name |
Data Scope |
Suggested Labels |
Risk |
create_pull_request_with_copilot |
repo-scoped (creates a PR; response contains PR metadata) |
secrecy: S(repo) via apply_repo_visibility_secrecy, integrity: writer_integrity(repo_id) |
Medium — remote-hosted only, but PR response data may be incorrectly labeled if caller-baseline is empty |
Suggested fix for tool_rules.rs
Add create_pull_request_with_copilot to the existing issue/PR write operations arm in apply_tool_labels:
// === 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" => {
// Write operations that return the created/modified resource.
// S = S(repo) — response contains repo-scoped content
// I = writer (agent-authored content)
secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
integrity = writer_integrity(repo_id, repo, ctx);
}
This mirrors the treatment of create_pull_request since both tools create a PR and return equivalent repo-scoped PR metadata.
MCP Tool Classification Gaps (tools.rs)
None. All 83 upstream MCP tools with write/mutating operations are correctly classified — either via explicit entries in WRITE_OPERATIONS / READ_WRITE_OPERATIONS or via prefix-pattern functions (create_*, delete_*, merge_*, update_*, lock_*, unlock_*).
GitHub CLI-Only Gaps
None. All CLI write commands (~40 across pr, issue, repo, gist, workflow, label, project, secret, variable, run) are either covered by existing MCP tools in the guard lists or by the pre-emptive entries already added to WRITE_OPERATIONS (pin_issue, unpin_issue, transfer_issue, enable_workflow, disable_workflow, set_secret, set_variable, upload_release_asset, sync_fork, cancel_workflow_run, force_cancel_workflow_run, rerun_workflow_run, rerun_failed_jobs, rerun_workflow_job).
Stale Guard Entries
None requiring action. create_issue appears in WRITE_OPERATIONS and tool_rules.rs despite being a deprecated alias of issue_write in the upstream server — this conservative retention is correct (the alias is still served) and should be kept until the upstream server removes it entirely.
References
Generated by GitHub Guard Coverage Checker (MCP + CLI) · ● 2.7M · ◷
Summary
The GitHub guard does not fully cover 1 operation from the github-mcp-server. The missing tool has correct write-classification (covered by the
create_*prefix pattern inis_create_operation) but lacks an explicit DIFC labeling rule intool_rules.rs, meaning its response data inherits caller-provided baseline labels rather than having the correct repo-scoped secrecy and writer-level integrity explicitly applied.WRITE_OPERATIONS+READ_WRITE_OPERATIONS)MCP Tool DIFC Labeling Gaps (tool_rules.rs)
The tool below is documented in the upstream github-mcp-server README (available on the remote/hosted Copilot MCP server at
https://api.githubcopilot.com/mcp/x/copilot) and is correctly classified as a write operation via thecreate_*prefix pattern inis_create_operation. However, it has no explicit match arm inapply_tool_labelsinguards/github-guard/rust-guard/src/labels/tool_rules.rs. It therefore falls through to the_default arm, which only inherits caller-provided baseline labels — it does not explicitly apply repo-scoped secrecy (apply_repo_visibility_secrecy) or writer-level integrity (writer_integrity).create_pull_request_with_copilotS(repo)viaapply_repo_visibility_secrecy, integrity:writer_integrity(repo_id)Suggested fix for tool_rules.rs
Add
create_pull_request_with_copilotto the existing issue/PR write operations arm inapply_tool_labels:This mirrors the treatment of
create_pull_requestsince both tools create a PR and return equivalent repo-scoped PR metadata.MCP Tool Classification Gaps (tools.rs)
None. All 83 upstream MCP tools with write/mutating operations are correctly classified — either via explicit entries in
WRITE_OPERATIONS/READ_WRITE_OPERATIONSor via prefix-pattern functions (create_*,delete_*,merge_*,update_*,lock_*,unlock_*).GitHub CLI-Only Gaps
None. All CLI write commands (~40 across
pr,issue,repo,gist,workflow,label,project,secret,variable,run) are either covered by existing MCP tools in the guard lists or by the pre-emptive entries already added toWRITE_OPERATIONS(pin_issue,unpin_issue,transfer_issue,enable_workflow,disable_workflow,set_secret,set_variable,upload_release_asset,sync_fork,cancel_workflow_run,force_cancel_workflow_run,rerun_workflow_run,rerun_failed_jobs,rerun_workflow_job).Stale Guard Entries
None requiring action.
create_issueappears inWRITE_OPERATIONSandtool_rules.rsdespite being a deprecated alias ofissue_writein the upstream server — this conservative retention is correct (the alias is still served) and should be kept until the upstream server removes it entirely.References