How to Prevent AI Agents from Changing Branch Protection Rules or Repository Settings via MCP

How settings changes are reached through MCP tool calls

An MCP server turns tool calls into requests against the source control platform, made with whatever credential the server holds. If the server exposes a tool that edits branch protection, or a generic tool that can reach administrative endpoints, and the credential carries administrative rights, the platform sees a valid request. Nothing about the call marks it as different from reading a file. This is the failure OWASP Cornucopia AAI9 describes: no authorization boundary on configuration actions, so the system does not distinguish reads from privileged writes when the request comes from an agent.

The agent chooses which tool to call based on its context, and that context can be influenced. Issue bodies, pull request descriptions and comments from untrusted contributors can steer agent behavior. Prompt injection, tool poisoning and tool interference are named risks of connecting models to third-party MCP servers. A mistaken call and an injected call look the same at the tool boundary.

The actions to protect are those that weaken the controls around code: editing branch protection rules, changing required reviews or status checks, modifying webhooks or deploy keys, changing repository visibility, and altering other repository settings. OWASP's position is that agents should operate under the same change-management controls as human administrators, with additional automated guardrails. Agents that only monitor or report should have no write access to configuration or permission systems.

Layers 1 and 2: scope the credential, then shrink the tool surface

Start with identity. Issue each MCP server its own credential and never share tokens across servers. Grant the minimum permissions the server needs for its function. NIST's agent identity tenets add zero standing privilege and ephemeral access acquired when a task starts, in place of long-lived bearer tokens or static reusable secrets. Use your platform's native controls for token scope, app permissions and organization-level restrictions, and review them on a schedule. OWASP lists scope creep as a risk because temporary permissions tend to expand over time.

Then reduce what the agent can see. Inventory the tools each MCP server exposes and disable or filter any administrative tool the task does not need. Scope tools per function, separating read from write and limiting them to specific resources. Use separate tool sets for different trust levels, avoid wildcard permissions, and do not let agents discover and connect to new MCP servers without approval.

These layers are necessary but incomplete. Scoping has to be repeated consistently across many agents, servers and repositories. A credential that is correct for one task may be too broad for the next. A server may expose a tool you did not inventory. Hence the need for a check at call time.

• Inventory every tool on every connected MCP server, including generic request tools.
• Disable administrative tools for agents whose task is coding, review or reporting.
• Issue one short-lived credential per server and task; never share across servers.
• Separate read tool sets from write tool sets by trust level.
• Require security review before connecting any MCP server from an untrusted source.
• Review scopes on a schedule and expire them automatically.

Layer 4: human approval for exceptions

Some administrative changes are legitimate. Route them through an approval step rather than widening the agent's standing permissions. The approval should be bound to the specific action and arguments: which repository, which rule, which new value. An approval of "change repository settings" in general is too broad to be a control.

Design approvals to resist fatigue. The DSOMM mapping describes a user worn down by approval prompts who enables standing auto-approve, and a prompt-injected agent rewriting its own permission configuration. Keep the escalation set small by blocking what should never happen, so that approvers see few, meaningful requests. Keep the approver separate from the requesting agent and, where practical, from the person who started the task, in line with separation of duties.

Trussed enforces policy in the execution path on tool calls to MCP servers and can allow, block or escalate for human approval. The decision is enforced at runtime, not reviewed after the fact, so a blocked branch protection change does not execute and then get flagged later.

Layer 5: retain evidence of every decision

For each tool call that touches repository settings, record the agent identity, the tool, the parameters, the policy decision and the rule that produced it, the approver where one was involved, and the outcome. Record blocked attempts as well as allowed ones. A blocked attempt is often the most useful signal that an agent was steered by untrusted content, and OWASP advises auditing agent actions after an agent processes such content.

Where the records live matters. NIST warns that if activity logs are accessible or modifiable by the agent, a compromised agent could tamper with them. Store evidence in a system the agent's credentials cannot reach, with retention set to your change-management and audit requirements. Map the fields to the frameworks and controls you are assessed against, such as NIST AI RMF or SOC 2, with your auditors.

Trussed generates audit-ready evidence as a product of enforcement, mapped to frameworks including NIST, and supports self-managed deployment in the customer cloud with configurable retention and data residency.