Capping file size and bulk writes from the Filesystem MCP server using runtime policy enforcement

What uncapped writes look like in practice

The Filesystem MCP server gives an AI agent or coding assistant the ability to read, write, create, move and edit files on the host through tool calls. The write-capable operations are the ones that matter for this guide: anything that writes new content, edits existing content, creates files or directories, or moves files from one path to another. Read operations carry their own risks, but they cannot fill a disk or overwrite a directory.

Without limits, a single session can fail in four recurring ways. It can write one oversized file and exhaust disk. It can issue many writes in rapid succession, which turns a runaway loop into thousands of file changes in minutes. It can overwrite or corrupt a directory through repeated edits and moves. Or it can make a bulk change nobody intended, such as rewriting every file in a project because a prompt was ambiguous.

None of these requires a malicious agent. They follow from a model that retries, loops or misreads an instruction, combined with a tool that does what it is asked. That is why the limits need to hold regardless of agent behavior, and why they cannot depend on the agent choosing to stay within them.

Where native server configuration stops

Allowed directories are the main native boundary. They answer the question of where the server may read and write. They do not answer how much a single call may write, how many writes a session may make, or how quickly calls may arrive. A write of ten bytes and a write of ten gigabytes to the same permitted path look identical from the point of view of location scoping.

Treat directory scoping as necessary and insufficient. It reduces the blast radius of a mistake by confining it to a known set of paths, which is valuable, but it leaves volume and velocity uncontrolled inside those paths. The remaining caps need to come from layers you operate: the storage and container layer beneath the server, and policy at the tool-call layer above it.

What each layer can and cannot constrain

Each layer answers a different question. The table shows why no single layer is enough.

• Allowed directories: Constrain where writes can land. Do not constrain size, count or rate within those paths.
• Read-only root filesystem: Keeps writes out of the container image filesystem. Does not limit what is written to the permitted volume.
• Dedicated writable volume: Bounds the location of persistent writes so a runaway write is confined. A size limit on the volume acts only as a backstop.
• Disk quotas and cgroup limits: Enforce hard ceilings on space or resources. They are blind to which tool call caused the breach and return a generic failure the agent may retry.
• Mandatory access control: Keeps process and file activity within defined boundaries. Governs access, not payload size or call rate.
• Tool-call policy in the execution path: Evaluates each write against thresholds before it runs, with the option to block, rate limit or escalate.

Designing the layers from the outside in

Start at the host and container boundary. NIST guidance on application containers recommends running containers with a read-only root filesystem, with the minimal set of file system permissions required, and rarely mounting local file systems from the host. Persistent changes belong in storage volumes allocated for that purpose, and containers should not be able to mount sensitive host directories. Applied here, the Filesystem MCP server runs in a container whose only writable location is a dedicated volume, and the allowed directories point inside that volume.

Next, add access control beneath the application. Mandatory access control can keep process and file activity within defined boundaries even if the application layer is misconfigured. Filesystem isolation works best as a combination, because mount namespaces, chroot, pivot_root and user namespaces each have limitations on their own.

Then add quotas on the writable volume as a hard backstop. Their limitation in agent workflows is behavioral. When a quota is reached, the write fails, and an agent in a loop may simply retry or try another path. The quota protects the disk, but it does not stop the loop, does not tell you which call was responsible, and gives no point at which a person can intervene. That is the job of the tool-call layer.

Policy at the tool-call layer: attributes and decisions

A runtime policy sits in the execution path between the agent and the server. It sees each write request before it reaches the filesystem and decides what happens next. Because it evaluates the call itself, it can apply limits that storage layers cannot express. Define thresholds per directory, per tool and per role rather than as one global number.

Two decisions deserve care. First, payload size alone is not enough. An agent that appends or edits in small increments can grow a file far beyond a sensible size without any single call looking large, so pair the per-call limit with a cumulative bytes budget per session. Second, move operations carry no meaningful payload, so they need controls on target path and count rather than size.

Use graduated responses. Allow calls within thresholds. Rate limit bursts so a loop slows down instead of failing hard. Escalate for human approval when a call crosses a soft threshold, such as a write into a sensitive path or a bulk change touching many files. Block outright when a call crosses a hard threshold, such as an oversized payload.

• Payload size per call: Reject or escalate writes and edits whose content exceeds the limit for that path.
• Target path: Apply stricter thresholds to sensitive or high-impact directories, and to move destinations.
• Write count per session: Cap cumulative writes, creates, edits and moves so bulk changes need approval.
• Cumulative bytes per session: Catch growth through many small writes that individually pass the size check.
• Call rate: Apply MCP tool call rate limiting per session to slow loops before they reach hard caps.
• Caller identity: Tie thresholds to the agent, user or role making the call.

Evidence that the limits were enforced

A cap that cannot be shown to have worked is hard to defend to an auditor. NIST storage guidance favors defining policy for file-level access patterns and detecting and notifying on violations, and those notifications are useful enforcement evidence. The same principle applies at the tool-call layer: each decision should leave a durable record, produced at the moment of enforcement rather than reconstructed later.

A practical record for each write call includes the tool invoked, the target path, the payload size, the session write count and rate at that moment, the policy and threshold that applied, the outcome (allowed, blocked, rate limited or escalated), a timestamp, and for escalations the approver and their decision. This field list is a design recommendation rather than a standard, so adjust it to your audit requirements.

Also keep evidence of the layers beneath the tool call. Container runtime configuration compliance should be automated, so retain repeatable proof that the read-only root, volume mounts and quotas were in place when the writes occurred.

Enforcing this with Trussed

Trussed is one way to apply the tool-call layer. It enforces policy in the execution path across agents, tools, MCP servers and coding assistants, with decisions to allow, block, rate limit or escalate for human approval on individual tool calls. Policy is enforced at runtime, not reviewed after the fact, and enforcement produces audit-ready evidence of each decision. It can be deployed self-managed in the customer cloud, with configurable retention and data residency.

The scope is the individual interaction and tool call. Trussed does not replace the container and storage controls described above, which remain the backstop beneath it. The layers work together: quotas protect the disk, scoping protects the paths, and policy in the path decides whether each write should happen at all.