How to Block AI Agents from Deleting Releases and Tags Through MCP

Why release and tag mutation is its own class of tool call

A source-control MCP server turns repository operations into tools an agent can call. Most of those operations are recoverable. Releases and tags are different because build, deployment and audit workflows anchor on them. Deleting a tag can break a pipeline that resolves a version by name. Recreating a tag on a different commit can change what downstream systems build or deploy, and the change may look routine.

The cause may be a mistaken inference, a manipulated prompt, or a credential that was simply broader than the task needed. NIST material on agentic AI notes that reduced human oversight widens the area of effect when an agent executes the wrong action or is manipulated through prompt injection. It also advises against giving agents broad privileges or open-ended tools, and against trusting instructions, metadata or artefacts from users or other agents. A tool call is therefore not legitimate just because the agent issued it.

Treat release and tag mutation as a distinct high-consequence class, with its own controls and its own approval rule, rather than as one more write operation.

Step 1: Inventory the tools and the API operations behind them

Start with an inventory of MCP servers, the agents that use them, and the identities and credentials each agent presents. You cannot scope or enforce what you have not enumerated.

For each server, list every tool and trace it to the platform API operation it performs. Classify by effect, not by tool name. The operations that matter are creating a tag or the underlying git reference, deleting or moving a tag, creating a release, editing a release or its attached assets, and deleting a release. Names can mislead. A tool called something generic, such as a raw API call, a git command runner or a reference update, can reach all of these even though no tool is labelled as a release tool.

These open-ended tools deserve the most scrutiny. If a tool accepts an arbitrary endpoint, method or ref name, a name-based allowlist will not describe what it can do. Either remove it from the agent's configuration or evaluate its parameters at runtime, as covered below.

What each control layer can and cannot enforce

Each layer covers part of the risk. The table shows where each one stops, which is why the layers need to work together.

• Credential scoping: Can: withhold the permission to write tags or releases, so the platform rejects the call. Cannot: separate release actions from other writes when scopes are coarse, and cannot express intent, repository pattern or approval.
• Platform tag and release protection: Can: restrict who may create, move or delete matching tags, independent of the client. Cannot: constrain actors who are allowed by the rule, and may not cover release objects as distinct from tags. Verify behavior in a test repository.
• MCP server tool configuration: Can: disable, filter or set tools read-only where the server supports it, shrinking what the agent can attempt. Cannot: inspect parameters of an allowed tool, and has no effect on other servers or direct API use with the same token.
• Runtime tool-call policy: Can: evaluate each call by tool name and parameters, then allow, block or escalate, and record the decision. Cannot: replace the layers below it. A call that bypasses the enforcement path is not evaluated.

Step 2: Apply the first three layers

Scope the credential first. Give each agent its own identity rather than a developer's personal token, and grant only the permissions its tasks need. If the agent reads code and opens pull requests, it has no need to mutate tags or releases. Where the platform allows scopes to be narrowed by repository, narrow them. Assign each credential a named owner so accountability is clear.

Next, configure the platform. Apply tag protection rules or rulesets to the patterns your release process uses, such as version-formatted tags, so creation, movement and deletion are restricted to the release pipeline identity or a small set of maintainers. Check whether release objects are covered by the same rules. If they are not, restrict the permission that governs them.

Then configure the MCP server. Disable the tools that create, update or delete tags and releases for any agent that does not need them. Where the server supports a read-only mode or tool filtering, use it. Keep a separate, narrowly scoped server instance for the one agent that legitimately handles releases, if one exists. Do not assume the agent configuration and the server configuration agree. Test that a blocked tool is absent from the tool list the agent actually receives.

Step 3: Enforce policy on each tool call at runtime

The first three layers are static. They fix what is permitted before the agent runs. Runtime enforcement adds a decision at the moment of the call, using the tool name, the parameters and the identity making the request. Filtering model output alone is an incomplete control, because novel prompts can still produce harmful actions, so the check belongs on the action itself.

A workable rule set is short. Block any delete of a tag or release, with no exceptions for agents. Block any tool call that targets protected tag patterns, including calls through generic API or git tools whose parameters resolve to a ref or release endpoint. Escalate creation of a tag or release for human approval, unless it comes from the designated release identity in an allowed repository. Default to block for unclassified tools on servers that can reach release operations.

The decision should be deterministic and independent of the prompt. Text in an issue, a commit message or a retrieved document must not be able to argue the policy into allowing a call.

Trussed is one option for this layer. It enforces policy in the execution path for agents, tools and MCP servers at the level of individual tool calls, with actions that include allow, block and escalate for human approval. The same approach can be built in-house if the enforcement point sits in the path of every call.

Deciding when to escalate, and what evidence to keep

Escalate when the action is legitimate in some contexts but irreversible or consequential in others. Creating a release tag is the clear case. Show the approver the repository, the tag or release name, the target commit, the requesting agent identity and the credential in use. Present any prompt-derived context as untrusted content, not as a justification. Define in advance who can approve, and what happens if no one responds. The safe default is that the call stays blocked.

For evidence, record for every call that reaches the policy point: timestamp, agent and credential identity, MCP server, tool name, parameters, the decision, the policy version applied, and for escalations the approver and outcome. Blocked calls matter as much as allowed ones, because they show the control worked. Keep the records protected from alteration, and set retention and handling rules in advance.

Treat these records as potentially untrusted content. NIST incident-management material warns that logs containing malicious prompts or adversarial content can become an attack surface if agents or automation later consume them. Do not feed raw records back into agents without safeguards. Trussed generates audit-ready evidence from enforcement, with configurable retention, so the record is produced by the decision itself rather than reconstructed afterward.

Finally, monitor downstream. NIST guidance on CI/CD recommends real-time monitoring and alerting for suspicious activity, and unexpected tag movement or release deletion fits that description.