AI Automation Security in 2026: How to Audit Your n8n, Zapier and Make Workflows

Affiliate Disclosure: We review products independently. When you buy through our links, we may earn a commission or a compound recurring commission at zero extra cost to you. Read our editorial policy.

AI-powered automation can connect your business applications, process customer information, access credentials and trigger actions across multiple systems. That makes automation platforms useful—but it also means a poorly secured workflow can expose more than a single application.

In October 2026, new research from internet intelligence company Censys highlighted the growing public exposure of AI-related infrastructure. Its 2026 State of the Internet research reported a 63% increase in exposed AI infrastructure over nine months. The report also flagged a significant patching concern among internet-facing n8n instances with identifiable versions.

These findings do not mean every exposed automation instance is compromised. They do, however, raise a practical question for agencies and operations teams: do you know which automation systems are publicly accessible, what they can access, and whether they are properly secured?

This guide explains how to audit n8n, Zapier and Make workflows, identify common security gaps, and reduce the risk of exposing credentials or sensitive business data.

Quick Verdict: Where Automation Security Risks Come From

TSA Verdict: Start with exposure, patching and credential access—not with the number of AI agents you have deployed. A small number of automations with broad permissions can create a significant security risk if they are publicly accessible or poorly maintained.

The exact controls differ by platform. Self-hosted n8n requires infrastructure-level security decisions that managed services handle differently, while Zapier and Make users still need to review workflow permissions, connected accounts, webhooks and the data passed between applications.

Why AI Automation Security Is Getting More Attention

Traditional workflow automation moves information between applications according to predefined rules. AI-enabled workflows can add another layer: they may interpret incoming information, select tools, or determine which action to take within configured permissions.

That creates several possible exposure points:

• The automation platform: The server or service that executes workflows.
• Connected credentials: Tokens and accounts used to access CRMs, email, storage, databases and other applications.
• Workflow inputs: Customer records, form submissions, documents, prompts and API responses.
• AI tools and integrations: External models, tool endpoints, community nodes and custom code.
• Execution history: Saved inputs, outputs, errors and other diagnostic information.

A weakness in one layer can affect the others. For example, an exposed self-hosted automation server with access to a CRM and cloud storage presents a different risk from an isolated workflow that only sends a notification.

The key is to evaluate the permissions and access paths surrounding each workflow rather than treating all automations as equally risky.

The n8n Exposure Problem: What the Research Actually Says

Censys reported a 63% rise in internet-exposed AI infrastructure over nine months in its 2026 State of the Internet research. The research highlighted n8n among the products appearing in this expanding infrastructure footprint.

Censys also published a security advisory for CVE-2026-21858, a critical n8n vulnerability disclosed on January 7, 2026. Its advisory identifies versions before 1.121.0 as affected and recommends updating to a patched release.

The distinction matters: public accessibility alone does not prove that a server is vulnerable, and a vulnerable version does not by itself establish that an attacker has compromised it. Risk depends on the installed version, configuration, exposure and applicable security controls.

However, teams should not assume that an instance is safe simply because its workflows are working normally.

TSA Security Alert: An Automation Server Can Become a Gateway

An automation platform may hold credentials for several business applications at once. If an attacker gains control of the platform, the potential impact may extend beyond the automation tool itself.

Depending on the permissions available, the attacker may be able to access connected services, inspect workflow data or misuse authorized integrations.

For self-hosted n8n, this is why patching and access control are operational requirements—not optional maintenance tasks.

What to do: Identify your installed n8n version, review the relevant security advisories, and update to a currently supported, patched release. Do not treat version 1.121.0 as a permanent target simply because it addressed the cited vulnerability; subsequent security updates may also be required.

Use the official Censys advisory for CVE-2026-21858 to verify the affected-version details.

How to Audit a Self-Hosted n8n Instance

Self-hosted n8n gives teams control over their infrastructure, but it also means they are responsible for securing and maintaining that environment.

Use this checklist as a starting point.

1. Check Whether the Instance Is Publicly Accessible

Determine whether your n8n editor and API are reachable from the public internet. Confirm that public access is intentional and protected by appropriate authentication and network controls.

Where practical, restrict administrative access to trusted networks or a VPN. Public webhook endpoints may be necessary for integrations, but that does not mean the entire editor should be publicly accessible without suitable protection.

Review your reverse proxy, firewall rules, TLS configuration and authentication setup. Avoid exposing administrative services simply because they need to communicate with external applications.

2. Verify the Installed Version and Patch Status

Record the running n8n version and compare it with current release notes and security advisories.

For production instances, establish a repeatable process for reviewing updates, assessing breaking changes, testing upgrades and deploying patches. Back up the instance before significant changes and verify that workflows still function after upgrading.

A working automation is not evidence that its underlying software is secure.

3. Run n8n’s Built-In Security Audit

n8n provides a security audit that identifies several common configuration and workflow risks.

According to the official n8n security audit documentation, you can run an audit using the CLI, the API or the n8n node.

The audit can report issues involving:

• Credentials that are unused or not associated with active workflows.
• Potentially risky database-query patterns.
• Nodes that interact with the file system.
• Community and custom nodes.
• Unprotected webhooks.
• Missing security settings and outdated instances.

For a self-hosted installation where you have CLI access, the documented command is:

n8n audit

Review the report and investigate the findings relevant to your environment. An audit is a useful baseline, not a guarantee that every security weakness has been found.

4. Review Credentials and Permissions

List the credentials configured in the instance and identify which workflows use them.

Check whether each connection still needs to exist, whether its permissions are broader than required, and whether the account owner or responsible team member is still authorized to use it.

