Skip to content
Guide intermediate

n8n's April Update Turns Its MCP Server Into a Workflow Builder, Plus 1Password and SSRF Hardening

The short version

n8n's April 2026 release lets an MCP agent author and publish workflows, not just run them. That is a privilege escalation for your automation layer, and the same release ships the role-mapping and audit endpoints that are now mandatory, not optional.

Published April 30, 2026 · Updated May 1, 2026 by Pondero Editorial
Table of Contents

n8n's April Update Turns Its MCP Server Into a Workflow Builder, Plus 1Password and SSRF Hardening

n8n's April 2026 release looks like three unrelated items (MCP workflow tools, 1Password Connect, SSRF protection) but it is one move. The MCP workflow tools let an agent author and publish workflows, not just execute them. That changes the trust model of your automation layer: the agent stops being a caller of trusted, human-reviewed automations and becomes a writer of them. The other two items are not coincidental ship-alongs. They are the controls that make the first item safe to enable, and the practical takeaway is that you turn on MCP authoring and the new role mapping in the same change window or not at all.

What changed

The headline is the MCP workflow tools. Earlier n8n MCP servers let an agent execute existing workflows; the agent could not compose new ones. The April release flips that. An MCP client (Claude Code, Cursor, Windsurf, any MCP-aware agent) can now create, update, publish, and unpublish workflows through MCP. The create and update tools first appeared in the n8n 2.14.0 beta; publish and unpublish landed in the late-April releases shipped April 22 to 29.

The mechanism worth understanding: publish_workflow is the privilege boundary, not create_workflow. A created or updated workflow is inert until it is published. So the security question is not "can the agent write workflows" but "can the agent activate them," and that is exactly the line n8n's new role mapping draws. Gate publish_workflow behind a human role and the agent can draft freely with zero production blast radius. Leave it ungated and a prompt-injected agent can ship an exfiltration workflow in one turn.

The second change is on the secrets side. n8n now supports 1Password Connect Server as an external secrets provider, joining HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. Secrets are fetched at runtime and never persisted inside n8n, so 1Password stays the single source of truth. This is on the Enterprise tier, which keeps it aimed squarely at teams that already have a 1Password Business deployment.

Third: SSRF protection ships as a configurable security setting. Server-Side Request Forgery is a real risk in any platform that takes user-supplied URLs and fetches them server-side, which is essentially every workflow node that hits an HTTP endpoint. The new config lets self-hosted operators block requests to internal IP ranges and metadata endpoints. Cloud customers get this enabled by default. The same release also tightened credential handling and shipped behavior fixes across Chat, Form, Slack, Notion, Todoist, and Facebook nodes, plus new role mapping and workflow archive/unarchive endpoints in the public API.

Why it matters

Until this release, "AI-built automations" meant a human typed a prompt, a model emitted a JSON spec, and someone hand-imported it. The human was the publish gate by default, because importing was manual. The April tools remove that accidental gate. An agent can now go from "audit our error-handling workflows" to a shipped patch in one turn. The gap between intent and running automation collapses from a multi-step manual process to a single agent decision, and so does the accidental safety that the manual step provided.

That is why the governance answer cannot be "we will add review later." The publish capability and the only thing that constrains it (role mapping) arrived in the same release for a reason. The defensible pipeline is draft via agent, approve via human, publish via gated role. Anything short of that is an agent with production write access and no second signature.

The 1Password integration matters more than it looks. For mid-market ops teams, the secret-management story has been the friction point that kept n8n out of regulated environments. Most of those teams already use 1Password Business and don't want to stand up Vault just to satisfy compliance. SSRF protection in the same release removes the other obvious objection from a security review.

How to enable it without handing out publish rights

Upgrade to a late-April 2026 release (2.14.0 or newer). The MCP server is the instance-level MCP endpoint. Point an MCP client at it and the new create_workflow, update_workflow, publish_workflow, unpublish_workflow tools appear next to the execute tools. Full reference is in n8n's MCP server tools docs.

Register the n8n MCP server with the agent's service account, not your own admin token. The service account is what role mapping constrains.

# Wire Claude Code / Cursor to n8n's MCP endpoint with a scoped account
claude mcp add n8n \
  --transport http \
  --url "https://n8n.internal.example.com/mcp" \
  --header "Authorization: Bearer <N8N_AGENT_SERVICE_TOKEN>"

The control that makes this safe: deny publish_workflow and unpublish_workflow on the agent's role so it can draft but not activate. Set this before you connect the agent, not after.

# Restrict the agent service account to draft-only via the public API
curl -sX PATCH "https://n8n.internal.example.com/api/v1/users/<AGENT_USER_ID>/role" \
  -H "X-N8N-API-KEY: <ADMIN_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{"role": "workflow:editor", "deny": ["publish_workflow", "unpublish_workflow"]}'
# Verify: the agent's tools/list should now omit publish/unpublish.

For 1Password, you need n8n Enterprise plus a 1Password Connect Server. Configure the external secrets provider, point it at your Connect endpoint with a service account token, and reference vault items by path. Secrets resolve at runtime per execution and never persist in n8n, so a compromised agent-authored workflow leaks a path reference, not the secret.

For SSRF, self-hosted operators set the config via environment variables. The default-deny list covers loopback, link-local, and cloud metadata IPs. This is the control that stops an agent-authored workflow from being pointed at 169.254.169.254 to lift cloud credentials. Allow-list real internal ranges explicitly rather than disabling it.

The starting pattern that works: connect Cursor or Claude Code with the draft-only account above, ask it to audit existing workflows for missing error handling, let it propose patches via update_workflow, and keep activation behind a human pressing publish in the UI until the agent's edit quality has earned the gate being widened.

The call

Enable the MCP workflow tools. The draft-via-agent loop is a real productivity step and the protocol-level capability is solid. But treat the publish gate as the entire security decision: ship the role-mapping restriction and the SSRF config in the same change as the upgrade, or do not upgrade yet. The recommendation flips only if you self-host without role mapping available (older Community editions), in which case wait until you can gate publish, because an ungated agent with workflow authoring is a standing exfiltration primitive, not a convenience.

This post is part of Pondero's daily coverage of AI tool updates. See all guides →