Preventing Coding Agents From Editing CI/CD Pipelines and Git Hooks Through the Filesystem MCP Server

Why pipeline and hook paths need separate treatment

A Filesystem MCP server gives an agent file tools over whatever paths the server exposes. If the exposed root is a repository checkout, that usually includes the files that decide how code is built, tested and deployed, along with the .git directory. Two groups of paths matter most.

The first is pipeline definitions: workflow YAML under .github/workflows, .gitlab-ci.yml, a Jenkinsfile, azure-pipelines.yml and any build configuration those files call. A changed pipeline can alter which tests run, which credentials a job can reach and what gets deployed.

The second is Git hooks in .git/hooks. Hooks are executable scripts that run on local Git operations. Because the .git directory is not part of the tracked tree, a change there does not appear in a diff or pull request. An edit to either group can change execution behavior or run arbitrary commands without passing through normal code review.

That is why these paths call for explicit controls instead of reliance on the general guidance to give an agent only what it needs. Least privilege and zero trust are the direction of current guidance for AI agents, and NIST material on agentic security advises against giving agents broad privileges or open-ended tools. A file tool rooted at a whole repository is a broad privilege.

Failure modes to test for before you rely on path scoping

Allowed-directory settings are the first control most teams reach for, and they are necessary. They are not sufficient on their own, because the paths an agent can reach depend on how the scoping is applied. Test each of the following against your own deployment instead of assuming it is handled.

Broad allowed directories. Pointing the server at a repository root or a home directory exposes pipeline files and .git together. Scope to the source subdirectories the task needs.

Write access to .git. If the exposed directory contains .git, hooks and Git configuration are writable unless something else prevents it.

Symlinks. A link inside an allowed directory can point to a location outside it, or to a protected file inside it. Check whether a read or write through a link resolves to the real target before the scope check.

Path traversal. Relative segments such as ../ and differing path normalization can move a request out of the intended directory. Try them directly.

Tool breadth. A server that exposes write, move and edit operations offers more ways to change a file than one limited to reads. Enable only the tools the workflow needs.

A passing test today is a statement about one configuration. Re-run it when the server version, mount layout or repository structure changes.

Layers one and two: configuration and environment isolation

Start with controls that do not depend on what the agent decides to do.

Configuration. Enumerate the paths the agent legitimately needs, then restrict the server to those directories and the tools it needs. Where the task is analysis or review, run the server read-only. Do not treat instructions in a prompt as a control. NIST agentic security guidance advises against trusting prompt instructions, metadata or artefacts from users or other agents.

Environment isolation. Run the server and the agent in an environment separated from the systems it should not change. NIST SP 800-218A says development environments should be strongly protected and separated to the extent feasible through isolation, segmentation, containment or access via APIs. In practice, run the server in a container, mount the working source tree as needed, and mount pipeline definitions and .git read-only or leave them out of the container entirely. NIST SP 800-190 notes that read-only filesystems make containers more resilient to compromise because tampering is confined to specific locations. It also recommends tooling that monitors which directories containers mount and blocks deployments that violate mount policy.

OS permissions add a further boundary: run the server under an account that has no write permission on protected paths, so a configuration error does not become a write.

• Scope the server to source directories, not the repository root.
• Enable only the file tools the task requires.
• Mount pipeline files and .git read-only, or exclude them.
• Run the server under an account without write permission on protected paths.
• Block container deployments that violate mount policy.

Layer three: repository-side protections and their limits

Repository controls decide what can merge, even if a file was changed on the agent's working copy. Branch protection requires review and passing checks before changes reach protected branches. CODEOWNERS can require approval from a named team for changes to pipeline files, so a workflow edit cannot merge on a general code review alone. Many platforms also offer settings that restrict who can modify or approve workflow changes. Use them for the same paths.

For hooks, manage them from a reviewed location. Git's core.hooksPath setting can point to a versioned directory, so hook content goes through review like other code. Be precise about what this covers: the setting itself lives in local Git configuration, which sits inside .git, so a writable .git can still undermine it.

The broader gap is timing. Repository controls act when a change is proposed or merged. A hook modified locally can run on the next Git operation, before any pull request exists. A modified pipeline file can be caught at review, but only if the reviewer notices it among other changes. These controls reduce risk after the write. They do not stop the write.

Layer four: policy enforcement on each tool call

The first three layers are static. Each depends on a configuration that stays correct, and none can tell a legitimate edit to a source file from an attempt to write to a protected path as it happens. A runtime layer in the execution path can make that decision per tool call: allow the write, block it, or escalate it for human approval.

Trussed enforces policy in the execution path across agents, tools and MCP servers, at the level of individual tool calls. For this use case, a policy can treat a write to a pipeline definition or a hook path differently from a write to application code: allow the routine, block the prohibited, and send the ambiguous to a person. Enforcement happens at runtime, not reviewed after the fact, and it applies even when an agent has been manipulated away from its instructions.

Each decision also produces audit-ready evidence: which call was attempted, which rule applied and what the outcome was. That answers the question platform and security teams are asked after an incident or during an audit, which is whether the restriction was actually enforced. NIST's DevSecOps guidance similarly describes automatically generating security and compliance artifacts across the pipeline, and evidence of enforcement belongs in that set.

Runtime enforcement is an addition to the earlier layers, not a replacement. Mounts and permissions still hold if the policy layer is misconfigured, and the policy layer still holds if a path was left exposed.