Zero Trust won the argument. After a decade of breaches that started with a single compromised credential inside a trusted network, the security industry accepted the premise: there is no trusted interior. Every request is verified. Every identity is authenticated. Every access is checked against policy, continuously, regardless of where it originates. Never trust, always verify.

Enterprises rebuilt their security architectures around this idea. Network perimeters gave way to identity perimeters. Implicit trust based on network location was replaced with explicit verification on every request. It worked, because it matched the threat. The interior was never safe, and pretending otherwise was the root cause of a generation of breaches.

Then AI agents arrived, and enterprises quietly granted them exactly the implicit trust that Zero Trust spent a decade dismantling.

This piece argues that Zero Trust principles apply to AI agents with more force than they ever applied to humans, that current agent deployments violate every one of those principles, and that closing the gap requires extending verification to the layer Zero Trust never had to reach: the individual action.

What Zero Trust Actually Means

Zero Trust is not a product. It is a set of principles about where and how trust is established. Three of them matter most here.

Never trust based on location. The fact that a request comes from inside the network, from a known device, or from an already authenticated session is not sufficient grounds to allow it. Interior position confers no privilege. Every request earns its access on its own merits.

Always verify explicitly. Every access decision is made against real signals: identity, device posture, the sensitivity of the resource, behavioural context. Verification is not a one time event at login. It is continuous, re evaluated as conditions change.

Enforce least privilege per request. An identity is granted the minimum access required for the specific thing it is doing right now, not the maximum it might ever need. Privilege is scoped tightly and granted just in time, not provisioned broadly and left standing.

The deep insight behind all three is that trust is not a property you hold. It is a decision that gets made, fresh, at the moment of each access, based on the full context of that access. The old model treated trust as a gate you passed once. Zero Trust treats it as a question asked every single time.

Hold that definition in mind, because agents violate it completely.

Why Agents Are the Hardest Case Zero Trust Has Faced

Zero Trust was designed for two kinds of actor: human users and the devices and services they operate. Agents are neither, and the ways they differ are exactly the ways that make them dangerous.

A human user is slow, singular, and externally accountable. A person makes one decision at a time, at human speed, and there is a name attached to that person. When a human requests access to something unusual, the request stands out, and the human can be asked to justify it.

A service account is fast but deterministic. It does the same well understood things repeatedly. Its behaviour is predictable enough that anomaly detection works, because anomalies are genuinely anomalous against a stable baseline.

An agent has the speed of a service account and the open ended decision making of a human, with none of the constraints of either. It decides what to do based on model reasoning over a context window, so its action space is not fixed. It acts at machine speed across many sequential steps. It can be manipulated by the content it processes, so its decisions are influenced by data an attacker may control. And it carries no intrinsic accountability, because there is no person behind any individual action.

Read that table as a threat assessment. The agent combines the worst column from each of the others. It has the openness that makes humans hard to baseline, the speed that makes service accounts able to do damage fast, and a unique vulnerability neither shares: it can be talked into things by the data it reads. This is precisely the actor for which implicit trust is most dangerous, and precisely the actor that current deployments trust the most.

How Current Deployments Violate Every Principle

Walk the three principles against how agents are actually deployed today, and the gap is total.

Violation one: trust based on location and session. An agent is authenticated once, at the start of its run, and then trusted for everything it does for the rest of the session. The credential it holds is its passport, and once inside, it roams. This is the exact pre Zero Trust model, the trusted interior, rebuilt around the session instead of the network. The agent is inside, therefore the agent is trusted.

Violation two: no explicit verification per action. The agent's individual actions are not verified against policy at the moment they execute. Authentication happened at the door. After that, the thousand actions the agent takes inside go unchecked. There is no continuous re evaluation, no per action decision. The verification was a one time event, which is the precise thing Zero Trust rejects.

Violation three: standing privilege, not least privilege. The agent is granted broad scopes up front, the union of everything it might conceivably need across its whole task, and holds them for the duration. It does not acquire narrow privilege just in time for each action and release it after. It holds the maximum, standing, for the session. This is the opposite of least privilege per request.

Every row is a violation. The industry that rebuilt itself around never trust, always verify is deploying agents on a trust once, verify never model. The contradiction is not subtle. It is structural, and it exists because the enforcement point Zero Trust relies on does not reach where agents do their damage.

