Back to Resources

Zero Trust Wasn’t Built for This: Securing the Rise of Non-Human Identities

31 August 2026

Key Takeaways

  • Zero Trust and SASE were built to secure a distributed human workforce. That problem is largely solved. The current gap is different: most architectures were never built to recognise, verify or constrain AI agents.
  • Non-human identities, service accounts, API keys and agent credentials already outnumber human identities in many enterprise environments, and the ratio is climbing as agentic AI moves from pilot to production.
  • Zero Trust’s founding principle, never trust, always verify, still holds. What has changed is who needs verifying.
  • Verifying and securing a fast-moving population of autonomous entities only works if the underlying network can deliver low-latency, policy-enforced access at the edge, not just at the data centre.
  • Extending Zero Trust to agents means short-lived, task-scoped credentials, least-privilege by default, and continuous verification rather than one-time authentication.

Zero Trust solved the human problem. It hasn’t solved the agent problem.

Most Zero Trust and SASE content, including a fair amount of Orro’s own material, was written for a specific world: staff working from home, branch offices, campuses, all needing secure access from wherever they happened to be. That problem is largely solved. Modern SASE architectures verify distributed human users well.

The problem in front of security and network leaders now is different. AI agents are becoming a distinct class of network user, and most Zero Trust architectures were never built to recognise them, let alone verify or constrain what they do once they’re in.

This isn’t a future planning exercise. It’s a gap that exists today, in any organisation running agentic AI in production, whether that deployment was formally sanctioned or crept in through a business unit’s pilot project.

What’s actually changing

Non-human identities, the API keys, service accounts, authentication tokens and agent credentials that let software act on an organisation’s behalf, already outnumber human identities in many enterprise environments. Fortinet’s own SASE product team has made a similar point from the platform side: as agent-based AI workflows become more common, security models need to extend beyond user-to-application interactions to cover how, why and with whom AI agents communicate with each other (Fortinet, 2026).

The scale of the shift is backed by independent forecasting. Gartner projects that by 2028, a third of enterprise software applications will include agentic AI, up from less than one per cent in 2024 (Gartner, 2025), a roughly thirty-fold increase in four years.

These entities don’t behave like human users. They act at machine speed, chain tasks across systems autonomously, and can accumulate access nobody explicitly granted them. The World Economic Forum has warned that agentic AI can create non-human identities in security blind spots that receive broad, persistent access without the safeguards typically applied to human users (World Economic Forum, 2025). Zero Trust architectures that demand continuous identification and least-privilege access have been widely adopted for people. Most implementations stop there. Automated processes routinely retain broad authorisation without expiration, attestation or accountability, which is exactly the gap Zero Trust was designed to close for human users in the first place.

Industry analysts are now saying the quiet part out loud. Gartner has noted that SASE and security service edge platforms will need to adapt to a new class of user these platforms were not originally built to secure (Gartner, cited in Fierce Network, 2026). That single line reframes the SASE conversation for 2026 and beyond: this is now a platform requirement, not an edge case.

Evidence Snapshot

Why this is a network architecture problem, not just an identity one

Identity governance alone doesn’t close this gap. An agent with a perfectly scoped, short-lived credential is still only as secure as the network path it travels. This is where the edge and latency conversation, usually treated as a separate performance topic, becomes directly relevant to the non-human identity problem.

Agents making real-time decisions, triaging a support ticket, adjusting a supply chain order, querying a database mid-transaction, need low-latency access as much as they need secure access. If policy enforcement happens only at a centralised data centre, verifying and constraining a fast-moving population of autonomous entities introduces exactly the kind of latency that defeats the purpose of using agents in the first place. Security teams end up facing a false choice between speed and control.

An edge-aware SASE architecture, one that pushes policy enforcement, inspection and identity verification closer to where agents actually operate, resolves that tension. SD-WAN and edge-native SASE design stop being purely a connectivity conversation and become part of how an organisation secures its growing population of non-human actors. Architecture decisions increasingly have to solve for both problems at once, not sequentially.

IBM’s newly released 2026 Cost of a Data Breach Report makes a similar point from the identity side, dedicating a section specifically to agentic identity security: AI agents must be secured through dynamic, identity-based access controls, tightly scoped permissions continuously enforced at runtime, and human attribution and auditability (IBM/Ponemon Institute, 2026).

What “extending Zero Trust to agents” looks like in practice

Four shifts, in prose rather than prescription, tend to separate organisations that are getting ahead of this from those that are catching up after the fact.

The first is credential lifecycle. Long-lived, broadly scoped API keys and service account credentials are a legacy pattern from a slower-moving IT environment. Agents should be issued short-lived, task-scoped credentials that expire when the task does, not standing access that outlives the job it was created for.

The second is least-privilege by default, applied with the same rigour used for human users. An agent chaining tasks across finance, HR and customer systems should never inherit the sum of every permission it might conceivably need. It should be granted exactly what the current task requires, nothing more, reissued for the next task.

The third is continuous verification rather than one-time authentication. A human user authenticating once at the start of a session is already an imperfect model; for an agent capable of taking hundreds of actions a minute, it’s an inadequate one. Verification needs to happen at the point of action, not just at the point of login.

The fourth is treating agents as first-class identities with their own lifecycle, discoverable, owned, reviewed and retired, in the same governance processes that already exist for human joiners, movers and leavers. An orphaned agent credential is at least as dangerous as an orphaned employee account, and considerably more likely to go unnoticed.

What leaders should ask this month

Few organisations have a complete inventory of every non-human identity operating across their environment, which makes visibility the natural starting point. It’s worth asking who in the organisation can currently produce a full, current list of every service account, API key and agent credential in use, and how confident anyone is that the list is complete.

It’s also worth asking how many of those credentials are long-lived by default, simply because that was the easiest way to get a project over the line, and what would need to change to make short-lived, task-scoped credentials the standard rather than the exception.

Network and security teams often plan SASE and Zero Trust investments separately from AI and automation investments. Leaders should ask whether that’s still the right split, given how directly the two now depend on each other, or whether it’s time for both roadmaps to be reviewed together.

Finally, it’s worth asking a genuinely uncomfortable question: if an AI agent’s credentials were compromised tomorrow, would anyone notice before it had finished doing damage. For most organisations, the honest answer is still no.

Where to start the conversation

None of this requires ripping out existing Zero Trust or SASE investment. It requires extending the same principle that already underpins them, never trust, always verify, to a population of identities that most architectures were never designed to see. Getting there is as much a network architecture question as an identity one: verification only works at machine speed if the underlying network can enforce policy without adding the latency that defeats the purpose of using agents at all.

If your organisation is running agentic AI in production, or is about to, this is worth a conversation with Orro’s network and SASE team before the gap gets any wider.

Sources & Further Reading