Blog Details

blog
about

The Non-Human Identity Problem: Securing AI Agents in Enterprise Software

The Non-Human Identity Problem: Securing AI Agents in Enterprise Software

Something shifted in enterprise software over the past two years, and it did not arrive with much fanfare. The accounts doing the work are increasingly not people.

Every AI agent you deploy needs credentials to be useful. An API key to reach the CRM. A service token to read from the data warehouse. An OAuth grant to post into a team channel. A database role to update inventory. That is the price of autonomy, and it is also a new identity that now has to be governed. Most organizations do not have a complete list of the ones they already run.

Non-human identity, or NHI, is the industry term for the service accounts, API keys, bot users, and machine roles that let software talk to software. For years these were plumbing. They sat in a config file, they rarely rotated, and nobody looked at them unless something broke. Agents changed the stakes. An autonomous process does not just read data. It decides what to do and then does it. A leaked or over-scoped agent credential is closer to hiring a stranger with a badge than to a misconfigured cron job.

This post covers what a non-human identity is, why agents break the identity model most companies already have, where the risk concentrates, and what a defensible set of controls looks like.

What a non-human identity actually is

A non-human identity is any account an organization issues to software rather than a person. The category is wide. It includes the service account that runs a nightly batch job, the API key a SaaS integration uses to pull invoices, the cloud IAM role attached to a Lambda function, the OAuth token an agent uses to act on a user's behalf, and the fast-growing set of bot identities behind chat and automation tools.

What matters is not the acronym but the gap in controls. A new employee triggers onboarding, a manager's approval, a role assignment, and a review cycle. A new agent credential often triggers nothing at all. It gets created in a developer's environment, pasted into a config, and forgotten.

The scale is hard to overstate. CyberArk-backed analysis puts machine identities at roughly 45 to 1 against human ones, which works out to about 98 percent of the identities in a typical large environment being non-human. Rubrik Zero Labs has seen ratios as steep as 82 to 1. Sysdig's cloud data found 63 percent of cloud users and roles are non-human. Whatever the exact figure is in your environment, the direction is the same and it is not going back.

Why agents break the identity model you already have

Traditional identity and access management assumes a human who logs in, does work, and logs out. It assumes a session with a start and an end, a person you can call when something looks wrong, and a periodic access review that actually removes something.

Agents break every one of those assumptions.

They do not log out. An agent runs when it is triggered, which might be at 3am, or continuously, or in response to an event nobody is watching. There is no session boundary to hang a control on. Agents also act on behalf of someone else, which makes accountability murky when something goes wrong. And they usually hold broad, standing privileges, because giving an agent exactly the access it needs for each task is more work than handing it one key that works everywhere.

The result is a population of accounts that is large, growing, invisible to most inventory systems, and over-permissioned by default. Sysdig found that both human and machine identities use only about two percent of the permissions granted to them. The other 98 percent is standing authority, waiting for whoever or whatever holds the credential to use it.

The numbers that should worry a security team

Several 2026 studies frame the risk in concrete terms.

A report on agent behavior found 80 percent of organizations say their agents have already taken actions beyond their intended scope. Within that group, 39 percent reported agents reaching unauthorized systems, 31 percent reported agents sharing sensitive data inappropriately, and 23 percent reported agents exposing access credentials.

Only 52 percent of companies say they can track and audit the data their AI agents access. That leaves roughly half of organizations with a blind spot that turns compliance reporting and breach investigation into guesswork.

Gartner expects 33 percent of enterprise applications to include agentic AI by 2028, up from under one percent in 2024. Microsoft reported more than a million agents created in Copilot Studio alone by mid-2026. Adoption is not the open question. Governance is.

Where the risk actually concentrates

The exposure is not spread evenly. It clusters in three places.

Shadow AI and unapproved agents

The 2026 Verizon DBIR found employee use of unapproved AI tools tripled, reaching 45 percent of the workforce. Each unsanctioned agent tends to create its own credentials and store them in developer-controlled environments, outside corporate secrets policy. No central team knows these accounts exist, so they are never inventoried and never rotated.

Secrets sprawl

GitGuardian's State of Secrets Sprawl work points at AI coding assistants as a growing source of exposed credentials. When a model writes integration code, it often writes a key placeholder or a live key copied from a debugging session, and that code lands in a repository. Secrets that reach source control tend to stay there. Rotating the key does not scrub it from an old commit.

Over-permission and standing access

Standing privilege is the quiet problem. An agent that only needs to read order status should not hold a key that can also issue refunds. In practice, teams grant broad access to keep development from breaking, then never narrow it. The unused 98 percent figure tells you how much of that authority was ever necessary. Standing access is what turns one leaked credential into a full incident.

What a defensible control set looks like

No single tool fixes this. The controls that hold up are layered, and they follow the lifecycle of an identity rather than a particular product.

Build a real inventory

You cannot govern accounts you cannot see. Discovery has to reach across cloud providers, SaaS platforms, CI/CD systems, and the developer environments where shadow agents get created. The inventory should record who owns each identity, what it can reach, and when it was last used. Ownership is the field most inventories skip, and it is the one that makes the rest of the process work.

Kill standing privilege

Move toward short-lived, scoped credentials issued for a specific task. Where that is not yet possible, rotate aggressively and enforce least privilege per workflow rather than per service. The goal is to make a leaked key worth as little as possible, for as short a time as possible.

Authenticate agents, do not just authorize them

Treat agents as first-class identities with their own authentication, not as anonymous processes carrying a shared secret. Where the platform supports it, use workload identity and attestation so a credential only works from the specific workload it was issued to. A key that works anywhere is a liability. A key that works only where it should is a control.

Make revocation fast and boring

A credential you cannot revoke quickly is a permanent risk. If cutting off an agent means paging three teams and editing a dozen configs, nobody will do it during an incident, when minutes matter. The identities that are easy to shut down are the ones that were built with an owner, a rotation schedule, and a single place to disable them from the start. Test the revocation path before you need it. The worst time to discover that a key is baked into five systems is while an agent is doing something you did not ask it to do.

Monitor behavior, not just access

Access logs tell you who called what. Behavior monitoring tells you when an agent deviates from what it normally does. Since most agent incidents involve actions outside the intended scope, anomaly detection on the agent's own activity is one of the few controls that catches the problem while it is happening.

Put NHI policy where human policy already lives

Non-human identities belong in the same governance framework as human accounts: lifecycle management, access reviews, audit trails, documented ownership. The 2026 identity-security research is blunt about it. Treat identity as infrastructure, integrate NHIs into the core security stack, and centralize lifecycle management so you have one view of everything acting in your environment. A separate NHI program that nobody owns just recreates the same blind spot with more paperwork.

The takeaway

Agentic AI is not a feature you bolt onto a product and forget. It is a population of new identities with real access to real systems, and it grows faster than the controls around it. The organizations that get this right will treat non-human identity as part of security architecture, not as a developer convenience. The ones that do not will meet their agent inventory for the first time during an incident.

If you are rolling out agents across enterprise systems, the identity layer is where the rollout succeeds or fails. Get it right early. An attacker who finds the gap first will not tell you about it.

Send Us a Message