Question about MCP runtime security for mailchimp-mcp-server

[MaazAhmed47]

Hi,

I’m researching runtime security patterns for high-risk MCP tools and came across mailchimp-mcp-server.

For projects like this, do you think users need controls like:

• tool-call argument inspection
• per-role tool permissions
• audit logs
• shadow/dry-run mode before enforcement
• response scanning

I’m asking because I’m building Interlock, a self-hosted runtime security gateway for MCP agents, and trying to understand what should live inside MCP servers vs an external gateway.

2-min demo:
https://drive.google.com/file/d/1gyIKe4jn7Y25m61saM_qQRWtmLVrCqCX/view?usp=drive_link

Full details:
https://interlock-security.notion.site/Interlock-Runtime-Security-Gateway-for-AI-Agents-35a82dc0e7c380efb499dbef25046664

If you’d prefer to reply privately:
maazahmed1856@gmail.com

Thanks,
Maaz

[damientilman]

Thanks for the question.

For context, mailchimp-mcp-server already ships some of the controls on your list, which shapes how I see the split:

• Read-only mode (MAILCHIMP_READ_ONLY=true) blocks all write tools; reads still work.

• Dry-run mode (MAILCHIMP_DRY_RUN=true) returns a preview of each write (tool, target, params) without hitting the API — that’s your “shadow mode,” server-side.

• Per-account flags let a write-protected and a writable account coexist.

All writes go through a single _guard_write chokepoint, so enforcement is consistent. On server vs. gateway, my take is defense-in-depth, split by who owns the semantics:

• In the server, only it knows which tools are reads, writes, or irreversible (this one has 14 permanently-destructive tools), what API call a dry-run would make, and the argument contract to validate (required IDs, batch caps).

• In the gateway: a centralized/tamper-resistant audit sink, RBAC across many servers, and response scanning/DLP applied uniformly.

The server exposes semantic guardrails + machine-readable risk metadata (is-destructive, risk tier, structured audit events), and the gateway consumes that to enforce policy centrally. A gateway that has to guess which call is destructive is working blind; one handed a destructive: true signal can enforce cleanly.

Btw we're actively building out the server-side guardrails right now so there’ll be more of this metadata to lean on soon.

[MaazAhmed47]

This is a really clean split, and I agree with it the server owns the semantics (it's the only thing that knows which of your 14 destructive tools is irreversible, what a dry-run would actually call, the argument contract), and the gateway owns cross-server enforcement, audit, and DLP. You _guard_write chokepoint + dry-run + machine-readable risk metadata is exactly the shape a gatewaywants to consume rather than guess at.

That's precisely where Interlock sits, and your "a gateway handed a destructive:true signal can enforce cleanly vs one that has to guess is working blind" line is the whole thesis. The case I focus on is the runtime layer: once an operator has approved your server, does the gateway notice if a tool's declared risk metadata, schema, or effective behavior changes after that approval including the harder case where the manifest is unchanged but a call that returned 403 now returns 200. Your metadata makes the "declared" side trustworthy; the gateway's job is verifying the approved version is still the one executing.

Genuinely interested in the risk metadata you're building out the more servers emit is-destructive / risk-tier / structured audit events natively, the less any gateway has to infer, which is strictly better. If it's useful as you design it, happy to compare notes on what a runtime-trust gateway would want that metadata to look like so it composes cleanly. No agenda, your server-side direction is exactly the right one.

[damientilman]

I think that's the right split. Server declares what each tool is (risk tiers + the MCP annotations, plus audit logs per call), gateway checks the approved version is actually the one running and watches for drift. The 403 -> 200 case is really your side, the server can't vouch for that about itself. Good luck with Interlock!