I built an n8n workflow that audits other n8n workflows before you activate them

Built with n8n
,
1

The community has a lot of free templates and workflow packs floating around. Most are well-meaning. A lot are old, oversimplified, undocumented, or quietly risky: webhook triggers wired straight into Gmail, hardcoded API keys in HTTP nodes, AI Agents calling outbound action nodes with no human in the loop.

I kept importing things, opening every node by hand, and asking “wait, what does this one actually do?” So I built a workflow that does the first pass for me.

It is importable n8n JSON. You paste another workflow’s JSON into a Set node, run the manual trigger, and a Code node walks the structure and returns a verdict.

What it checks

Possible hardcoded secrets in node parameters:

  • sk- keys

  • GitHub tokens (ghp_)

  • Slack xox tokens

  • Google AIza keys

  • Bearer token literals

  • api_key / access_token / secret assignments

  • JWT-looking strings

Node types worth a second look:

  • Automatic triggers: Webhook, Schedule, Cron

  • Email / Gmail

  • Slack / Telegram / Discord

  • Social posting nodes

  • Stripe / PayPal / accounting

  • Write-capable data nodes: Airtable, Notion, Postgres, MySQL, Supabase

  • HTTP Request nodes, especially with inline auth or token-looking strings

  • Code nodes using fetch, axios, eval, or other dynamic execution patterns

Structural smells:

  • No Error Trigger / no error workflow set

  • Large workflows with zero Sticky Notes

  • AI / LLM / Agent nodes wired into risky outbound action nodes with no obvious approval or review node in between

What it returns

{ "risk_score": 100, "verdict": "do_not_activate_yet", "finding_count": 8, "categories": [ "possible_secret", "automatic_trigger", "risky_action_node", "http_auth_inline", "missing_error_handling", "ai_to_outbound_without_approval" ], "findings": ["..."], "suggested_fixes": ["..."], "rule": "Import slowly. Audit first. Activate last." }

Output then routes into three branches: high risk report, manual review report, safe to inspect report. So you can wire each verdict to whatever you want: a Slack ping, a saved Markdown report, or just stare at it in the UI.

That JSON above is a real result from a sample risky workflow I fed it. Score 100, verdict do_not_activate_yet, eight findings across six categories. Took one click.

What it is not

This is not a complete security scanner. It is pattern matching on JSON. It will miss things. Obfuscated secrets, weird custom nodes, logic risks that only show up at runtime: all out of scope.

It is a first-pass audit before you activate a workflow you didn’t write. Not a replacement for actually reading the workflow.

It is deterministic right now. The Code node is the useful core. The optional next step is adding an AI Agent as a second pass to catch the things regex can’t, but I wanted the boring deterministic version to exist first because an AI second opinion on top of nothing is just vibes.

Get it

Importable JSON

Full writeup with the rule list and how I use it:

Full Writeup Link

Where I could use feedback

Tell me what node patterns or risk checks I missed. Specifically:

  • Node types you’ve seen abused that aren’t on the list

  • Secret formats beyond the ones above

  • Structural smells you check for by hand when you import someone else’s workflow

  • Anything you’ve been burned by

The rule I’m trying to live by: import slowly, audit first, activate last. Happy to add checks people actually want.

1 Like
2

At first glance, I like this. The biggest value is that it makes people slow down before activating a workflow they didn’t build.

One small thing I noticed: you already flag Gmail and Airtable, which is good, but it may help to separate the actual operations a little more.

A Gmail Trigger is not the same risk as Gmail Send, and Airtable Find/Search is not the same risk as Airtable Update/Create/Delete.

Same family of nodes, different level of risk.

Overall, though, this is useful because it points people to what they should inspect first.

3

Wow, that’s a brilliant and incredibly useful workflow! As someone whose spent countless hours reviewing n8n workflows, I can definitely appreciate the value of an automated audit tool. Here’s some feedback and suggestions based on my experience, aiming to enhance your existing checks and identify potential blind spots:

