Your coding agent just merged a pull request to main, deleted three files it thought were unused, and created a new repository called temp-debug-workspace
. You didn't ask it to do any of that. But you gave it access to the GitHub MCP server, and the GitHub MCP server said yes to everything.
The official GitHub MCP server registers 83 tools. Most people set it up for reading code and managing issues. What they don't realise is they've also handed their agent the keys to:
delete_file
merge_pull_request
push_files
create_repository
fork_repository
create_or_update_file
actions_run_trigger
There's no permission model inside MCP. The protocol forwards every tools/call
from agent to server without restriction. If the GitHub token has write access, the agent has write access. And if the agent hallucinates a plan that involves tidying up old files or "fixing" a broken workflow, nothing stands in its way.
This is the same class of problem we covered in what happens when an AI agent goes rogue — except here the blast radius is your entire GitHub organisation.
Intercept sits between your agent and the GitHub MCP server as a proxy. Every tool call passes through a YAML policy before reaching GitHub. The policy is deterministic — no LLM judgment, no prompt-based guardrails, just hard rules evaluated at the transport layer.
Here's the destructive tool policy from our GitHub starter config. File deletion is blocked outright:
version: "1"
description: "Policy for github/github-mcp-server"
default: "allow"
tools:
delete_file:
rules:
- name: "block-delete"
action: deny
on_deny: "File deletion blocked by policy"
When the agent tries to call delete_file
, it receives the on_deny
message instead. The request never reaches GitHub.
For write operations you want to permit but not leave unchecked, rate limits keep things sane:
tools:
create_or_update_file:
rules:
- name: "rate-limit-writes"
rate_limit: "30/hour"
on_deny: "Rate limit: max 30 write operations per hour"
push_files:
rules:
- name: "rate-limit-writes"
rate_limit: "30/hour"
on_deny: "Rate limit: max 30 write operations per hour"
create_repository:
rules:
- name: "rate-limit-repo-creation"
rate_limit: "5/hour"
on_deny: "Rate limit: max 5 repository creations per hour"
add_issue_comment:
rules:
- name: "rate-limit-comments"
rate_limit: "20/hour"
on_deny: "Rate limit: max 20 comments per hour"
actions_run_trigger:
rules:
- name: "rate-limit-workflows"
rate_limit: "10/hour"
on_deny: "Rate limit: max 10 workflow triggers per hour"
Rate limits use stateful counters that reset at the top of each window (hour, minute, or day). If the agent burns through 30 file writes in a loop, it's cut off until the next hour — and it knows why, because the denial message tells it.
Finally, a global backstop catches anything you haven't explicitly configured:
tools:
"*":
rules:
- name: "global-rate-limit"
rate_limit: "120/minute"
on_deny: "Global rate limit: max 120 calls per minute"
This caps the agent at 120 total tool calls per minute across all 83 tools. Even if you forget to add a rule for a specific tool, the wildcard catches runaway loops before they cause real damage.
Install Intercept and point it at the GitHub MCP server:
npm install -g @policylayer/intercept
intercept -c github.yaml -- npx -y @modelcontextprotocol/server-github
Every tool call now passes through the policy. Denied calls return the on_deny
message to the agent. Allowed calls forward to GitHub as normal. The agent doesn't know Intercept is there — it just sees an MCP server that sometimes says no.
You can start with our pre-built GitHub policy and adjust from there. Block what's dangerous, rate limit what's useful, and leave read-only tools open.