Rolling Out Filesystem and Browser MCP Servers to Developer Laptops Safely

Two servers, two risk surfaces

A filesystem MCP server gives an AI coding assistant the developer's own reach over local files. Without a sandbox, that includes source code, local configuration, SSH keys and cloud tokens. OWASP guidance describes an agent with auto-accept and full developer permissions as having the same blast radius as a compromised developer workstation.

A browser MCP server adds a different exposure. It can drive web sessions, including authenticated ones, and it pulls untrusted web content into the model's context. Content an agent reads can carry hidden instructions, a pattern known as indirect prompt injection. Issue bodies and pull request comments are documented examples, and the same mechanism applies to any page or file the agent ingests.

Both server types share tool-description risks: poisoned descriptions, tool names that shadow legitimate ones, and definitions that change after approval (a rug-pull). The two surfaces also interact. Web content can steer a filesystem call, so each server should be treated as an independent untrusted security domain, and data flowing between servers, such as a credential from one appearing in a call to another, should be watched.

Scope each server before it ships

Scoping starts with the process, not the protocol. Run local servers in a sandbox with minimal privileges and limited access to host resources. Binding a local HTTP-transport server to localhost is sensible, but avoiding a listening endpoint does not restrict what the server process can reach on the file system, network or credential store.

Give each server its own scoped credentials and never share tokens across servers. Prefer ephemeral, task-scoped credentials over long-lived developer credentials, and keep SSH keys and cloud tokens out of the agent's reach. Block agents from modifying their own rules files without explicit developer approval.

Configuration expresses intent, but the arguments in each call are produced by a model influenced by untrusted context. Treat every tool argument as untrusted input. That is why scope should be checked again at the moment of each call, as described below.

• Filesystem server: Limit to approved project directories. Separate read from write. Exclude credential and key locations. Treat file contents as untrusted.
• Browser server: Limit to approved domains. Use a profile separate from the developer's authenticated sessions. Treat page content as untrusted.
• Both servers: Disable auto-approval and automatic discovery. Require re-approval when tool definitions change. Keep credentials per server.

Apply runtime policy to individual tool calls

Allowlisting decides which servers exist. Runtime policy decides what a given call may do. Each call can be evaluated against the server, the tool, the arguments and the context, and resolved to one of a small set of outcomes. A path outside the approved directories, or a navigation to an unapproved domain, should not depend on the model behaving well.

Keep the outcome set small enough to operate and explain to developers. Start permissive on low-risk reads in the pilot, record what the policy would have done, and tighten as you learn. Reserve human approval for high-impact actions so approvers are not trained to click through.

• Allow: Calls within approved directories or domains and approved operations proceed.
• Redact: Sensitive values in arguments or results, such as secrets in file contents, are removed before they reach the model or another server.
• Block: Calls outside scope, such as writes to credential paths or navigation to unapproved domains, are refused.
• Rate limit: Bulk reads or repeated navigation that could indicate exfiltration are throttled.
• Escalate for approval: High-impact actions, such as modifying security configuration, wait for a named human approver.

Decide what evidence to retain

Limited telemetry is a named MCP risk because it impedes investigation and incident response. Decide before the pilot what each tool call leaves behind. A practical record includes the server identity, the tool invoked, the arguments, the policy decision and its reason, and the approver where a human was involved. Add a timestamp and the developer or endpoint so records can be tied back to a laptop.

Set retention and access rules at the same time. Arguments may contain sensitive data, so decide whether to store them in full, redacted or hashed, and where the records reside. Include assistant memory and connector permissions in incident response plans, and make sure the person who owns the approved-server inventory can also see changes to tool definitions.

Trussed enforces policy in the execution path of MCP tool calls, including those made by coding assistants, with allow, redact, block, rate limit and escalate-for-human-approval outcomes. Because enforcement happens at runtime, not reviewed after the fact, the decision and its audit-ready evidence are produced at the point of the call. Trussed also records the origin, licence and security context of code, which helps when assistants write to local files. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Scope is individual interactions and tool calls.