The Missing Enforcement Point

Zero Trust for humans and devices is enforced at access. When a user opens an application, reaches for a resource, or crosses a service boundary, a policy decision point intercepts the request and verifies it. That model works because for humans and services, the meaningful unit of trust is the access request. A human asking to open a document is the thing you want to verify.

For agents, the meaningful unit is not the access. It is the action.

An agent that has legitimately authenticated and legitimately retrieved data can still do something catastrophic with the next action it decides to take. The access was fine. The action is the risk. Verifying that the agent is allowed to reach the payments API tells you nothing about whether this specific transfer, of this amount, to this recipient, in this context, after everything else the agent has done in this session, should proceed.

Zero Trust as deployed for humans and services:

   identity ──► [policy decision point] ──► access granted ──► then trusted
                  verifies the access            to act freely

What agents require:

   identity ──► access ──► [verify every action] ──► execute or block
                            per action, in context,
                            against policy, before it runs

This is the enforcement point Zero Trust never needed before, because no previous actor combined open ended decision making with machine speed execution. A human, once granted access, acts slowly and accountably. An agent, once granted access, can take a thousand consequential actions in the time it takes a human to read one sentence. Verifying the access and trusting the actions worked for every actor until the actor could act faster than anyone could watch and more openly than anyone could predict.

Extending Zero Trust to agents means moving the verification point inward, from the access to the action. Every action the agent intends to take is intercepted before it executes, verified explicitly against policy, in full context, and allowed only if it earns that specific permission at that specific moment. Never trust, always verify, applied to the action rather than the door.

What Per Action Verification Looks Like

Concretely, an action level Zero Trust enforcement point evaluates each intended action against a set of signals the moment before it executes, and returns a decision. The signals are the agent equivalent of the device posture and behavioural context that Zero Trust already uses for humans, adapted to what matters for an autonomous actor.

Identity and scope. Which agent is this, what is it authorised to do, and is this action inside that envelope. A research agent attempting a financial transaction fails this check regardless of how it was instructed.

Session context. What has this agent already done in this run. The tenth high value action in two minutes, or the first sensitive write after a long read only session, looks different from an isolated step. Continuous evaluation means the history shapes the decision.

Provenance. Where did the instruction driving this action originate. An action whose causal root is untrusted external content the agent ingested is treated with more suspicion than one rooted in the operator's original task.

Policy. The operator's actual rules, held as data outside the agent. Amounts, recipients, data patterns, time windows, approval requirements. These are conditions evaluated deterministically, not preferences the agent weighs.

Verdict. Allow, block, or escalate to a human. Returned before the action executes, so the decision is prevention, not a record of something that already happened.

   agent intends an action
            │
            ▼
   ┌──────────────────────────────────────────┐
   │     ACTION-LEVEL ZERO TRUST POINT          │
   │                                            │
   │   verify( identity, session, provenance,   │
   │           policy )  ── continuously,       │
   │                        per action          │
   │                  │                         │
   │      ┌───────────┼───────────┐             │
   │      ▼           ▼           ▼             │
   │    allow       block      escalate         │
   └──────────────────────────────────────────┘
            │           │           │
            ▼           ▼           ▼
        executes     rejected   human decides
        + recorded   + recorded + recorded

Notice that this is the same shape as the policy decision point Zero Trust already uses, moved to a new altitude. The principle is unchanged. Verify explicitly, never trust implicitly, grant least privilege. Only the unit of enforcement has moved, from the access request to the individual action, because that is where the agent's risk actually lives.

Least Privilege, Just in Time, for Agents

The least privilege principle deserves its own treatment, because it is where the agent model is most obviously broken and most fixable.

Today an agent is provisioned with standing privilege. It is handed the full set of scopes it might need across its entire task, up front, and holds them throughout. A support agent that occasionally issues refunds holds the refund permission for the whole session, even during the long stretches when it is only reading. The privilege stands whether or not it is being used, and a manipulated agent finds the standing privilege waiting for it.

