Non-Human Identity Sprawl: The Security Debt Hiding in Your Automation Stack

The account nobody remembers creating

When you connect an automation to a tool, you authorise it once and then forget about it. That authorisation does not expire the way a customer session does. It sits in the platform's credential store as a non-human identity (NHI) — the industry's term for any secret that software uses to act on its own behalf rather than a person typing a password. Security teams have tracked service accounts and API keys for years, but the automation boom has pushed the count into new territory. According to machine-identity data compiled in 2026, machine identities now outnumber human identities by roughly 109 to 1 in the average enterprise, up from 82 to 1 a year earlier, and the ratio climbs to 144 to 1 in cloud-heavy environments.

Small and mid-sized businesses rarely think of themselves as running a fleet of machine identities. They think they run "a few zaps and a couple of n8n workflows." But the two descriptions are the same thing. Each connection is a standing credential with real reach, running on a schedule, with no human watching the individual runs. The person who built it may have moved teams or left the company entirely, and the credential keeps working exactly as before. High privilege, long life, and no clear owner: that is the profile of a risk, and most organisations cannot even produce a list of which automations hold which keys.

Why 2026 is the tipping point

Three trends collided this year. Automation adoption accelerated, AI agents multiplied the number of credentials in play, and attackers noticed that a stolen key is quieter and more durable than a stolen password. The numbers tell the story better than any narrative.

The AI-service figure is the one to sit with. GitGuardian reports that credentials tied to AI services grew 81% year over year — the fastest-growing category it tracks — precisely because every new agent, model integration and AI-powered workflow needs its own key. The more you lean into agentic automation, the more machine identities you create, and the faster your exposure grows if you are not managing them deliberately. This is the operational cost that sits underneath the excitement covered in our guide to what agentic automation actually is: more autonomy means more credentials, and more credentials means more to govern.

How the sprawl actually happens

No one decides to build an ungoverned credential fleet. It grows one convenient shortcut at a time, and every step feels reasonable in isolation. A typical progression looks like this:

1. A founder connects a lead form to the CRM with a personal API key, because it is faster than setting up a proper service account.
2. A marketer adds three more automations that reuse the same key, because it already works and copying it is easy.
3. An operations hire spins up an n8n instance to handle invoices, storing bank and accounting credentials directly in the workflow fields.
4. Someone experiments with an AI agent that needs read access to "just about everything" to be useful, and gets it.
5. The original founder leaves. Their key still authenticates every automation built on top of it, and no one knows.

Every one of those credentials outlives the context it was created in. This is why the problem is invisible until it is not: nothing breaks, nothing alerts, and the automations keep delivering value right up to the moment one key is exposed and grants an attacker a tour of your entire stack. The failure is not a bug in any single workflow — it is the absence of a system that treats those workflows as identities with a lifecycle.

What goes wrong when nobody owns the fleet

Self-hosted automation makes the stakes vivid. In March 2026, security researchers disclosed critical vulnerabilities in n8n that allowed an authenticated user to achieve remote code execution, read the platform's master encryption key, and decrypt every stored credential — AWS keys, database passwords, OAuth tokens, the lot. As of early February 2026, monitoring by the Shadowserver Foundation counted more than 24,700 unpatched n8n instances still exposed on the public internet. Self-hosting is a legitimate choice, but it makes you the security team, and a single unpatched instance can hand over the keys to everything it touches.

It would be a mistake to read that as an n8n problem. Hosted platforms such as Zapier, Make and Power Automate hold your OAuth tokens and API keys just the same; you have simply outsourced the patching. The real issue is the sprawl of live credentials across every platform at once, and how differently a managed fleet behaves from an unmanaged one when something goes wrong.

The shadow-AI multiplier

The identity problem gets worse when automations are created outside anyone's oversight. Shadow AI — the use of AI tools and agents that IT has not approved or does not know about — has become a governance headache that analysts raised prominently at Gartner's 2026 security and risk conferences. Surveys this year put unapproved AI-tool usage at between 40% and 65% of employees, with roughly 47% of AI users reaching those tools through unmanaged personal accounts that bypass corporate controls entirely. Yet only about 37% of organisations have any policy in place to detect shadow AI at all, and 82% of CIOs report that employees are creating AI agents and apps faster than IT can govern them.

Each of those unsanctioned agents is a non-human identity that can call tools, read data and trigger workflows with nobody accountable for it. That is why the sharper framing gaining ground in 2026 is that shadow AI is a machine-identity problem before it is a policy problem. If you are evaluating tools to buy rather than build, the same discipline applies to your vendors — a theme we develop in how to buy automation without creating shadow AI. The question is not only "does this tool work" but "what identity does it become inside my stack, and who owns it."

A governance playbook you can actually run

