How to Block Force Push by AI Agents on a Source-Control MCP Server

Map tool calls to destructive operations by effect, not by name

Tool names differ between source-control MCP servers and change between versions, so a policy keyed only on names will drift. Start by inventorying every tool each connected server exposes, then classify each one by the Git or platform operation it can perform. Three effects matter here.

A force push moves a branch pointer to a commit that is not a descendant of the current one, discarding history on the remote. It can come from a dedicated push tool with a force option, from a ref-update API call that permits non-fast-forward updates, or from a generic shell or command tool running a push with a force flag or a refspec prefixed with a plus sign. Branch deletion removes a ref, through a delete-ref API call or a push with a delete flag or an empty source refspec. Repository deletion is a platform API operation on the repository itself, and it usually requires elevated permissions on the calling credential.

The generic command tool deserves particular attention. If an agent can submit arbitrary commands or natural-language instructions that a server translates into Git operations, the tool name reveals nothing about the effect. Inspect the arguments instead.

• Force push: Inspect for force flags, force-with-lease, plus-prefixed refspecs, or a force parameter on ref updates. Key on the target branch.
• Branch deletion: Inspect for delete flags, empty source refspecs, and delete-ref or delete-branch calls. Key on branch name and repository.
• Repository deletion: Inspect for any delete call on the repository resource. Key on repository and calling identity.
• Generic command tools: Parse the full command or instruction. Treat unparseable input as untrusted.

What native controls cover, and where gaps remain

Branch protection rules and rulesets are the first layer. When configured for a branch, they can reject non-fast-forward updates and deletion of that branch, and they apply regardless of whether the caller is a person or an agent. Their limits are structural. They protect only the branches they match, so feature and release branches outside the pattern stay exposed. They generally do not address repository deletion. Depending on configuration, administrator roles or bypass permissions may exempt a caller from the rules entirely.

Credential scoping is the second layer, and it is where most agent exposure originates. Agents often run with a personal access token or a service account holding more privilege than any single task needs. If that identity can administer a repository, the platform will treat a deletion request from the agent as legitimate. Use narrowly scoped, short-lived credentials per agent and per task, and avoid reusing a developer's personal token. This follows the identity and authorization direction in NIST's concept paper on software and AI agent identity, which includes OAuth 2.0-based authorization of AI systems.

The third layer is MCP server configuration. Servers differ in which tools they expose and in how they handle credentials, so do not assume one server's protections match another's. Disable tools the agent does not need. Any metadata a server declares about a tool describes intent and is not enforcement, so it should not be your only safeguard.

Build the layered control set

Apply the layers in order, and treat each as a safeguard that assumes the one before it may be misconfigured.

• 1. Protect refs on the platform: Apply rules or rulesets that block non-fast-forward updates and deletion on default, release, and any long-lived branches. Review who holds bypass permissions and remove agent identities from them.
• 2. Issue least-privilege credentials: Give each agent its own identity with only the repository and permission scope its tasks need. Exclude repository administration and deletion rights.
• 3. Trim the MCP tool set: Expose only the tools required. Remove or isolate generic command tools and anything that can delete refs or repositories.
• 4. Enforce policy on tool calls: Place a policy decision on the path between agent and MCP server. Block force pushes and repository deletion outright, and escalate branch deletion for human approval.
• 5. Separate execution environments: Run agents apart from systems holding privileged credentials, consistent with NIST SP 800-218A guidance on separating execution environments through isolation, segmentation, or access via APIs.

Enforce policy on the tool call itself

Native controls fail when the credential is too powerful or the branch is not covered. A runtime check on the tool call does not depend on either. NIST SP 800-228 (update 1) describes the general pattern for APIs: a gateway acts as the policy enforcement point and defers to an authorization system that makes the decision. It also recommends resource-level authorization on all requests using endpoint-level annotations that define the permissions required. The same separation applies to MCP tool calls, with the tool taking the place of the endpoint.

For these three operations, the policy needs four inputs: the tool name, the arguments including any force flag, refspec, or delete parameter, the target branch or repository, and the calling identity. With those, rules can be specific. Block any force push to protected or default branches. Block repository deletion for all agent identities. Escalate branch deletion outside an allowed naming pattern to a human approver. Deny by default any tool the policy does not recognize, and fail closed if arguments cannot be parsed.

Escalation has precedent in NIST SP 800-172r3, which calls for dual authorization of organization-defined privileged actions. It was not written for agents, but it is a useful model: the approver should be a different person from whoever configured or invoked the agent, and the approval should be tied to the specific call. NIST SP 800-228 (update 1) also describes blocking by end-user credential, which in this setting means you can cut off one agent identity quickly during an incident without disabling the whole server.

Trussed is one option for this layer. It enforces policy in the execution path on tool calls to MCP servers and coding assistants, with allow, block, and escalate for human approval outcomes, and generates audit-ready evidence from that enforcement. The design requirements above apply whichever mechanism you choose.