Document and provide hooks for sandboxing file and network access in MCP tools

[dgenio]

Description

Summary

MCP tools and resources built with the Python SDK can, by default, access the full file system, network, and environment of the host process. This is powerful but risky, especially when:

• servers are installed from third parties, or
• LLM agents can call tools based on prompt-injected instructions.

The SDK should clearly document this and provide hooks/patterns for limiting capabilities.

Proposal

1. Document security considerations

   • Add a “Security considerations” section explicitly calling out:
     • file system access,
     • network access,
     • environment variables and credentials.

2. Provide capability hooks

   • Offer configuration points or helper utilities to:
     • restrict file access to specific directories (allowlist),
     • restrict outbound network calls to certain hosts/domains,
     • prevent access to environment variables by default.

3. Encourage process-level sandboxing

   • Provide guidance on running MCP servers in:
     • containers with minimal privileges,
     • separate processes with limited OS capabilities.

Why this matters

• Defense in depth: Even if application code is careful, configuration mistakes or third-party code can introduce risk.
• Prompt-injection mitigation: Restricting what tools can do reduces the impact of malicious prompts.
• Operational guidance: Many users are new to MCP and benefit from clear security best practices.

Acceptance criteria

• Documentation clearly describes the security implications of running MCP servers and tools.
• There are example patterns for restricting file and network access.
• Where feasible, the SDK exposes hooks or configuration points for capability control.

References

No response

[dgenio]

Bumping this to check for maintainer interest — it's been a few months since labeling and the issue has had no activity.

I'm the author and happy to do the work. To keep scope manageable and avoid a large PR, I'd suggest starting with just item 1 (documentation only): adding a "Security considerations" section to the docs that clearly calls out file system access, network access, and environment variable exposure.

That's a no-API-change contribution and would already fulfill the first acceptance criterion. Items 2 (capability hooks) and 3 (process sandboxing guidance) could follow in separate issues/PRs if confirmed as desired.

I also searched for any existing related issues or PRs — nothing overlapping was found.

Could a maintainer confirm whether the documentation portion is in scope and welcome? I'll wait for a ready for work label or explicit sign-off before opening a PR. Thanks!