Non-Human Identities Need Containment, Not Just Rotation

Most Zero Trust programs still talk about identity as if the identity is a person.

That is no longer enough.

Modern environments are full of identities that do not show up in HR systems, do not sit in security awareness training, and do not leave the company when an employee changes jobs. Service accounts. API keys. OAuth apps. CI/CD tokens. Workload roles. SaaS connectors. Kubernetes service accounts. Agent runtimes. Automation jobs.

These identities run the business. They also create some of the cleanest movement paths an attacker can inherit.

The mistake is treating this as a secrets-management problem only.

Rotation matters. Vaulting matters. Short-lived credentials matter. But if a compromised non-human identity can reach too many systems, call too many APIs, or cross too many environments, the real problem is not the secret.

The real problem is blast radius.

Why This Is Getting Worse

The 2026 Verizon DBIR says 31% of breaches now start with software vulnerabilities, making exploitation the leading initial access vector in that report. It also says ransomware is involved in 48% of breaches. Mandiant’s M-Trends 2026 is based on more than 500,000 hours of incident investigations in 2025.

Different reports, same operating reality: initial access is varied, fast, and often not where the real damage happens.

The damage happens when access turns into reach.

That is where non-human identities matter. They sit between systems. They hold permissions. They authenticate quietly. They connect development to production, SaaS to cloud, workload to database, agent to tool, and automation to infrastructure.

If one of those identities is overprivileged, reused, long-lived, poorly monitored, or allowed to cross environment boundaries, it becomes a movement path.

Not a theoretical one. A working one.

OWASP Named the Right Risks

OWASP’s 2025 Top 10 for Non-Human Identities is useful because it names the failure modes practitioners already see:

improper offboarding
secret leakage
vulnerable third-party non-human identities
insecure authentication
overprivileged non-human identities
insecure cloud deployment configurations
long-lived secrets
weak environment isolation
identity reuse
human use of non-human identities

Read that list as an attacker would.

Each item is not just a credential hygiene issue. It is an authorization and reachability issue.

An overprivileged service account is dangerous because it can do too much. A long-lived secret is dangerous because it gives the attacker time. Identity reuse is dangerous because compromise in one area can open another. Weak environment isolation is dangerous because non-production can become a bridge into production.

That is exactly the terrain microsegmentation is meant to change.

Human IAM Does Not Solve Machine Reach

Most organizations have put real effort into human identity. Centralized identity providers. MFA. Conditional access. Privileged access workflows. Joiner, mover, leaver processes. Access reviews.

Good.

But non-human identities do not fit neatly into that model.

CSA’s State of Non-Human Identity Security report defines NHIs as bots, API keys, service accounts, OAuth tokens, and secrets. The same report says only 15% of organizations feel highly confident in preventing NHI attacks, while 69% express concern. It also says only 20% have formal processes for offboarding and revoking API keys.

That is the governance gap.

But the containment gap is just as important.

If a service account is compromised, what can it reach over the network?

If an OAuth app is abused, which systems accept its calls?

If a CI/CD token leaks, can it talk directly to production, secrets stores, cloud control planes, or databases?

If an agent runtime is tricked into using a connected tool, what is the maximum damage it can cause before another control stops it?

Those are microsegmentation questions as much as identity questions.

Segmentation Has to Follow the Trust Path

Classic segmentation often starts with subnets and zones.

That still has value, but it is not enough for non-human identities. Machine trust paths rarely map cleanly to one VLAN. They cross clouds, SaaS platforms, Kubernetes namespaces, pipelines, APIs, and internal services.

The segmentation model needs to follow the dependency graph:

this workload can call this API
this CI runner can push to this artifact store
this deployment identity can reach this environment, not every environment
this SaaS connector can call this business application, not the whole tenant
this agent can use this tool, not every tool exposed to the user
this service account can reach this database on this port, not adjacent databases because they sit nearby

The principle is simple: a non-human identity should have both narrow permissions and narrow reach.

Identity policy answers what the identity is allowed to do.

Microsegmentation answers where that identity can actually go.

You need both.

AI Agents Make This Urgent

AI agents are just the newest version of an old pattern: software acting with delegated authority.

The difference is speed and ambiguity.

Agents can chain tools, interpret user intent, call APIs, query internal systems, create tickets, inspect code, trigger workflows, and operate across SaaS and cloud environments. Some will be centrally managed. Some will appear through developer tooling. Some will arrive inside business platforms before security has a clean inventory.

That makes every connected tool and credential part of the agent’s blast radius.

If the agent can reach a shell, a ticketing system, a document store, a code repo, a cloud API, and a secrets workflow, the control question is not only “is the model safe?”

The better question is:

What can this runtime reach if it behaves badly, is compromised, or is tricked into using its tools in the wrong order?

Prompt controls are not a substitute for containment. Neither is a good model card. Neither is trust in the vendor.

Agentic systems need the same architectural discipline as other privileged automation:

separate runtime zones
narrow tool access
scoped credentials
explicit allowed paths
strong logging
default-deny network behavior for sensitive services
no shared broad service accounts across unrelated workflows

Treat the agent runtime like a privileged workload, because that is what it is becoming.

What Good Looks Like

This is not a call to block all automation. That would be unserious. Non-human identities are how modern systems work.

The goal is to make compromise local.

Start with the identities and paths that would hurt most if abused:

CI/CD runners and deployment identities.
Cloud workload roles and service accounts.
Kubernetes service accounts with access outside their namespace.
OAuth apps connected to high-value SaaS platforms.
Backup, monitoring, EDR, ITSM, and management-platform integrations.
AI agent runtimes and tool connectors.
Third-party integrations with standing access.

Then map what each one can reach.

Not what the diagram says. What traffic actually happens. Which API endpoints. Which ports. Which environments. Which data stores. Which control planes.

After that, enforce the minimum:

separate dev, test, staging, and production identity paths
remove non-production reach into production by default
bind deployment identities to specific pipelines and environments
isolate CI/CD from general user and developer networks
prevent service accounts from reaching unrelated application tiers
segment SaaS connectors and automation platforms from crown-jewel systems
create emergency containment policies for abused service accounts, tokens, and agent runtimes

The first useful artifact is not a rule set.

It is a map of machine trust.

Once you have that map, policy becomes a way to delete unnecessary paths.

The Bottom Line

Non-human identities are not a side issue in IAM anymore.

They are connective tissue for cloud, SaaS, automation, Kubernetes, CI/CD, and AI agents. That makes them operationally necessary and architecturally dangerous.

Secrets management reduces the chance that an identity is stolen.

Microsegmentation reduces what that identity can do after it is stolen.

That distinction matters.

Because in the breach you actually have to survive, the question will not be whether the service account had a clean naming convention.

The question will be what it could reach.

microsegment.io