Zero Trust for AI and AI Agents: How the Security Framework is Evolving
Key Takeaways
- Zero trust for AI agents extends the same "never trust, always verify" principle that governs human identities, but the framework has had to evolve because identity verification alone can't constrain what an agent does once it's authenticated. An agent can pass every identity check and still cause harm through ordinary operation.
- The access model built for human users doesn't transfer cleanly to non-human identities. AI agents are the fastest-growing category of machine identity in most enterprise environments, and every one of them inherits the permissions of whatever role they run under.
- Zero trust for AI agents only holds up if it's enforced architecturally. Zones, boundaries, and baselines built into the cloud's native controls, not policies that sit beside the environment and hope the agent behaves.
How Zero Trust Got Here
Zero trust developed as a response to a specific failure: the assumption that network location meant trust. If a request came from inside the perimeter, it was treated as legitimate. If it came from outside, it was suspect.
That assumption stopped working when cloud environments arrived and the network perimeter stopped functioning as a reliable boundary. As explored in Native's architecture of zones, boundaries, and baselines, what changed wasn't the goal of security, but the environment that goal had to be expressed through. The perimeter didn't disappear. It expanded across network paths, identities, resources, and service-level relationships.
The framework that replaced network-centric security was well-suited to that shift: stop assuming location means safety, verify every request, and build controls around who is asking rather than where they're asking from. That model reoriented access controls around identity, and it's served cloud security well.
The same basic pressure is now being applied from a different direction. AI agents don't sit at keyboards. They call APIs, query data stores, trigger deployments, and chain actions together at machine speed, often without a human reviewing each individual decision. They can authenticate correctly, hold valid credentials, and pass every check the current model runs, and still cause harm through ordinary operation, not because something went wrong but because the architecture never defined what was off-limits in the first place.
That's the shift happening now in zero trust for AI agents: from verifying who is asking, to constraining what can happen regardless of who, or what, is asking.
How the Framework Has Moved
The model has shifted through distinct stages, and it helps to see them as stages rather than one continuous idea, because each stage was a genuine response to a genuine change in the environment.
Stage one was the perimeter. Trust was determined by location. If a request came from inside the network, it was treated as safe. The assumption held as long as the network had a meaningful edge, and for a long time, it did. That model broke when the cloud made the edge impossible to define. There was no longer one boundary to sit behind, so sitting behind it stopped being a signal of trustworthiness.
Stage two was identity and device. This is zero trust as most security teams know it today: never trust by default, verify every request, and base that verification on who the user is, whether their device meets posture requirements, and whether their access matches their role. It was the right response to what broke in stage one. It works because human behavior is reasonably bounded. A finance analyst logs in from roughly the same places, uses roughly the same tools, and performs a predictable range of actions. Verifying identity is a good proxy for verifying intent, so making identity the boundary made sense.
Stage three is what's happening now, driven by what's changed about the actors in the environment. An agent that holds valid credentials can chain a task in a direction nobody anticipated, reach a system adjacent to the one it actually needed, or decide that removing a restriction is the fastest way to finish what it was asked to do. Authentication works exactly as intended here. What fails is the assumption that authentication is enough.
The actual evolution is this: trust moves from being a property of the requester to being a property of the action space itself. Instead of asking "is this identity allowed to make this request," the question becomes "is this action possible at all, regardless of which identity is asking." That's a structural change. It's why agent security can't be solved by adding more identity checks on top of the stage-two model. The boundary has to be enforced on what can happen, through zones that define which agents operate where, governed crossings that specify which interactions are approved, and baselines that hold no matter what the agent decides to try.
The Gap Authentication Can't Close
The scale of the gap is measurable. According to Gravitee's 2026 State of AI Agent Security report, only 47.1% of deployed AI agents are actively monitored or secured. A separate Cloud Security Alliance and Aembit study found that 68% of organizations can't clearly distinguish human activity from agent activity in their own logs. These aren't configuration failures. They're symptoms of applying a human-centric security model to actors that don't behave like humans.
Machine identities already outnumber human identities by a significant margin in most enterprise environments, with some microservice-heavy stacks running ratios in the range of 500 machine identities to every one human. Every agent in that population inherits the permissions of whatever identity it runs under, which means a single overly broad role can hand an agent far more reach than its actual task requires.
An agent's identity tells you almost nothing about what it might do next. Unlike a human user with predictable habits and a fixed set of job functions, an agent reasons through a task and decides its own sequence of actions. It can call a tool it's never called before, reach a system that happens to be adjacent to the one it was supposed to touch, or remove a restriction it sees as an obstacle. None of that requires a compromised credential. The agent can be working exactly as designed and still cross a line nobody drew.
Zero Trust for AI Agents vs. Traditional Zero Trust
The difference between stage two and stage three is operational. You can see it when you set the two side by side.
The shift in the right column is the whole point. Guardrails for agents can't live inside the agent, because the agent's own reasoning is what you're trying to constrain. The architecture has to define what's possible from the outside.
What Zero Trust for AI Agents Requires
Applying stage three zero trust to agents means answering the same questions security teams have always asked, applied to a new kind of actor: which zone does this agent operate in, which crossings are approved, and what baseline governs its behavior inside that zone?
Scope the agent to a zone, not the whole environment. An agent built to summarize support tickets has no architectural reason to reach a production database. Zero trust for AI agents means the agent's reach is defined by the zone it's assigned to, not by whatever the underlying service account happens to be able to touch.
Treat every crossing as a decision, not a default. If an agent needs to call a model endpoint, touch a data store, or trigger a deployment, that's a boundary crossing, and it should be governed the same way any other boundary crossing is governed: with explicit, enforced rules about what's allowed to cross and under what conditions. The zones, boundaries, and baselines framework that structures cloud security architecture generally applies here directly.
Enforce a baseline that holds regardless of what the agent decides to do. A baseline that says an agent can read but cannot delete, overwrite, or exfiltrate without approval doesn't depend on the agent behaving consistently. It holds because the architecture doesn't permit the alternative. This is the same logic behind cloud security guardrails: the unsafe outcome can't happen because the architecture doesn't allow it, not because someone caught it in time.
Build it before the agent runs, not after it's already load-bearing. Engineers move fast. They wire up integrations that work, and nobody is being careless. But the pattern that keeps appearing across organizations adopting agents quickly is an environment full of agents already running, already crossing zone lines, with nobody having defined whether those crossings should be allowed. Every integration that works without defined constraints becomes a legacy actor. Fixing it after the fact is significantly harder than architecting for it from the start.
The Architecture Has to Keep Up With the Actors
Zero trust for AI agents is the same discipline security teams have always practiced, now applied to an actor that moves faster and reasons for itself, rather than a separate security layer bolted onto the environment. The organizations that are ahead of this are the ones that recognized the framework needed to evolve before their agent architecture became too entrenched to re-examine.
The building blocks are already there. Cloud providers ship the controls needed to enforce zones, govern crossings, and hold baselines at the architecture level. The challenge is translating a unified security intent into each provider's policy engine, modeling the impact before anything goes live, and keeping the architecture current as the environment keeps changing.
That's the layer Native is built around. Native turns the built-in controls already present in AWS, Azure, Google Cloud, and OCI into active, enforced defenses around how agents operate, simulated against your real environment before deployment so guardrails don't become operational risk. If your organization is deploying agents and hasn't yet defined the zones they operate in or the baselines that govern them, that's the place to start.