Should n8n-MCP clients re-check trust if read-only/management scope changes?

[MaazAhmed47]

Hi,

First, impressive work on n8n-MCP. The validation-first workflow building flow is strong, and I appreciated the README’s explicit warning not to edit production workflows directly with AI.

I’m looking at the trust boundary around the n8n management surface, especially:

• workflow create/update/delete
• partial workflow updates
• deploy template
• test/trigger workflow
• execution deletion
• credential management
• read-only deployments using disabled tools / disabled operations

One question I’m exploring:

If a client approves n8n-MCP in a read-only or validation-only state, should the runtime re-check trust if that approved tool surface changes later?

Example drift cases:

• a docs/validation-only setup later exposes workflow create/update/delete
• a read-only deployment later gains partial update or delete operations
• credential-management tools become available after approval
• delete/rollback/prune operations appear under the same approved server
• tool schemas or descriptions stay similar, but the execution blast radius changes

To a static allowlist, this may still look like the same approved MCP server. But from the user/agent perspective, the capability changed from “help me validate/build” to “modify/delete workflows or touch credentials.”

How do you think this should be handled for n8n-MCP users today? Is post-approval re-review expected to happen outside the server, or is it not part of the current threat model?

I’m asking because I’m building Interlock, an open-source MCP runtime trust layer focused on post-approval tool drift, so I’m trying to understand how maintainers of high-impact MCP servers think this boundary should be handled.

Happy to run a small non-production drift check against n8n-MCP’s public tool surface if useful. No n8n instance, no API key, no credentials. I’d baseline a safe/read-only surface, simulate one harmless drift case, and send back the diff + Security Receipt.

Maaz
https://getinterlock.dev

[P-r-e-m-i-u-m]

@MaazAhmed47 — you're hitting a massive blind spot in the current MCP spec.

Right now, standard MCP clients do a one-time trust prompt. If a server adds delete_workflow or manage_credentials an hour later, the client just silently allows it because the base connection is already approved.

The current n8n-MCP threat model basically assumes you scope the tools in your config before you connect, and relies on the client to enforce it. But since clients don't track tool drift post-approval, you're absolutely right that the blast radius can change without the user knowing.

Your Interlock layer is exactly what's missing here. I'd say let them run that non-production drift check—it would highlight exactly why post-approval monitoring is mandatory for high-impact servers like n8n.

[MaazAhmed47]

Thanks I appreciate you weighing in. You put it well: clients do a one-time trust prompt and don't track drift after. That gap is exactly what I'm working on. If you or anyone you know is running n8n or other MCP tools against real workflows and wants to see a drift check, happy to show it, no strings.