An automation that organizes public leads has one risk profile. An automation that reads a client’s mailbox, changes CRM records and sends messages under its name has another.
The point at which an n8n workflow gains access to those systems is a sensible point for an independent security review. That is especially true when an agency operates several clients’ automations or when an AI step can decide which action happens next.
Map the authority behind each workflow
Start with a practical inventory. For each important workflow, identify what starts it, who controls that input, which credentials it uses and what those credentials allow it to do.
A workflow described as “summarize support requests” may also be able to read the entire inbox, retrieve customer records and send outbound email. Its business name does not tell you the limits of its access.
Write down the intended action boundary. Can it only draft a reply, or send it? Can it retrieve one customer’s order, or search every order? Who approves a change to those permissions? These answers define what an assessment needs to test.
Use the built-in audit as an input
n8n provides a native audit feature that flags several common risks, including unprotected webhooks, risky nodes, some database-query patterns and instance settings. Run it and investigate its findings. n8n security-audit documentation.
A separate review should then examine the rules specific to your operation. For example, can a genuine webhook request cause an action for the wrong client? Does an authenticated employee have more authority through a workflow than through the original application? Those questions depend on your business permissions and integration design.
Authenticate the event and authorize the action
Imagine a workflow that creates a customer refund after receiving an event from another system. Verifying the source of that event is important. The workflow also needs to establish which customer, order and amount it is allowed to act on.
Test that the relevant identifiers remain bound together throughout the workflow. Check how duplicate events and retries are handled. Use synthetic records, test integrations and explicit limits so the assessment does not create real refunds or contact actual customers.
Signed or authenticated input can still contain an action the sender should not be allowed to request. The assessment needs to follow the request through to the connected service.
For agencies, inspect the boundary between clients
If an agency manages five clients, document where their workflows, credentials and operational records are separated. Examine who can edit workflows, inspect execution history, export configurations and administer the underlying environment.
Include contractors and former team members. Access that was reasonable during implementation may be unnecessary after handover. A support account may also have broad visibility that neither the agency nor its clients intended.
Do not assume that putting workflows in differently named groups proves isolation. Equally, do not assume that separate deployments are secure without reviewing the shared administrative access and backup arrangements. Test the actual configuration against the promised boundary.
Review the information left behind
Workflow processing can create secondary copies of information in execution records, debug output, error messages and exported data. Establish which copies your deployment retains, who can read them and how long they remain available.
A customer-support workflow may need to process a message without retaining its full content in every operational record. A failed request may reveal details that a successful request hides. Include both paths in the review, using synthetic examples.
Credential storage also deserves examination beyond the workflow editor: deployment configuration, backups, source repositories and incident-recovery access may all be relevant to the agreed scope.
Give AI steps explicit action limits
When an AI step consumes customer messages or third-party documents, treat that material as untrusted input. Establish whether it can influence the recipient of an email, the target of a CRM change or the selection of a privileged tool.
Define actions that require approval and enforce those limits outside the model’s conversational instructions. Then test the implementation with controlled adversarial inputs and simulated downstream actions.
Review which nodes and capabilities users can invoke. n8n documents ways to restrict node availability; the appropriate approach depends on the deployment and the capabilities the team actually needs. n8n node-restriction documentation.
Request a report tied to business consequences
A useful finding describes the entry point, the authority obtained and the action or data exposed. It should identify the affected workflow and integration, provide redacted evidence and recommend a concrete change.
For example, a controlled test might establish that a webhook caller could select another test client’s record for an outbound message. The fix would need to restore that client boundary, followed by a repeat of the same test. Merely rotating a credential might leave the authorization flaw intact.
Agree the workflow inventory, authorized integrations, action limits and retest window before work begins. The outcome should help your team decide which automations are ready for their intended access and which controls need changing first.
Need independent testing before a client handover or production launch? Request a written n8n audit scope based on your workflows, connected systems and the actions they can perform. Build your audit scope ↗
Published 28 October 2026. Original Atlant Security analysis. Scenarios and diagrams are illustrative, not client findings. Platform references are linked beside the relevant guidance.