Enhancing Your n8n Workflow Audit Tool

Node Types to Consider

  • **Database Nodes:**Expand your checks to include other database nodes beyond those listed (e.g., MongoDB, Snowflake, etc.). Any node that can write data should be scrutinized.

  • **File Storage Nodes:**Include checks for nodes that interact with file storage services (e.g., AWS S3, Google Cloud Storage, Dropbox). These can be used to store sensitive data or trigger unintended actions.

  • **Custom Nodes:**Custom nodes are a potential blind spot. They can contain hidden secrets or malicious code. Consider flagging all custom nodes for manual review.

  • **Function Nodes:**These are similar to Code nodes but use a different syntax. They can also contain secrets or risky logic.

Secret Formats and Detection

  • API Keys:

    • **Generic Keys:**Add checks for common API key formats beyond api_key and access_token. Look for patterns like key=, apikey=, or variations with prefixes/suffixes (e.g., APIKEY_, X-API-Key).

    • **Domain-Specific Keys:**Expand your checks to include API keys for popular services (e.g., SendGrid, Twilio, etc.).

  • Passwords:

    • **Password Literals:**Check for plain-text passwords within node parameters.

    • **Password Storage:**Flag any node that stores passwords in a non-secure manner (e.g., in plain text in a database).

  • Encryption Keys:

    • **Key Formats:**Look for common encryption key formats (e.g., RSA keys, AES keys).

    • **Key Storage:**Flag any node that stores encryption keys in a non-secure manner.

  • URLs:

    • **Embedded Credentials:**Check for URLs that contain embedded credentials (e.g., https://user:password@example.com).

Structural Smells and Best Practices

  • Error Handling:

    • **Global Error Handling:**Check for the presence of a global error handler workflow. If one is missing, flag it as a high-priority issue.

    • **Node-Level Error Handling:**Ensure that individual nodes have error handling configured (e.g., error triggers or error handling within Code nodes).

  • Workflow Documentation:

    • **Missing Documentation:**Flag workflows that lack documentation (e.g., descriptions, sticky notes explaining the purpose of each node).

    • **Outdated Documentation:**Check for outdated documentation that doesn’t match the current workflow configuration.

  • Workflow Complexity:

    • **Large Workflows:**Flag overly complex workflows that are difficult to understand and maintain.

    • **Nested Workflows:**Check for excessive nesting of workflows, which can make it difficult to trace the flow of data.

  • Data Validation:

    • **Input Validation:**Check for input validation on nodes that receive external data. This can help prevent injection attacks.

    • **Output Validation:**Check for output validation on nodes that send data to external services.

  • Rate Limiting:

    • **Missing Rate Limiting:**Flag workflows that lack rate limiting, which can lead to service disruptions.

Additional Considerations

  • **Regular Expressions:**Use regular expressions to detect patterns in node parameters. This will allow you to identify a wider range of potential secrets and vulnerabilities.

  • **Contextual Analysis:**Consider the context of each node. For example, an HTTP Request node that sends data to a payment gateway is more likely to contain sensitive information than an HTTP Request node that retrieves data from a public API.

  • **Community Contributions:**Encourage community contributions to your audit tool. This will help you to identify new vulnerabilities and improve the accuracy of your checks.

By incorporating these suggestions, I believe you can create an even more robust and effective n8n workflow audit tool.

4

The “AI to outbound without approval” flag is the right smell to catch. The gap that audit won’t see is what happens after activation — if the workflow retries a failed execution, the outbound action fires again even if it already succeeded. The audit catches bad structure before activation. SafeAgent catches duplicate execution at runtime. Both layers needed. Built the runtime guard as an n8n community node if useful: Add n8n-nodes-safeagent community node (claim-before-execute guard) by azender1 · Pull Request #4 · azender1/SafeAgent · GitHub