in one lineEvery Zapier, Make, or Power Automate workflow is a chain of standing OAuth grants, built by one person and running unattended.
the numbers
- 3.4Mbusinesses run automations on Zapier alone (self-reported)Zapier, 2026
- 48%of breaches involve a third partyVerizon DBIR, 2026
- 700+companies reached through one compromised OAuth integrationFINRA on the Salesloft/Drift breach, 2025
1what it is
No-code platforms, Zapier, Make, n8n, Power Automate, let anyone wire systems together: when an invoice lands in the inbox, save it to Drive and post to Slack. Zapier alone reports 3.4 million businesses on its platform, and Gartner has predicted that by 2026 at least 80% of low-code tool users will sit outside IT.
Under every workflow sits a set of connections: an OAuth grant into the mailbox, another into Drive, another into Slack. The platform holds those credentials and exercises them on schedule, indefinitely. Functionally, each automation is a small unowned service account with multi-system access, created without anyone calling it that.
2why it accumulates
Automations are built by the people closest to the tedium, which is their virtue and the governance problem in one. Marketing automates lead routing, finance automates invoice filing, ops automates everything else. Each builder grants access from their own account, scopes it broadly because the platform asks broadly, and moves on.
Then the usual decay: the builder changes teams or leaves, the workflow keeps running on their grant, and the company accumulates business processes that depend on credentials tied to people who are gone. Nobody lists automations in an asset register, so nothing ever prompts a review.
3what it costs you
The access cost first: every workflow widens the blast radius of the account that built it. Compromise the builder, inherit the chain, including the write access into systems the builder personally never touches. Third-party involvement appears in 48% of breaches (Verizon DBIR 2026), and automation platforms are third parties holding live, multi-system credentials.
The continuity cost is quieter. When the builder leaves and offboarding revokes their grants correctly, the invoice flow stops, and nobody knows why, because the process existed only in their personal workspace. Companies discover their automation inventory by breaking it.
And the data cost: automations move customer and financial data through an intermediary platform whose terms, retention, and region nobody checked, which is GDPR exposure created one Zap at a time.
what it looks like when it goes wrong
Three ways this tends to go, each one taken from a real case.
- it happenedSalesloft / Drift, 2025howA chat tool's key into your CRM is stolen from the vendor.what leavessupport tickets, including passwords pasted into themwho ends up with itan extortion group working through hundreds of companies
- it happenedGitHub OAuth tokens, 2022howIntegration keys to your code host are stolen from the integration vendor.what leavesyour private code and the secrets inside itwho ends up with itattackers looking for the next door
- it happenedSisense, 2024howAn analytics vendor is breached and the keys it holds to your systems are copied.what leavesconnections straight into your datawho ends up with itwhoever holds the vendor's keys
4what works
Discovery starts in the IdP's connected-app view, where Zapier, Make, and their peers appear with the grants and scopes they hold and the accounts that created them. That view has a boundary worth knowing: a workflow built under a personal, non-company login never touches the company directory and leaves no trace there, so the only way to surface that layer is to ask. The useful inventory question for teams is which automations they would notice breaking. That list, rather than the platform's full export of every test workflow ever made, is the real governance scope.
Shared ownership is the control that holds. A team workspace with a dedicated automation account and a named owner replaces the personal grant that walks out the door with its creator, and it addresses both failure modes at once: the security one, where a leaver's credentials keep exercising access, and the continuity one, where correct offboarding silently kills the invoice flow.
Narrow scoping does the same for blast radius. Most platforms accept tighter grants than they request by default; a workflow that files invoices needs access to one folder, never the whole Drive, and the difference determines what an attacker inherits if the builder's account is compromised.
The last piece is bringing automations into the lifecycle they currently escape: a leaver's workflows re-owned or retired the same week their other access closes, and the automation account included in the quarterly grant review like any other service account, which is what it functionally is.
on the record
your turn
what you can do about it
this week
List automations that run on a personal account, and who owns each one.
Move the important ones to a shared service account with an owner.
go deeper
if you're not sure where to start
Run the offboarding checklist on one leaver. It covers every account and token to close when someone leaves.
open the checklist →