Block an agent from deleting GitHub branches

An agent that can open and manage pull requests is genuinely useful. The same agent with the power to merge, force-overwrite a branch, or rewrite files directly is one bad prompt away from losing history you can't get back. The GitHub MCP server's tool set has no single delete_branch call, so the practical protection is denying the tools that remove or overwrite branch content: merge_pull_request (which folds a branch into another, and on repos with "automatically delete head branches" enabled, removes it in the process), push_files (a multi-file commit written straight to a branch, bypassing review), create_or_update_file (a single-file version of the same), and delete_file (removes a file from a branch in a single commit). This walkthrough denies those four and leaves the core pull-request workflow open.

What you'll need

• The GitHub resource added to your gateway (Add GitHub)
• An agent connected to open the pull requests (Connect an agent)
• Admin access to Access Policies
• If your organization still has the default Allow all rule, disable or delete it first — otherwise the allow rule below is redundant, since anything it doesn't match falls through to Allow all and succeeds anyway. (The deny rule still bites either way: it sits above Allow all and is matched first.)

Removing Allow all flips the whole org to deny-by-default, not just GitHub deletes: from then on every tool matching no rule is denied, reads included. This agent keeps only what the allow rule below grants it, so get_file_contents, list_issues, search_code and every other GitHub read stop working unless you add them — get_*, list_*, and search_* alongside the patterns in step 5 cover the common ones. Anything else in the org that was quietly riding on the fall-through loses access too, so add the rules those workloads need before you remove it.

Steps

Create the allow rule first, since rule order matters: new rules land at the top of the table, so creating the deny rule second puts it above the allow rule, where the first matching rule wins.

1. Navigate to Access Policies and click Add Rule.
2. Name it "Allow PR workflow."
3. Set the effect pill to Allow.
4. Set the MCP scope pill to GitHub.
5. Add the tool pattern *pull_request* — it matches every tool with pull_request in its name: create_pull_request, create_pull_request_with_copilot, update_pull_request, update_pull_request_branch, list_pull_requests, search_pull_requests, pull_request_read, pull_request_review_write, and add_reply_to_pull_request_comment. It also matches merge_pull_request, but that's fine: the deny rule you create next lands above this one and catches every merge_pull_request call first, so this rule never sees it. None of the other nine touches branch content directly — update_pull_request_branch only merges the base branch's latest commits forward (the same effect as clicking GitHub's "Update branch" button) and fails on conflicts instead of overwriting anything, so it's safe to leave allowed here.
6. Add create_branch and list_branches so the agent can cut a working branch and see what already exists. Add add_comment_to_pending_review too: the pattern in step 5 misses it, and it's the middle step of the standard review flow — pull_request_review_write opens a pending review, add_comment_to_pending_review adds the inline comments, and submitting finishes it. Without it the flow breaks halfway. If your agent uses Copilot reviews, add request_copilot_review and get_copilot_job_status (the follow-up to the already-matched create_pull_request_with_copilot) on the same grounds.
7. Set the status to Active and click Create. It lands at the top of the table, at position 1 — a disabled Allow all rule may still appear below it, since disabling only removes a rule from evaluation, not from the table.
8. Click Add Rule again to create the deny rule: name it "Block destructive GitHub writes," effect Deny, MCP scope GitHub.
9. Add these tool patterns: merge_pull_request, push_files, create_or_update_file, delete_file.
10. Set the status to Active and click Create. New rules land at the top of the table, so this deny rule takes position 1, above the allow rule — exactly the order you need.

Verify it works

1. Have the agent call create_pull_request. It should succeed.
2. Have it call merge_pull_request. It should fail.
3. Have it call push_files, create_or_update_file, or delete_file. All three should fail too.
4. Open Agent Trail (Audit log) and confirm the pattern: the PR creation shows a successful gateway.tool.executed event, and each denied call shows gateway.tool.error with error_type: blocked_by_policy, naming "Block destructive GitHub writes."

Next steps

• Credential modes — compare SecureAuth's app against bringing your own GitHub OAuth app before you install.
• Tags — label every production repository's resource and scope this deny rule to a Resource tag instead of one server.
• Give Claude read-only access to Jira — the same deny-by-default shape on a different resource.