Preventing an Agent from Chaining Filesystem MCP Reads into Browser MCP Exfiltration

Why the chain is hard to see one call at a time

An agent with both a Filesystem MCP server and a Browser MCP server can read a sensitive local file in one call and send its contents out in a later one. The outbound step may be a URL parameter, a form submission or text placed on a page. Evaluated alone, each call can look legitimate: a file read inside a working directory, then a page visit.

OWASP lists data exfiltration through legitimate channels as a key MCP risk. Prompt injection is used to encode sensitive data into normal-looking tool calls, such as search queries or email subjects. OWASP also notes that agents connected to file-operation servers may pass file contents, credentials or environment variables as tool arguments without any awareness of data classification. That is the handoff from a read tool to an outbound tool.

The trigger is usually upstream. Untrusted content, a tool response, or a manipulated tool description steers the agent. OWASP advises treating every tool response as untrusted, including responses from approved servers, and treating tool annotations as untrusted unless they come from trusted servers. Agent output is a second channel: Markdown-based exfiltration links and zero-width or bidirectional characters can carry data without any browser call.

Layered preventive controls

Start by removing capability. OWASP's guidance on excessive agency is to offer an agent only the extensions it needs; if a task does not require fetching URL contents, do not offer that tool. An agent that reads local files for one task rarely needs open browsing in the same session. Where both are needed, use separate identities and browsing profiles, and keep sensitive sessions out of reach.

On the Filesystem side, scope reads to named directories or resources, and read-only where writes are not required. Treat access to sensitive paths as a sensitive read that may warrant approval. Do not assume a `.gitignore` entry keeps a file away from an agent; it is not an access control.

On the Browser side, enforce a destination allowlist outside the model. Instructions in a prompt can be overridden by injected content, while a policy check in the call path cannot be argued with. Guard parameters that carry URLs, since tools that fetch LLM-generated URLs can be manipulated into reaching internal services such as cloud metadata endpoints.

For outbound content, inspect arguments for credentials, file contents and other sensitive patterns, then redact or block. Choose patterns and thresholds from your own data classification, since there is no universal set. Treat rate limiting the same way: pick values from normal task behavior, then tighten.

Conditions evaluated on a single call, and the decision each supports

Each of these conditions can be evaluated on one tool call without tracing the whole workflow. The mapping below is a starting design, not a fixed rule set.

• File path inside approved scope, not sensitive: Allow the read.
• File path sensitive or outside scope: Block, or escalate for human approval when the task may legitimately need it.
• Destination on the allowlist: Allow, subject to payload inspection.
• Destination not on the allowlist: Block. Escalate if cross-site transfer of data is a legitimate need.
• Payload contains credential or sensitive-content patterns: Redact if the call is otherwise valid; block if the destination is also unexpected.
• Call frequency exceeds the expected pattern: Rate limit, and trip a circuit breaker on repeated hits.

Runtime enforcement versus after-the-fact review

The distinction matters most for exfiltration. A policy check in the execution path decides before the call reaches the Filesystem or Browser server. A review of records afterward can show what left, but the data has already left. OWASP recommends monitoring cross-server data flows, such as credentials from one server appearing in calls to another, and monitoring is valuable. It complements prevention and does not substitute for it.

Be precise about scope. Per-call enforcement evaluates individual interactions and tool calls. It does not trace an entire agentic workflow or govern a business transaction end to end. An attacker who splits a transfer into calls that each pass policy is a real design concern. The mitigation is to make each call's conditions conservative: reads of sensitive paths escalate regardless of what follows, and outbound payloads are inspected regardless of what came before. Workflow-level correlation, where you need it, is a separate capability.

What evidence each control should produce

OWASP recommends logging structured decision metadata for high-risk actions. For each enforced call, record the tool, the decision and the reason, plus the policy condition that matched. In practice that means:

Path scoping records the requested path, the scope rule applied and the outcome. Destination restrictions record the requested domain and whether it matched the allowlist. Redaction records which pattern category matched and that content was removed, not the content itself. Rate limiting records the counter and the limit reached. Human approval records the request, the reviewer and the result.

Keep the evidence from becoming its own leak. Redact credentials and personal data before captured traffic is stored. Then test the design: OWASP lists testing adversarial task framing as a defense, and its stated outcome for data exfiltration, no sensitive context leaked through tool calls, logs or final output, works as a pass criterion.

Where in-path enforcement fits

Trussed is one implementation of this pattern. It enforces policy in the execution path across agents, tools and MCP servers, with decisions to allow, redact, block, rate limit or escalate for human approval, and the scope is individual interactions and tool calls. Enforcement is at runtime, not reviewed after the fact, and it generates audit-ready evidence mapped to frameworks including HIPAA, NAIC, NYDFS, the EU AI Act and NIST. It can be self-managed in the customer cloud, with configurable retention and data residency, which is relevant to a regulated enterprise deciding where evidence is held.

Trussed does not provide end-to-end tracing of agentic workflows, so the correlation point above still applies. The controls in this guide remain useful whichever enforcement point you choose, provided it sits in the call path and sits outside the model.