Workflow automation platforms quietly hold some of the most powerful credentials in a business: OAuth tokens and API keys that connect the CRM, the mailbox, the file store and the finance system, owned by whoever built the flow. This list ranks the ten workflow automation security risks that most often lead to data leaks and account abuse, with how to spot each one and how to fix it. It covers integration platforms such as Make, n8n, Power Automate, Workato and Zapier (listed alphabetically; examples, not a ranking), and the same risks apply to robotic process automation and AI flow builders. It is written for security teams, platform owners and IT leads who govern citizen-built automation. For a hands-on credential review, use How to audit Zapier, Make and n8n connections and credentials; this page is the risk list behind that audit.
Key takeaways
- Every connection is a non-human identity. A flow's stored OAuth refresh token or API key acts with the builder's rights, around the clock, long after the builder has moved on.
- Personal connections are the biggest single risk. OWASP's Citizen Development Top 10 lists account impersonation (CD-SEC-02) and authorisation misuse (CD-SEC-03) because shared flows run as their creator.
- Data flows cross boundaries silently. A two-step flow can copy customer data from a governed system into a personal mailbox or an unmanaged SaaS app.
- Self-hosted platforms are internet-facing servers. CISA added an n8n remote code execution flaw, CVE-2025-68613, to its Known Exploited Vulnerabilities catalogue in March 2026.
- Governance is mostly inventory and ownership. Most fixes start with knowing which flows exist, who owns them, which connections they use and what data they move.
The Top 10 at a glance
| # | Risk | What it leads to | OWASP Citizen Development Top 10 |
|---|---|---|---|
| 1 | Flows running on personal connections | Anyone using the flow acts as its creator | CD-SEC-02 Account Impersonation |
| 2 | Over-scoped OAuth grants and admin API keys | One flow can read or change everything | CD-SEC-03 Authorization Misuse |
| 3 | Orphaned flows and zombie connections | Live access nobody owns or reviews | CD-SEC-09 Asset Management Failures |
| 4 | Uncontrolled data movement between apps | Regulated data in unmanaged services | CD-SEC-04 Sensitive Data Leakage |
| 5 | Secrets pasted into steps, variables and logs | Credentials exposed to anyone who can view runs | CD-SEC-04, CD-SEC-05 |
| 6 | Unauthenticated webhooks and public triggers | Outsiders start flows and inject data | CD-SEC-05 Authentication Failures |
| 7 | Untrusted input reaching code and AI steps | Injection, prompt injection, unintended actions | CD-SEC-08 Injection Handling Failures |
| 8 | Unvetted templates, community nodes and connectors | Malicious or vulnerable components in production | CD-SEC-01 Blind Trust, CD-SEC-06 |
| 9 | Unpatched, exposed self-hosted instances | Server takeover and theft of every stored credential | CD-SEC-07 Security Misconfiguration |
| 10 | No logging or monitoring of flow activity | Abuse and leaks go unnoticed | CD-SEC-10 Logging and Monitoring Failures |
The ranking is our judgement of how often each risk turns into a real incident and how much access it exposes. Items 1 to 3 are identity problems and are the first fixes for most organisations.
1. Flows running on personal connections
The risk: a builder connects the flow to Salesforce, Microsoft 365 or a database with their own account, then shares the flow or the app in front of it with colleagues.
Why it matters: OWASP describes how citizen-built applications embed personal credentials or shared accounts so that monitoring sees every action as the creator, which lets any user of the app impersonate the creator and opens a path to privilege escalation. When the creator leaves, the flow either breaks or keeps running on an account that should have been disabled.
How to check: export the platform's list of connections with their owning identity, and match owners against your HR leaver list and your privileged account list.
How to fix: for shared or business-critical flows, use dedicated service or integration accounts owned by a team, with behaviour monitoring on those accounts as OWASP recommends. Where the flow should act as each user, use per-user OAuth consent instead of one stored connection. See Power Automate connections security and the OWASP NHI Top 10 NHI10 Human Use of NHI Guide.
2. Over-scoped OAuth grants and admin API keys
The risk: to avoid permission errors, builders grant "read and write all data" scopes or paste an administrator API key, when the flow only needs to read one object.
Why it matters: OWASP CD-SEC-03 gives exactly this example: an app granted full CRM access when it needed sales reports, with its refresh token stored on the platform. Whoever compromises the platform account, the flow or the token inherits all of that access. In the Salesloft Drift breach, OAuth tokens held by one integration opened hundreds of Salesforce tenants.
How to check: list the scopes behind each connection in the identity provider (enterprise applications and OAuth grants) and in each SaaS admin console; flag admin and "all data" scopes.
How to fix: restrict which users can consent to third-party apps, require admin approval for high-privilege scopes, and give integration accounts only the objects they need. Re-authenticate connections periodically, as OWASP advises. See the Consent Phishing and Illicit OAuth Grants Guide.
3. Orphaned flows and zombie connections
The risk: flows built for a project, a trial or one person's job keep running after the need has gone, and connections remain valid after the flows that used them are deleted.
Why it matters: OWASP CD-SEC-09 describes orphaned applications outside IT's monitoring and patching that an attacker can exploit, using their established but unreviewed permissions to reach connected services. CD-SEC-03 calls the long-lived, forgotten tokens "zombie" connections.
How to check: report flows with no successful run in 90 days, flows whose owner is disabled, and connections not used by any active flow.
How to fix: require a named owning team for every production flow, run quarterly attestation, and delete unused connections (which also revokes their tokens on most platforms). Add workflow platforms to joiner, mover and leaver processes. See NHI lifecycle automation.
4. Uncontrolled data movement between apps
The risk: a flow copies data from a governed business system into a personal mailbox, a public chat channel, a spreadsheet shared outside the company or an unvetted SaaS tool.
Why it matters: OWASP CD-SEC-04 notes that most citizen development tools cannot classify or track sensitive data through an application, and that undocumented connections create fragile dependencies where one schema change cascades across processes.
How to check: map which connectors appear together in the same flow; any flow that pairs a system holding personal or financial data with a consumer or unapproved service is a candidate leak.
How to fix: use the platform's connector controls. In Microsoft Power Platform, data policies sort connectors into Business, Non-Business and Blocked groups; connectors in different groups cannot be used together in one app or flow, new policies place every connector in Non-Business by default, and blocked connectors fail at design time and at runtime. Other platforms offer app allow-lists and per-environment restrictions: limit connectors to an approved list and restrict custom connector creation to named staff, as OWASP recommends.
| Control | What it stops | Trade-off |
|---|---|---|
| Connector allow-list per environment | Flows to unapproved services | Requests to add connectors need a fast path |
| Business and non-business separation | Mixing corporate and personal services in one flow | HTTP and generic connectors need careful grouping |
| Separate environments for personal productivity and production | Experiments touching production data | More environments to administer |
| Restricted custom connectors and HTTP steps | Calls to arbitrary external endpoints | Slows developers integrating new APIs |
5. Secrets pasted into steps, variables and logs
The risk: API keys and connection strings typed directly into HTTP steps, code steps or environment variables, and run histories that record full request and response bodies.
Why it matters: anyone who can view, copy or export the flow, or read its run history, can collect the secret. OWASP CD-SEC-04 describes a connection string encrypted at runtime but exposed when the app is exported, and a webhook listener that logged a partner's client secret.
How to check: run secret scanning against exported flow definitions and templates; review who can see run history for flows that handle credentials.
How to fix: keep secrets in the platform's credential store or an external secrets manager, never in step fields; mask sensitive inputs and outputs in run history where the platform supports it; restrict export rights. See the Secrets Management Guide.
6. Unauthenticated webhooks and public triggers
The risk: flows started by a webhook URL that anyone who knows it can call, with no signature check, token or source restriction.
Why it matters: the URL is the only secret, and it ends up in browser histories, tickets and partner configurations. Anyone holding it can trigger the flow with data of their choosing, including data that later reaches code or AI steps (item 7).
How to check: list every flow with an HTTP or webhook trigger and whether it validates a signature, header token or source.
How to fix: verify the sender's HMAC signature where the source supports it, require an authentication header, rotate webhook URLs that have been shared widely, and validate payloads against an expected schema before acting on them. See the Webhook Secrets Security Guide.
7. Untrusted input reaching code and AI steps
The risk: email bodies, form fields, ticket text and API responses passed straight into code steps, database queries, shell commands or language model prompts that can take actions.
Why it matters: OWASP CD-SEC-01 gives the case of generated code that trusts third-party API responses without validation. With AI steps, text in an inbound email can carry instructions that the model follows, the risk OWASP lists as LLM01:2025 Prompt Injection, and an AI step with broad connections turns that into actions.
How to check: find flows where an external trigger feeds a code step, a query or an AI step that can send, write or delete.
How to fix: validate and constrain inputs; use parameterised queries; give AI steps read-only connections or require human approval before they act; separate flows that read untrusted content from flows that hold write access. See the OWASP LLM Top 10 LLM01 Prompt Injection Guide and the Low-Code Agent Platforms Guide.
8. Unvetted templates, community nodes and connectors
The risk: builders import marketplace templates, community-built nodes or custom connectors because they look professional and are highly rated.
Why it matters: OWASP CD-SEC-01 describes a marketplace login template carrying a hidden malicious script, and a highly rated component hiding a crypto-miner. On self-hosted platforms a community node is code running on the server with access to every stored credential.
How to check: list installed community nodes and custom connectors, and flows created from external templates.
How to fix: keep an approved component library, restrict community node installation to administrators, review custom connectors before publication, and pin versions. See the Low-Code and No-Code Application Security Guide.
9. Unpatched, exposed self-hosted instances
The risk: a self-hosted automation server published to the internet for webhooks, running an old version, with the editor exposed and default or weak administrator access.
Why it matters: these servers store credentials for many systems. CISA's KEV catalogue lists CVE-2025-68613, an n8n flaw in workflow expression evaluation allowing remote code execution (added 11 March 2026), and several Langflow vulnerabilities, including CVE-2025-3248, a missing authentication flaw added in May 2025, which attackers exploited to dump server environment variables, where API keys and connection strings often live (see the Langflow CVE-2025-3248 exploitation).
How to check: scan your external attack surface for automation editors and APIs; compare versions with vendor advisories and the KEV catalogue.
How to fix: keep the editor off the internet (expose only webhook paths through a reverse proxy), require SSO and MFA for the editor, patch within KEV timelines, protect the instance's credential encryption key, and run the service with least privilege. See the n8n Security Guide and the Flowise and Langflow Security Guide.
10. No logging or monitoring of flow activity
The risk: platform audit logs are not collected, connection use is not attributed, and nobody reviews flows that start moving unusual volumes of data.
Why it matters: without logs, items 1 to 9 are invisible until damage is done. Activity performed through a shared connection appears as the connection owner in downstream systems.
How to check: confirm platform audit events (flow created, connection created, sharing changed, run failures) reach your SIEM, and that downstream SaaS logs identify integration accounts.
How to fix: forward platform audit logs centrally, tag integration accounts so downstream logs can be attributed, and alert on the signals below.
Detection: what to alert on
| Signal | Source | Risk |
|---|---|---|
| New connection using a privileged or executive account | Platform audit log, IdP sign-in logs | 1, 2 |
| OAuth grant with admin or "all data" scopes to an automation app | IdP and SaaS consent logs | 2 |
| Flows owned by disabled users still running | Platform inventory joined to HR data | 3 |
| New flow pairing a regulated data source with an external service | Platform inventory, data policy violations | 4 |
| Secrets detected in exported flow definitions | Secret scanning | 5 |
| Spike in webhook calls or runs from new sources | Platform run logs, reverse proxy logs | 6, 7 |
| Community node installed or custom connector published | Platform audit log | 8 |
| Self-hosted version listed in a KEV entry | Asset inventory against KEV | 9 |
Metrics that show progress: percentage of production flows with a named owning team; percentage of connections on integration accounts rather than personal accounts; number of connections with admin scopes; orphaned flows found per quarter; median days to patch self-hosted instances after a KEV listing; percentage of webhook triggers with sender verification.
Common failure patterns
- Banning the platform instead of governing it: builders move to personal accounts on the same tools, outside any tenant control.
- Treating integration accounts as exempt: service accounts for flows excluded from MFA, Conditional Access and access reviews, so they become the easiest way in.
- Offboarding the person but not their flows: disabling a leaver's account breaks critical flows, so the account is quietly re-enabled.
- Data policies applied to one environment only: the default environment, where most personal flows live, stays open.
- Exposing the whole self-hosted instance for one webhook: the editor and API become reachable from the internet with it.
Mapping to frameworks
| Framework | Reference | Items |
|---|---|---|
| OWASP Citizen Development Top 10 | CD-SEC-01 to CD-SEC-10 | All (see the table above) |
| OWASP Top 10 for LLM Applications 2025 | LLM01 Prompt Injection; LLM06 Excessive Agency | 7 |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege; AC-2 Account Management; CM-8 System Component Inventory; IA-5 Authenticator Management; SI-2 Flaw Remediation; AU-6 Audit Record Review | 2; 1, 3; 3; 5; 9; 10 |
| NIST CSF 2.0 | PR.AA-05 access permissions defined, managed, enforced and reviewed; ID.AM-08 lifecycle management; DE.CM-03 personnel activity and technology usage monitored | 1, 2; 3; 10 |
Where to start
- Week 1 to 2: export every flow and connection from each platform; identify owners, flag leavers, and list connections on privileged accounts.
- Week 2 to 4: patch and lock down any self-hosted instance; take editors off the internet; check versions against KEV.
- Month 2: move business-critical flows to team-owned integration accounts with least-privilege scopes; restrict user consent for high-privilege scopes.
- Month 2 to 3: apply connector policies to every environment, including the default; restrict custom connectors and community nodes.
- Ongoing: forward audit logs, run quarterly owner attestation, and add workflow platforms to leaver and access review processes.
Practitioner checklist
- Inventory of every flow and connection, with an owning team for each production flow.
- Shared and critical flows run on team-owned integration accounts, not personal connections.
- OAuth scopes and API keys limited to what each flow needs; admin approval for high-privilege consent.
- Unused flows and connections removed quarterly; leavers' flows reassigned before accounts are disabled.
- Connector allow-lists or data policies on every environment, including the default.
- No secrets in step fields; run history masked or restricted where flows handle credentials.
- Webhook triggers verify the sender and validate payloads.
- AI and code steps fed by external input have read-only access or human approval.
- Self-hosted instances patched against KEV entries, editor behind SSO and not internet-facing.
- Platform audit logs in the SIEM with alerts on new privileged connections and data policy violations.
Standards and references
- OWASP: Citizen Development Top 10 (formerly Low-Code/No-Code Top 10)
- OWASP: Top 10 for LLM Applications 2025
- CISA: Known Exploited Vulnerabilities Catalog
- Microsoft Learn: Power Platform data policies
- Microsoft Learn: Connector classification
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: How to audit Zapier, Make and n8n connections and credentials · Low-Code and No-Code Application Security Guide · Workato Security · Zapier AI Security Guide · Top 10 NHI Risks