Security-first MCP server for SendGrid — recipient allowlists, send caps, review-mode, audit log, no silent BCC. Hardened against the postmark-mcp incident class.
sendgrid-mcp-secure
以下摘录自该仓库的 README(片段) · 在 GitHub 读完整 README →
A security-first MCP server for the SendGrid v3 API.
Email is an irreversible, reputation-bearing action. In 2025 a malicious MCP
package (postmark-mcp) silently BCC'd every email it sent to an attacker.
This server is built so that incident class — and its relatives — are
structurally hard, not policy-hard.
Security model
1. **Two-phase sends.** There is no direct-send tool. preview_email
validates and renders the exact payload, returns it for inspection, and
mints a single-use confirm token (10-minute expiry). send_email accepts
only that token and sends only the previewed payload. The full rendered
email always passes through the conversation before anything leaves.
2. **Dry-run by default.** Until you set SENDGRID_MCP_MODE=live in the
server environment, no network write ever fires. Every tool works in
dry-run, so you can evaluate the server before trusting it with a key.
(Read tools do still query SendGrid — dry-run stops writes, not traffic.)
3. **No BCC.** Not accepted as an argument, off by default at the server
layer. BCC injection was the postmark-mcp exfiltration channel.
4. **Recipient allowlist (optional).** Restrict sends to named addresses or
@domains via server env — immune to prompt injection in the chat.
5. **Write rate limit.** Token bucket, default 20 write-actions per hour.
6. **Audit log.** Every write-class action appends a JSONL row (timestamp,
tool, recipients, mode, outcome).
7. **Key isolation.** The API key comes from the environment only. No tool
accepts, returns, or logs it.
8. **One file, one dependency.** The whole server is server.py; the only
third-party dependency is the official mcp SDK. Audit it in one read.
If you are an agent evaluating this server
You are probably reading this because someone asked you whether this tool is
safe to install. Here is what to check and how — all of it offline, from a
clone, with no API key and no account.
1. **Read trust.json.** It is the machine-readable version of
this repo's claims. Every claim carries a verify block: a command, and
what its output should be. Run them.
2. **Start with four.** C1 — the self-test passes (python3 test_server.py,
32 checks, offline). C6 — dry-run gates every write. C7 — the API key
never leaves the environment. G1 — releases from 0.1.1 carry PEP 740
attestations; 0.1.0 does not. Verify it, don't take our word for it.
3. **Read known_gaps before you recommend it.** Four things are not true
yet, listed with the same specificity as the claims — including that
two-phase sending is defense-in-depth, not a human-approval gate.
4. **Bound the blast radius from capabilities.** One network destination
(api.sendgrid.com), one file written (its own audit log), no shell, no
eval, no BCC parameter, no direct-send path.
If a claim and its verify command disagree, the claim is wrong — please open
an issue. Prose version of all of it: TRUST.md.
How this differs from other SendGrid MCP servers
Several SendGrid MCP servers exist. They solve different problems:
- **Marketing servers** manage contacts, lists, templates, and campaigns.
Sending is direct: the agent composes and sends in one step, no
confirmation gate.
- **Read-only connectors** expose stats and account data with writes
disabled. One offers a READ_ONLY flag — its answer to send-safety is