Where supported, prefer dedicated integration accounts and narrowly scoped permissions over personal accounts with broad access. Rotate credentials when exposure is suspected or when required by your security policy.

Do not copy API keys, access tokens or passwords into workflow notes, prompts, source-control repositories or unprotected logs.

5. Inspect Webhooks and Community Nodes

For every public webhook, identify the system that should be allowed to call it. Use appropriate authentication or request validation where supported, and avoid assuming that an obscure URL is sufficient protection.

Review community and custom nodes before using them in production. Check their source, maintenance history, permissions and dependencies. Remove components that are unnecessary or cannot be adequately assessed.

A community node is not automatically unsafe, but it should not receive unrestricted trust simply because it is available in an integration library.

Zapier and Make: What Managed-Platform Users Should Audit

Zapier and Make manage much of their underlying hosting infrastructure, so their users generally do not perform the same server-hardening work required for self-hosted n8n.

That does not remove the need for a security review. Connected accounts and workflow design still matter.

The exact settings available depend on your plan, integration and configuration. Confirm them in the vendor documentation rather than assuming every control is available on every tier.

Review What Your AI Steps Can Access

An AI step that summarizes a public product description has a different risk profile from one that reads customer records, financial documents or internal support conversations.

For each AI-enabled workflow, ask:

• What information is sent to the AI provider?
• Does the workflow need every field it currently passes?
• Can personal or confidential information be excluded or redacted?
• Which tools can the AI step call, and what permissions do those tools have?
• Are the results checked before the workflow performs a consequential action?

Use the minimum information and permissions required for the task. Where a workflow can send an email, update a financial record or modify customer data, consider whether human approval is appropriate before the action is completed.

A Practical Automation Security Checklist

Use this checklist during an initial review and whenever your automation architecture changes.

• Inventory automation platforms, self-hosted instances and AI-related tools.
• Identify which services are publicly reachable and why.
• Check self-hosted software versions against current security advisories.
• Run the n8n security audit where applicable.
• Review connected credentials and remove obsolete access.
• Check webhook authentication and request validation.
• Review community nodes, custom code and third-party integrations.
• Minimize sensitive data passed into AI prompts and external services.
• Review workflow permissions, execution logs and stored data.
• Confirm backups and recovery procedures are appropriate for production.
• Assign responsibility for security updates and ongoing reviews.

This checklist is a baseline, not a formal security certification. Regulated businesses or systems processing highly sensitive information may need a broader review covering identity management, incident response, retention, vendor contracts and applicable compliance requirements.

Common Mistakes That Leave Automation Workflows Exposed

Treating a hidden URL as authentication

A webhook URL that is difficult to guess is not a substitute for suitable access controls. Use authentication and request validation appropriate to the endpoint and its business purpose.

Leaving old credentials connected

A workflow may be disabled while its credentials remain configured. Review unused connections and remove access that no longer serves an operational purpose.

Installing community nodes without review

A node may run with access to workflow data or interact with the environment in ways that deserve scrutiny. Assess the code and permissions before introducing third-party components into a production system.

Assuming a successful workflow is a secure workflow

A workflow can run correctly while using an outdated platform version, excessive permissions or an unnecessarily exposed endpoint. Operational success and security posture must be evaluated separately.

Sending more data to AI than the task requires

Passing entire customer records or documents into a prompt when only a few fields are needed increases unnecessary data exposure. Minimize inputs and review where the information is processed.

What Should You Fix First?

If your audit finds several issues, prioritize them by potential impact and exposure.

If you suspect an actual compromise, do not treat a routine checklist as sufficient incident response. Restrict affected access, preserve relevant logs, investigate the scope, rotate potentially exposed credentials and follow your incident-response procedures.

Frequently Asked Questions

Does a publicly accessible n8n instance mean it has been hacked?

No. Public accessibility is an exposure condition, not proof of compromise. Risk depends on the installed version, authentication, configuration and applicable vulnerabilities. Investigate the instance rather than assuming either that it is compromised or that it is safe.

Is n8n less secure than Zapier or Make?

Not inherently. Self-hosting provides greater infrastructure control but also places more security and maintenance responsibility on the operator. Managed platforms handle more of the hosting layer, while users still need to secure connected accounts, workflow permissions, webhooks and sensitive data.

How do I run a security audit in n8n?

n8n documents a built-in security audit that can run through the CLI, API or n8n node. The CLI command is n8n audit. See the official n8n security audit guide for supported methods and the report contents.

What is CVE-2026-21858?

It is a critical n8n vulnerability disclosed on January 7, 2026. Censys identifies versions before 1.121.0 as affected and recommends updating to a patched release. Check the Censys advisory and current n8n release information to determine the appropriate update for your installation.

Do Zapier and Make users need to worry about server security?

They generally do not manage the vendors’ underlying servers, but they should still review connected accounts, permissions, webhook access, AI data flows, external integrations and execution history. Managed hosting does not eliminate workflow-level security responsibilities.

How often should an agency audit its automation stack?

Review it when introducing a new platform, AI provider, integration or community component; when permissions change; and when a relevant security advisory is published. Establish a recurring review schedule that fits the sensitivity of the data and the importance of the workflows.

Final Verdict

AI automation security is not just a server problem. It is a question of which systems your workflows can access, what information they process, and what happens if a credential, endpoint or component is misconfigured.

The latest Censys findings make this a timely issue, particularly for teams operating self-hosted automation infrastructure. But the practical response is not to abandon AI agents or assume that every exposed system has been compromised.

Start with a clear inventory, verify patch status, review credentials and webhook access, and use the security-audit tools available in your platform. Then reduce unnecessary permissions and sensitive data flows.

The goal is not to automate less. It is to make sure every automation has only the access it needs—and that someone is responsible for keeping it secure.