Production gotchas — untrusted content, destructive actions, permission scope

At a glance

Learning objectives

• Treat fetched content as untrusted model input and scope its network path
• Bound destructive actions with deny-by-default hooks
• Scope every credential to the role and repositories the task needs

What you need

• The MCP specification's security section
• The tool list and schemas of every server you connect
• A non-production database role with SELECT only

Steps

1. Read the MCP specification's security section before connecting any MCP server to real data — it is the definitive reference for transports (stdio, SSE, HTTP), tool definitions, resource templates, prompts, and the security model. (from ref-mcp-spec )
2. Anything fetched becomes model context — the fetch tool retrieves a URL and converts it to markdown for the model. (from mcp-fetch )
3. And fetch is network egress to arbitrary URLs — it can reach internal endpoints (SSRF risk), so in a corporate environment route it through an allowlisting proxy. (from mcp-fetch )
4. Destructive actions are denied by default — intercept DROP / TRUNCATE / DELETE-without-WHERE before the agent executes it. (from hook-destructive-sql-guard )
5. Scope warehouse credentials — the reference SQL server issues raw SQL: connect with a role that only has SELECT on the schemas intended, prefer a replica, and do not point it at production with a superuser. (from mcp-postgres )
6. Scope repository credentials — use a fine-grained GitHub token limited to the target repositories, read-only unless the task must open PRs; never grant org-wide admin. (from mcp-github )
7. Audit the contracts before connecting — flag tools that can write, delete, spend money or exfiltrate data, and produce a least-privilege connection recommendation. (from skill-mcp-tool-contract-auditor )

Check yourself

• Every MCP server connected has had its tools classified — none can write, delete, spend or exfiltrate beyond what the task needs.
• The database role has SELECT only, the GitHub token is fine-grained and read-only, and fetch runs behind an allowlist.

Worked example

The security section of the MCP specification is required reading before
connecting any MCP server to real data: transports (stdio, SSE, HTTP),
tool definitions, resource templates, prompts, and the security model.

The reference server issues raw SQL. Connect with a role that only has
SELECT on the schemas intended, and prefer a replica. Do not point it at
production with a superuser.

Requires a GitHub token. Use a fine-grained token limited to the target
repositories and read-only unless the task must open PRs. Never grant
org-wide admin.

Sourced from

• Model Context Protocol Specification
• Fetch MCP Server
• Destructive SQL Guard
• PostgreSQL MCP Server
• GitHub MCP Server
• MCP Tool Contract Auditor

Security scan

Last sweep 2026-10-24: 0 finding(s), 0 marked as examples.

Common gotchas

• Network egress to arbitrary URLs can reach internal endpoints — SSRF risk; allowlist the proxy.
• Never point a raw-SQL server at production with a superuser — SELECT-only role, prefer a replica.
• Never grant org-wide admin on the GitHub token — scope it to the target repositories.

Production considerations

• Treat MCP registry entries as discovery, never as a trust signal.
• Classify every tool — write, delete, spend or exfiltrate — before the first connection, and keep the table with the config.

Diagram

production agent
   |
   |- fetched page --> untrusted model context --> allowlisted egress only
   |
   |- SQL tools --> SELECT-only role, replica --> never prod superuser
   |
   |- repo tools --> fine-grained read-only token
   |
   |- destructive SQL --> denied by default
   |
   |- spend/exfiltrate tools --> classified before connect

Registry stats