Questions about n8n security usually come up just before go-live, when a workflow built quickly with AI help is about to handle live customer data. An AI-built automation is a workflow whose steps, settings or code were created with AI assistance. Its security has two layers. On n8n Cloud, Make and Zapier, the vendor runs the hosting. You control what each connected account can do, who can trigger a webhook and where customer data ends up.
This guide covers the checks to run before go-live, the evidence to request from your developer and where each setting sits in n8n, Make and Zapier. For the wider product view, see our guide to shipping AI-built products safely.
TL;DR
- The risk sits in your workflows, not the platform. n8n Cloud, Make and Zapier secure hosting and encryption. Five of seven security controls stay with you, including connection permissions, webhook authentication and execution history. Self-hosted n8n adds patching: CVE-2026-21858 (CVSS 10.0) required version 1.121.0 or later.
- Three checks come before live data. Each connected account has only the permissions its task needs. Each webhook verifies the sender before a protected action runs. Execution history keeps no more personal data than necessary. If any check fails, keep the workflow off live data.
- Personal data in a workflow brings GDPR duties. You need a processor agreement with each platform and AI provider (Article 28) and limited retention (Article 5(1)(e)). A breach must be reported to the Autoriteit Persoonsgegevens within 72 hours where feasible (Article 33).
How secure is n8n? The platform and your workflows are separate questions
n8n as a platform has standard controls: encrypted credentials, HTTPS for webhooks and the API, and user access controls such as roles, SSO and MFA, with availability depending on plan. Most risk sits one layer up, in the workflows you build on it. Make and Zapier follow the same split. n8n describes its platform controls on its security page.
The question to ask is therefore not “is the tool secure?” but “which controls are ours?”. The answer depends on how you host.
| Control | n8n Cloud, Make, Zapier | Self-hosted n8n |
|---|---|---|
| Hosting, platform encryption and platform patching | Vendor | You |
| SSO, MFA and user roles | Vendor provides (plan-dependent); you switch them on | You configure (licence-dependent) |
| Permissions of each connected account | You | You |
| Webhook authentication | You | You |
| Personal data kept in execution history | You set retention | You set retention and storage |
| Generated code, templates and community components | You | You |
| Who can edit, run and stop workflows | You | You |
Five of the seven controls stay with you whichever platform you choose. That is why an AI-built workflow on a well-secured platform can still expose customer data.
What should you check before running an AI-built automation?
Start by mapping one workflow from its trigger to its final action, including the accounts and stored data along the way. The map gives your developer a defined process to review.
Record:
- The purpose, trigger and any public entry point, such as a webhook (a URL that receives requests from another service).
- Each connected account, its owner and the actions it can perform.
- The incoming fields, destination systems and data saved in execution history, queues or failed runs.
- Any AI provider, generated code, imported template or third-party component, plus the person responsible for operating the workflow.
For example, imagine a workflow that receives a customer email, uses AI to classify it and creates a CRM task. The email enters from outside the business. Selected fields go to the AI provider. A CRM connection creates the task, and execution history may retain a copy of the processed data.
That example has four review points, even though the visible outcome is one task. If fixed rules classify the email instead, the AI-provider checks fall away; the connection, access and storage checks remain.
AI assistants write for a successful run. They tend to request the permission that makes the call succeed and to leave a test webhook without authentication. One over-scoped CRM token can expose the whole customer base.
Workflow automation security checks for n8n, Make and Zapier
Review the permissions and data handling behind each business action. A successful run proves the workflow completes its task. It says nothing about whether unauthorised requests are rejected.
Use the checklist below with the person who built or maintains the workflow. Request redacted evidence so the review itself does not expose credentials or customer records.
| Control and risk | Question for the developer or owner | Evidence to request |
|---|---|---|
| Credentials and connected accounts. Permissions can extend beyond the workflow’s purpose. | What can each connection read or change, who owns it, and has obsolete access been revoked? | Redacted connection list, granted permissions and a record of revoked access. |
| Triggers and webhooks. Unverified requests can reach protected actions. | Where is the sender or request authorised before the action runs? | Authentication or validation settings and a test showing an unauthorised request is blocked. |
| Generated code and imported components. Imported logic may call unapproved destinations. | Who reviewed the code or component, and which destinations can it contact? | Reviewed workflow export or code changes, component list and approved outbound destinations. |
| Access to business records. A valid connection can target the wrong customer’s record. | Can incoming data select records or destinations outside the caller’s permitted scope? | Authorisation rules and a test showing that out-of-scope access is refused. |
| Execution history. Payloads can remain in other services or diagnostic storage. | What is sent, saved or retained after failures, and who can read it? | Field-level data map, retention and access settings, redacted execution examples. |
| Failed runs. A workflow can stop without anyone noticing, so invoices or follow-ups silently stop. | Who is alerted when a run fails, and how quickly? | Error-workflow or alert settings and the name of the person who receives them. |
| Editing rights and ownership. Workflow changes can alter how credentials are used. | Who can edit, publish, run or stop production, and how is a departing employee’s access removed? | Access list, identity controls, separate test and production accounts, and a named owner. |
If a workflow uses a privileged database key, such as a service-role key, ask where customer-level authorisation is enforced. These keys bypass row-level security (database rules that decide which user may see which row). The workflow then has to check entitlement itself.
Keep credentials out of prompts, inline code, workflow notes and screenshots. If exposure is suspected, restrict affected access, preserve relevant evidence and revoke or replace the exposed credential. Use the guide to exposed API keys for the detailed response.
Which security issues should you fix before using live data?
Keep the affected workflow off live sensitive data if any of these is true:
- an unverified trigger can reach protected actions
- a connection exposes records beyond its approved scope
- credentials are known to be compromised
Lower-priority gaps, such as incomplete operational documentation, can follow a documented improvement plan if they do not weaken those controls. Record each open issue’s impact, owner and the evidence needed to close it.
Not sure which of your workflows hold customer data or admin-level access? Start with an independent look at the evidence. An AI-built product review checks code and architecture, reliability and critical flows, and shows what was found, why it matters and the evidence behind it. Talk to us about a review →
Where to check security settings in n8n, Make and Zapier
Review each workflow’s connections, trigger settings and execution history with whoever maintains it. Request redacted evidence and use the official documentation for implementation detail.
n8n security checks
n8n security covers the instance configuration and each workflow’s permissions and data paths. Request three sets of evidence:
- Connections and webhooks: the account permissions behind each connected node and its webhook authentication settings. Confirm the evidence covers the production endpoint, because n8n uses separate test and production URLs.
- Code and execution history: a review of generated code, imported or community nodes and outbound destinations. Keep a redacted workflow export, execution examples and the list of people who can edit the workflow.
- Security audit: the built-in security audit report (CLI command n8n audit) with an explanation of relevant findings. Treat the report as a baseline. It flags risky settings and nodes, but it cannot check your business-access rules.
Make security checks
For Make scenarios, focus on connections, webhook controls and retained payloads:
- Connections and mapped data: the connected account’s permissions and an annotated scenario or blueprint. Identify generated code, custom requests, destination URLs and unnecessary fields. Check who can edit or stop the scenario.
- Incoming requests: evidence of custom webhook authentication and request validation. Make supports API key authentication. Detecting fields from a sample payload does not switch on validation.
- Execution history: redacted examples from execution history and failed-run storage. Keep data confidential limits payload retention in new execution logs, at the cost of harder troubleshooting. Inspect incomplete executions and webhook queues separately; one toggle does not cover every storage location.
Zapier security checks
For each Zap, ask the owner to demonstrate account access, sender verification and control over downstream actions:
- Connections and editing: the account identity and permissions behind each action, plus the Zap’s sharing list. Review mapped fields and any Code or custom-request steps. A connection’s display name says nothing about its access scope.
- Webhook verification: for Catch Hook or Catch Raw Hook, ask where the sender is verified before a protected action runs. Knowing a unique receiving URL does not make a caller authorised.
- Zap history and approvals: redacted Zap history samples showing retained fields. If Human in the Loop is used, confirm reviewer access and that a refusal stops the protected action. Zapier can be set to continue after a decline, so check the setting, not just the presence of the step.
Self-hosted n8n: patching and hardening
Self-hosting moves the platform layer from n8n to you. In January 2026, n8n disclosed CVE-2026-21858, a critical flaw (CVSS 10.0) in form-based workflows. It let unauthenticated attackers read files on the server. Self-hosted instances needed version 1.121.0 or later; n8n Cloud was updated by n8n. Self-hosted instances without a patch owner stay exposed until someone notices.
For self-hosted n8n, request evidence of:
- a named owner for version updates and security advisories
- HTTPS through a reverse proxy, with the editor not open to the public internet
- the encryption key stored outside the instance and backed up
- database backups that have been restored in a test
- unused nodes blocked, and SSRF protection switched on (it stops a workflow from being used to call internal systems)
Managed hosting removes these infrastructure tasks. The workflow checks above still apply.
Extra safeguards when your workflow uses AI
A workflow that calls an AI model while it runs needs checks on the model’s inputs, outputs and permitted actions. The checks apply whether AI summarises a message or an agent selects a tool, but the consequences differ.
In the customer-email example, a classification step returns a category for fixed routing. An agent allowed to choose CRM actions has more discretion. Review that discretion explicitly:
- Send only the fields the task needs. Check the provider’s data handling and retention against your requirements.
- Treat incoming emails and documents as untrusted content. An email could contain instructions asking the model to send customer details elsewhere, which is a prompt-injection risk.
- Validate the returned category, record identifiers and destinations before downstream use. Keep permission checks in workflow logic or connected systems, outside the model’s instructions.
- Limit available tools and actions. Where a wrong action could disclose information, move money or change important records, require an approval step. Show the reviewer the proposed action, target and parameters, and make a refusal block the action.
Ask for the input field map, validation rules and approval configuration, and judge them against the consequence of the action. For agents with wider tool access, see AI agent security.
GDPR duties for data that passes through your automations
When a workflow moves personal data, GDPR obligations follow the data into every tool it touches. For EU businesses, four articles matter most:
- Article 28: each platform and AI provider that processes personal data for you needs a processor agreement (data processing agreement).
- Article 32: security measures must fit the risk; scoped credentials, authenticated webhooks and restricted editor access are examples.
- Article 5(1)(e): personal data may be kept no longer than necessary, and execution history counts as storage.
- Article 33: a personal data breach, such as a leaked token that exposed customer records, must be reported to the Autoriteit Persoonsgegevens without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to put people at risk.
A workflow review shows where these duties apply. It is not a legal assessment of GDPR compliance; involve your privacy officer or lawyer for that.
Fix it yourself, get a review or rebuild the automation
The right next step depends on what the workflow carries and how much of your business runs through it.
| Situation | Recommendation | Condition |
|---|---|---|
| A few workflows, no personal data, cloud-hosted | Fix it yourself with the checks above | Someone in the team can show evidence for each control |
| Workflows carry customer or employee data, or self-hosted n8n has no patch owner | Get an independent review before live use | You need evidence for customers, investors or a GDPR record |
| Orders, invoicing or onboarding run on a chain of workflows with AI-written code | Rebuild as a maintained process automation | Failures already reach customers, or no one can explain how the chain works |
How Sunbytes reviews and rebuilds business automations
The platform is rarely the weak point. Incidents start in the workflows on top of it: broad tokens, open webhooks and execution history full of customer data.
Sunbytes reviews software engineering and security together, so one pass covers a workflow’s code, credentials and data flow. You get findings with evidence and a prioritised action plan. You also get a handoff your developer can work from, written in plain English rather than as a scanner export. Delivery runs under an ISO/IEC 27001:2022-certified ISMS, with Dutch-led governance and 300+ projects delivered since 2011.
Some core processes, such as orders, invoicing or onboarding, outgrow a chain of quick workflows. Our process automation team can rebuild them as a maintained system. If the automations sit behind a customer-facing product, start with an AI-built product review. Every setup differs, so scope is agreed case by case.