Zero Trust says privilege should be minimal and just in time. For agents, this means an action acquires the specific permission it needs at the moment it needs it, justified by the context, and that permission does not persist as a standing capability the agent can reach for later. The refund permission is not a scope the agent holds. It is a decision the enforcement point makes, per refund, based on whether this specific refund is warranted right now.

The difference is decisive for the manipulation case. With standing privilege, a successful prompt injection inherits the agent's entire scope, everything it was provisioned with, and can use any of it. With just in time per action verification, a manipulated agent gains nothing standing. Each action it attempts is evaluated fresh against policy and context, and the injection cannot grant itself a permission the enforcement point declines to give. Least privilege per action turns a successful manipulation from a master key into a single rejected request.

A Breach, Traced Twice

The argument lands harder against a concrete incident. Consider an enterprise that has deployed a data operations agent with access to its customer database and an external reporting service. The agent's job is routine: pull figures, compile summaries, push reports to the reporting endpoint. It authenticates once at the start of each run and holds broad scopes for the session, the standard deployment.

An attacker compromises one of the data sources the agent reads from, planting content that manipulates the agent into exporting the full customer table to an external address the attacker controls.

Trace it through the trust once model that most agents run on today. The agent authenticates legitimately. It begins its task, reads the poisoned source, and is manipulated. It already holds, as standing privilege, both database read access and the ability to call external endpoints, because both were provisioned up front for its normal work. Nothing re evaluates the export action when it fires, because verification happened at the door and the agent is inside. The export executes against a real system, at machine speed, and is discovered later when someone reviews the logs. By then the data is gone. Every step the agent took was performed with valid credentials inside a trusted session. The breach used no stolen password and tripped no authentication alarm, because the authentication was never the weak point. The standing trust was.

Now trace it through action level Zero Trust. The agent authenticates and is manipulated in exactly the same way. The model decides to export the customer table to the external address. The action is intercepted before it executes. The enforcement point evaluates it: the volume of data is anomalous against this agent's session baseline, the destination is external, the action matches a bulk personal data egress pattern, and provenance shows the triggering instruction traces to content the agent ingested rather than the operator's task. The verdict is block, and a signed record captures the attempt and its basis.

The manipulation succeeded in both traces. The authentication was valid in both. The only difference is whether the consequential action was verified at the moment it fired, and that single difference is the whole breach. This is why moving the verification point inward is not a refinement. It is the difference between a contained, logged non event and a reported data breach.

This Is Continuity, Not a New Doctrine

It would be easy to read this as a claim that AI agents need some novel security paradigm invented from scratch. The opposite is true, and the continuity is the strongest part of the argument.

Zero Trust is correct. The principles that the security industry spent a decade adopting, never trust based on location, always verify explicitly, enforce least privilege per request, are exactly the right principles for agents. Enterprises do not need to be convinced of the doctrine. They already believe it. They already rebuilt their human and device security around it.

What has changed is only the enforcement point. For humans and devices, verifying at access was sufficient because the actor was slow and accountable after the door. For agents, verification has to reach the action, because the agent is fast, open ended, manipulable, and unaccountable per step. Same doctrine, deeper enforcement.

The enterprises that have already adopted Zero Trust have done the hard part, which was the cultural and architectural shift away from implicit trust. Extending it to agents is not a reversal of that work. It is its logical completion. The agent is simply the newest principal in the environment, and it is the one that most needs verification on every action, because it is the one that can take the most actions, the fastest, with the least inherent accountability.

   the Zero Trust journey

   network perimeter  ──►  identity perimeter  ──►  action-level verification
   (trust the inside)      (verify each access)     (verify each agent action)

   each step moved the verification point closer to the actual risk.
   agents move it one step further: to the action itself.

An enterprise that authenticates its agents but does not verify their actions has not extended Zero Trust to agents. It has recreated, for its most dangerous class of actor, the precise trusted interior model that Zero Trust was built to eliminate. The agent is inside, so the agent is trusted. That sentence should be as alarming for agents as it became for networks. The fix is the same fix the industry already chose, applied at the layer where agents act.

Never trust, always verify. The agent is not an exception to that principle. It is the principal that needs it most.

Xybern is the authorisation layer for enterprise AI agents. Every agent action is enforced, audited, and governed before it executes. Learn more at xybern.com or read the technical documentation at docs.xybern.com.