[guard-coverage] Guard coverage gap: 2 operations from github-mcp-server not fully covered

[github-actions]

Summary

The GitHub guard does not fully cover 2 operation(s) from the github-mcp-server. Both are newly-observed read tools with repo-scoped data that lack explicit DIFC labeling rules, causing them to fall through to default handling. There are no classification gaps — all 53 write/mutating operations in the upstream tool list are covered by WRITE_OPERATIONS, READ_WRITE_OPERATIONS, or prefix patterns.

• MCP tools scanned: 107 (up from 102 last run — 5 new tools added)
• CLI write commands scanned: 42 (unchanged)
• Guard-covered write tools (tools.rs): 53 explicit + pattern coverage (create_*, delete_*, merge_*, lock_*, unlock_*, update_*)
• Tools with explicit DIFC rules (tool_rules.rs): 43 match arms
• New gaps found this run: 2

---

MCP Tool Classification Gaps (tools.rs)

✅ None. All 53 write/mutating operations in the upstream tool list are accounted for in WRITE_OPERATIONS, READ_WRITE_OPERATIONS, or prefix pattern functions.

---

MCP Tool DIFC Labeling Gaps (tool_rules.rs)

These MCP tools exist in the upstream server but have no explicit match arm in apply_tool_labels in guards/github-guard/rust-guard/src/labels/tool_rules.rs. They fall through to default label handling, which does not apply repo-scoped secrecy tags or appropriate integrity levels:

Tool Name	Data Scope	Suggested Labels	Risk
search_commits	repo-scoped (commit content, messages, diffs across public/private repos)	secrecy: S(repo via search scope), integrity: writer	Medium
list_issues_ff_remote_mcp_issue_fields	repo-scoped (issues + custom fields)	same as list_issues	Medium

Details

search_commits — Searches commit history across GitHub repositories. Can expose commit messages, author details, and code changes in private repos. The existing list_commits and search_code tools both have explicit labeling; search_commits should follow the same pattern.

list_issues_ff_remote_mcp_issue_fields — Feature-flag variant of list_issues that supports filtering by custom issue field values. Returns the same repo-scoped issue data as list_issues (which has an explicit match arm), but this variant bypasses that arm and falls through to defaults.

Suggested fix for tool_rules.rs

// In apply_tool_labels, add these match arms alongside the existing list_issues / search_code arms:

// search_commits — mirrors search_code scoping logic
"search_commits" => {
    // Commit search can expose private commit history
    // S(commits) = inherits from repo secrecy
    // I(commits) = approved - commits reachable from default branch
    let (s_owner, s_repo, s_repo_id) = resolve_search_scope(tool_args, &owner, &repo);
    if !s_repo_id.is_empty() {
        desc = format!("search_commits:{}", s_repo_id);
        secrecy =
            apply_repo_visibility_secrecy(&s_owner, &s_repo, &s_repo_id, secrecy, ctx);
        integrity = writer_integrity(&s_repo_id, ctx);
        baseline_scope = Cow::Owned(s_repo_id);
    } else {
        secrecy =
            apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
        integrity = writer_integrity(repo_id, ctx);
    }
}

// list_issues_ff_remote_mcp_issue_fields — feature-flag variant of list_issues; same labeling
// Extend the existing arm:
"get_issue" | "issue_read" | "list_issues" | "list_issues_ff_remote_mcp_issue_fields" => {
    // (same body as existing list_issues arm)
}

---

GitHub CLI-Only Gaps

✅ None. The guard already contains comprehensive pre-emptive entries for all known CLI write operations (workflow runs, secrets, variables, releases, gist deletion, issue/comment edits, etc.). No new CLI write commands were detected since the last run.

---

Stale Guard Entries (bonus)

create_pull_request_with_copilot is listed in WRITE_OPERATIONS but does not appear in the current upstream toolsnaps. This may be a pre-emptive entry for a tool not yet publicly available, or it may be stale. No action required unless the tool has been permanently removed from the server.

---

References

• github-mcp-server tools
• GitHub CLI commands
• guard tools.rs
• guard tool_rules.rs
• Run: 26350662154

Generated by GitHub Guard Coverage Checker (MCP + CLI) · ● 1.3M · ◷

• expires on Jun 7, 2026, 3:26 AM UTC

[github-actions]

🤖 This is an automated response from Repo Assist.

Confirmed both gaps in tool_rules.rs. The fixes are minimal:

1. search_commits (line ~412) — mirror the existing search_code arm:

"search_code" | "search_commits" => {
    let (s_owner, s_repo, s_repo_id) = resolve_search_scope(tool_args, &owner, &repo);
    if !s_repo_id.is_empty() {
        desc = format!("{tool_name}:{s_repo_id}");
        secrecy = apply_repo_visibility_secrecy(&s_owner, &s_repo, &s_repo_id, secrecy, ctx);
        integrity = writer_integrity(&s_repo_id, ctx);
        baseline_scope = Cow::Owned(s_repo_id);
    } else {
        secrecy = apply_repo_visibility_secrecy(&owner, &repo, repo_id, secrecy, ctx);
        integrity = writer_integrity(repo_id, ctx);
    }
}

2. list_issues_ff_remote_mcp_issue_fields (line ~135) — extend the existing arm:

"get_issue" | "issue_read" | "list_issues" | "list_issues_ff_remote_mcp_issue_fields" => {

No other changes needed — the body logic is identical for the feature-flag variant.

Both changes are low-risk: they promote tools from default label handling to explicit repo-scoped labeling, which is the stricter correct behavior. Happy to create a PR if that would be helpful.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• proxy.golang.org

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "proxy.golang.org"

See Network Configuration for more information.

Generated by Repo Assist · ● 3.2M · ◷

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@851905c06e905bf362a9f6cc54f912e3df747d55