Block GitHub merges and file writes

Let an agent open GitHub pull requests but never merge them or edit a branch directly, with SecureAuth Agent Authority

You want an agent to open and update GitHub pull requests, but not to merge them or change a branch without a review. Two SecureAuth Agent Authority rules do it: one allows the pull-request workflow, and one denies the tools that merge pull requests or add, change, or delete files on a branch. When you finish, the agent can still open, update, and review pull requests, and it can't merge them or edit a branch directly.

Tools this blocks

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).

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 Agent Access
  • 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

Rule order matters because the first matching rule wins. A new deny rule goes to the top of the table and a new allow rule goes to the bottom, so the deny rule ends up above the allow rule.

  1. Navigate to Agent Access 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 goes to the bottom of the table. If you disabled Allow all instead of deleting it, the new rule sits below it, which is harmless: a disabled rule stays in the table but isn't evaluated.
  8. Click Add Rule again to create the deny rule: name it "Block GitHub merges and file 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. A new deny rule goes to the top of the table, so this rule takes position 1, above the allow rule. That's 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 GitHub merges and file 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.

On this page