How MCPProxy Could Monitor MCP Server File Access Without Docker

Algis Dumbris • 2026/03/13

TL;DR

MCPProxy has Docker isolation for MCP servers that need it, schema quarantine for new connections, and sensitive data detection for tool responses. But Docker is heavyweight — most developers do not run every MCP server in a container. The next frontier is lightweight OS-level monitoring: knowing what files an MCP server process actually touches, without the overhead of Docker. Linux’s Landlock and seccomp provide the primitives. macOS is harder. Here is the research and the roadmap.

The Gap

MCPProxy currently addresses MCP security at three levels:

Schema quarantine catches malicious tool definitions before they reach the agent. New MCP server connections are quarantined, their tool schemas analyzed for known attack patterns, and suspicious tools flagged for manual review.

BM25 pre-filtering reduces the attack surface by limiting which tools enter the agent’s context. Instead of presenting hundreds of tool definitions, the agent sees only the 3-5 most relevant ones.

Sensitive data detection scans tool responses for credentials, API keys, and other sensitive patterns, alerting when a tool returns data that should not be in the response.

Docker isolation runs MCP server processes in containers with controlled filesystem access, network restrictions, and resource limits.

But Docker isolation is opt-in and heavyweight. Most developers run MCP servers as native stdio processes — npx, uvx, or compiled binaries that launch directly on the host. These processes have full access to the user’s filesystem, network, and credentials. If a compromised MCP server reads ~/.ssh/id_rsa or ~/.aws/credentials, MCPProxy’s protocol-level protections cannot detect it because the access happens at the OS level, below the MCP protocol.

The question: can we monitor what these processes actually do without wrapping them in Docker?

Linux: Landlock + seccomp

Linux provides two complementary kernel mechanisms that together offer both enforcement and monitoring.

Landlock for Filesystem Enforcement

Landlock is a Linux Security Module (merged in Linux 5.13) that enables unprivileged process sandboxing. Unlike AppArmor or SELinux, Landlock does not require root configuration — any process can voluntarily restrict its own capabilities.

The mechanism is straightforward: create a ruleset, add rules for specific filesystem paths (read, write, execute, create), and apply via landlock_restrict_self(). The restrictions are irreversible and hereditary.

How MCPProxy would use it: Before launching a stdio MCP server process, MCPProxy would create a Landlock ruleset that:

• Grants read/write access to the server’s designated working directory
• Grants read-only access to the server’s binary and dependencies
• Blocks access to sensitive paths (~/.ssh/, ~/.aws/, ~/.gnupg/, browser profile directories)
• Grants network access only to declared endpoints (Landlock ABI v4 supports TCP bind/connect restrictions by port)

Go implementation: The go-landlock library (by Seth Hoenig, HashiCorp) provides clean Go bindings. HashiCorp Nomad already uses it to sandbox artifact downloads — granting read/write/create only to allocation directories and read/execute to system binary paths. The library includes pre-configured path groups (DNS(), Certs(), Tmp()) that cover common needs.

MCPProxy already manages process groups for stdio servers (Setpgid=true). Adding Landlock sandboxing before exec is a natural extension of the existing process management.

seccomp User Notifications for Monitoring

While Landlock enforces filesystem restrictions, seccomp SECCOMP_RET_USER_NOTIF (Linux 5.0+) provides real-time monitoring of syscalls. When a monitored process hits a matching syscall, it blocks in the kernel while a supervisor process receives the full details — syscall number, arguments, and calling PID.

How MCPProxy would use it: A monitoring mode (separate from enforcement) that intercepts open(), connect(), execve(), and unlink() syscalls from MCP server processes. Each intercepted call generates an activity log entry showing exactly which files the server accessed, which network connections it made, and which processes it spawned.

This integrates naturally with MCPProxy’s existing activity log and sensitive data detection. If a server opens ~/.aws/credentials, the activity log records it. If the sensitive data detector sees AWS keys in a subsequent tool response, the filesystem access log provides the causal chain.

Important caveat: seccomp user notifications have a TOCTOU race condition for syscalls with pointer arguments. They are effective for monitoring and audit logging but should not be the sole enforcement mechanism. That is why the two-layer approach matters — Landlock enforces, seccomp monitors.

Go libraries: libseccomp-golang (307 stars) provides seccomp BPF filter management. cilium/ebpf (7,600 stars) offers eBPF-based alternatives for newer kernels. u-root/u-root (2,900 stars) includes a pure Go strace implementation for ptrace-based tracing.

macOS: Limited Options

macOS sandboxing is significantly harder due to platform restrictions.

Endpoint Security framework provides comprehensive process, file, and network monitoring — but requires an entitlement that Apple grants only to recognized security vendors. Impractical for MCPProxy.

DYLD_INSERT_LIBRARIES can inject monitoring code into MCP server processes. Since most MCP servers are unsigned Python (uvx) or Node.js (npx) processes, the injection works. The injected library can intercept file access calls and report them back to MCPProxy. However:

• System Integrity Protection blocks injection into Apple-signed binaries
• Hardened Runtime blocks injection by default
• Not reliable for all process types

Seatbelt (sandbox-exec) provides kernel-level sandboxing via SBPL profiles. Apple deprecated the public command but the mechanism still works. The nono project (by Luke Hinds of Sigstore fame) uses Seatbelt for macOS agent sandboxing successfully.

Bottom line: There is no cross-platform solution. MCPProxy would need separate backends for Linux (Landlock + seccomp) and macOS (DYLD_INSERT_LIBRARIES or Seatbelt). Linux support would come first, with macOS as a best-effort follow-up.

The Competitive Landscape

No existing MCP security tool does filesystem auditing:

The closest project is nono, which provides Landlock/Seatbelt enforcement for AI agent processes. But nono is a standalone sandbox — it does not integrate with MCP protocol-level security (quarantine, BM25 filtering, sensitive data detection). MCPProxy adding filesystem monitoring would combine all three security waves — protocol, traffic, and OS-level — in a single tool.

Roadmap

Phase 1: Landlock enforcement (Linux). Add optional Landlock sandboxing for stdio MCP servers. Configuration per server in mcp_config.json:

{
  "name": "filesystem-server",
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"],
  "sandbox": {
    "enabled": true,
    "allow_paths": ["/home/user/projects"],
    "deny_paths": ["~/.ssh", "~/.aws", "~/.gnupg"],
    "network": "restricted"
  }
}

Phase 2: seccomp monitoring (Linux). Add syscall monitoring that logs file access, network connections, and process execution to the activity log. This runs alongside Landlock enforcement, providing both prevention and detection.

Phase 3: macOS support. Implement DYLD_INSERT_LIBRARIES-based monitoring for Python/Node MCP servers and Seatbelt-based sandboxing where possible.

Phase 4: Behavioral baselines. After collecting filesystem access patterns from monitoring, build behavioral baselines per server. Alert when a server accesses files outside its normal pattern — the filesystem equivalent of schema drift detection.

What This Means for MCPProxy Users

Today: use Docker isolation for MCP servers that handle sensitive data or come from untrusted sources. MCPProxy’s Docker isolation already provides filesystem, network, and resource restrictions.

Tomorrow: lightweight OS-level sandboxing will provide similar protection without the Docker overhead. MCP servers will run as native processes but with kernel-enforced filesystem restrictions and real-time access monitoring.

The goal is defense in depth: schema quarantine catches malicious tool definitions, BM25 pre-filtering limits context exposure, sensitive data detection catches credential leaks, and filesystem sandboxing prevents unauthorized access at the OS level. Each layer catches what the previous one misses.