You do not need an enterprise identity program to bring this under control. You need a handful of habits applied consistently. Here is a sequence that a small team can adopt without hiring anyone.

1. Inventory first. List every automation, the platform it runs on, the credentials it holds, the systems those credentials reach, and a named human owner. This single spreadsheet is the foundation for everything else; most teams find forgotten connections and orphaned accounts the first time they do it.
2. Scope to least privilege. Replace broad master keys with narrow, revocable tokens that grant only what a given workflow needs. An agent that reads support tickets does not need write access to your billing system.
3. Vault the secrets. Store credentials in a dedicated secrets manager rather than pasting them into workflow fields. This is the fix the n8n community itself pushed after the March disclosures, and it applies to every platform.
4. Rotate on a schedule and on events. Cycle high-privilege keys every 60 to 90 days, and immediately whenever an owner leaves or a platform discloses a breach. Scoped tokens make rotation painless because one change does not break everything.
5. Scan for leaks. Run secret scanning against your repositories and shared documents so an exposed key is caught by you before it is caught by an attacker.
6. Assign an owner to every automation. An automation with no owner is an automation no one will rotate, review or retire. Ownership is what turns a static inventory into a living one.
7. Offboard automations like you offboard people. When a workflow is retired or a person leaves, revoke the associated credentials the same day. Decommissioning is the step everyone skips, and it is where sprawl comes from.

What this means for buyers and builders

For businesses buying automation, identity governance is now a purchasing criterion, not an afterthought. Ask a prospective vendor or freelancer how credentials are stored, whether tokens are scoped, how rotation works, and what happens to access when the engagement ends. A serious provider will have answers; the ones who improvise are the ones who will leave you with orphaned keys. This is also a close cousin of the portability question we cover in how to avoid automation vendor lock-in, because credentials you cannot inventory are credentials you cannot cleanly migrate or revoke.

For the people building and selling automations, identity hygiene has quietly become a differentiator. Delivering a workflow with scoped tokens, vaulted secrets, a documented credential list and a clear owner is a mark of a professional, and it is increasingly what buyers who have been burned once will insist on. The broader defensive posture — from prompt-level attacks to credential handling — is worth understanding end to end, which is why it pairs naturally with our deeper look at prompt injection and automation security. The market is maturing from "can you make it work" to "can you make it safe," and that shift rewards the builders who treat every connection as an identity with a lifecycle.

The takeaway

The point is not to be afraid of automation. Automation is still the highest-leverage investment most small businesses can make, and the companies pulling ahead are automating more, not less. The point is that scaling automation and scaling machine identities are the same act, and only one of them tends to get managed. The fix is cheap relative to the risk: an inventory, least-privilege scoping, a vault, a rotation habit, and an owner for every workflow. Do that, and you can keep connecting tools with confidence instead of quietly building a pile of accounts nobody remembers creating — the exact pile that, in 2026, attackers have learned to look for first.

FAQ

What is a non-human identity in plain terms?

It is any credential software uses to log in on its own — an API key, OAuth token, service account or webhook secret. Every automation you connect creates at least one, and it keeps authenticating long after you have forgotten about it.

Why should a small business care about machine identities?

Because you already have them. A dozen zaps and a couple of n8n workflows is a dozen-plus standing credentials with real reach into your systems. Machine identities outnumber human ones roughly 109 to 1, and most of them nobody is watching.

How bad is the secrets exposure problem right now?

GitGuardian counted 28.65 million new hardcoded secrets in public GitHub commits in 2025, up 34% year over year, with AI-service secrets up 81%. SpyCloud recaptured 18.1 million exposed API keys and tokens from criminal sources over the same period.

Is self-hosted automation less safe than hosted tools?

It shifts the responsibility. Critical n8n flaws in March 2026 could decrypt every stored credential, and over 24,700 instances stayed unpatched and exposed. Hosted tools hold the same secrets but patch for you; the sprawl of credentials is the shared risk.

What is the single most useful first step?

Write an inventory: every automation, its platform, the credentials it holds, the systems it reaches, and a named owner. You cannot rotate or revoke what you have never listed, and the exercise almost always uncovers forgotten connections.

How often should I rotate automation credentials?

Rotate high-privilege keys every 60 to 90 days, and immediately when an owner leaves or a platform discloses a breach. Use scoped, revocable tokens so one rotation does not take everything else down with it.

How does shadow AI fit into this?

Shadow AI tools are agents nobody approved, each holding credentials nobody governs. With 40% to 65% of employees using unapproved tools and only 37% of organisations able to detect them, shadow AI is a machine-identity problem before it is a policy one.

Does managing this slow down building automations?

Barely. A shared inventory, scoped tokens, a secrets vault and a rotation habit add minutes per workflow and let you keep scaling without accumulating invisible risk. The cost is trivial next to a single leaked key.