Summary
The GitHub guard does not fully cover 3 operation(s) from the github-mcp-server and/or GitHub CLI. This may leave read operations without proper secrecy/integrity labeling and allow write operations to bypass DIFC classification.
- MCP tools scanned: 109 (↑1 from previous run of 108)
- CLI write commands scanned: 44
- Guard-covered write tools (tools.rs): 90 (58 in
WRITE_OPERATIONS + 32 in READ_WRITE_OPERATIONS)
- New gaps found this run: 3
- Previously known gaps resolved: 2 (
search_commits, list_issues_ff_remote_mcp_issue_fields — both now have explicit labeling rules ✅)
MCP Tool DIFC Labeling Gap (tool_rules.rs)
get_file_blame — new tool added since last run (108 → 109 tools)
get_file_blame is a read-only tool (readOnlyHint: true) added to the upstream MCP server that returns git blame information for a file — showing which commit last modified each line, with associated author and SHA metadata. It accepts owner, repo, path, and optional ref parameters.
It is not in WRITE_OPERATIONS (correct, it is read-only), but it also has no explicit match arm in apply_tool_labels, causing it to fall through to the default handler. This means:
- Repo visibility secrecy is not applied (private repo code leaks without
S(repo) label)
- Sensitive file path escalation is not applied (blame for
.env, credentials, workflow files stays unclassified)
- Ref-based integrity (
merged vs writer) is not applied (unlike its sibling get_file_contents)
| Tool Name |
Data Scope |
Suggested Labels |
Risk |
get_file_blame |
repo-scoped file content + commit metadata |
secrecy: S(repo), integrity: merged (default branch) / writer (feature branch) |
Medium |
Suggested fix for tool_rules.rs
Extend the existing get_file_contents match arm to cover get_file_blame as well, since both tools operate on file path + ref with identical secrecy/integrity semantics:
// === Content Access ===
"get_file_contents" | "get_file_blame" => {
secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
// File secrecy based on path patterns
if let Some(path) = tool_args.get("path").and_then(|v| v.as_str()) {
secrecy = check_file_secrecy(path, secrecy, &owner, &repo, repo_id, ctx);
}
let branch_ref = tool_args.get("ref").and_then(|v| v.as_str()).unwrap_or("");
integrity = if is_default_branch_ref(branch_ref) {
merged_integrity(repo_id, ctx)
} else {
writer_integrity(repo_id, ctx)
};
}
GitHub CLI-Only Gaps
These write operations are reachable via the GitHub CLI (gh discussion create / gh discussion edit) but have no corresponding MCP tool in the upstream server and no pre-emptive guard entry. The guard has no visibility into these operations if an agent invokes them via gh or direct GraphQL API calls.
Note: gh discussion comment is already covered by the existing discussion_comment_write entry in WRITE_OPERATIONS. The gaps below are for creating and editing entire discussions, not comments.
| CLI Command |
API Operation |
GitHub Action |
Guard Entry |
Risk |
gh discussion create |
GraphQL createDiscussion mutation |
Creates a new discussion in a repository |
❌ None |
Medium |
gh discussion edit |
GraphQL updateDiscussion mutation |
Edits title, body, or labels of an existing discussion |
❌ None |
Medium |
Suggested fix for tools.rs
Add pre-emptive entries to WRITE_OPERATIONS (maintaining sorted order):
pub const WRITE_OPERATIONS: &[&str] = &[
// Keep sorted for binary_search correctness.
// ...
"create_discussion", // gh discussion create — creates a discussion in a repository
// ...
"edit_discussion", // gh discussion edit — edits title/body/labels of a discussion
// ...
];
Then add corresponding match arms in tool_rules.rs (under the repo-scoped write operations block):
// Discussion creation/editing (repo-scoped writes)
| "create_discussion"
| "edit_discussion"
References
Generated by GitHub Guard Coverage Checker (MCP + CLI) · 487.7 AIC · ⊞ 36.7K · ◷
Summary
The GitHub guard does not fully cover 3 operation(s) from the github-mcp-server and/or GitHub CLI. This may leave read operations without proper secrecy/integrity labeling and allow write operations to bypass DIFC classification.
WRITE_OPERATIONS+ 32 inREAD_WRITE_OPERATIONS)search_commits,list_issues_ff_remote_mcp_issue_fields— both now have explicit labeling rules ✅)MCP Tool DIFC Labeling Gap (tool_rules.rs)
get_file_blame— new tool added since last run (108 → 109 tools)get_file_blameis a read-only tool (readOnlyHint: true) added to the upstream MCP server that returns git blame information for a file — showing which commit last modified each line, with associated author and SHA metadata. It acceptsowner,repo,path, and optionalrefparameters.It is not in
WRITE_OPERATIONS(correct, it is read-only), but it also has no explicit match arm inapply_tool_labels, causing it to fall through to the default handler. This means:S(repo)label).env, credentials, workflow files stays unclassified)mergedvswriter) is not applied (unlike its siblingget_file_contents)get_file_blameSuggested fix for tool_rules.rs
Extend the existing
get_file_contentsmatch arm to coverget_file_blameas well, since both tools operate on file path + ref with identical secrecy/integrity semantics:GitHub CLI-Only Gaps
These write operations are reachable via the GitHub CLI (
gh discussion create/gh discussion edit) but have no corresponding MCP tool in the upstream server and no pre-emptive guard entry. The guard has no visibility into these operations if an agent invokes them viaghor direct GraphQL API calls.Note:
gh discussion commentis already covered by the existingdiscussion_comment_writeentry inWRITE_OPERATIONS. The gaps below are for creating and editing entire discussions, not comments.gh discussion createcreateDiscussionmutationgh discussion editupdateDiscussionmutationSuggested fix for tools.rs
Add pre-emptive entries to
WRITE_OPERATIONS(maintaining sorted order):Then add corresponding match arms in
tool_rules.rs(under the repo-scoped write operations block):References