Skip to content

Chapter 3 of 64 min readBy Deepak GuptaUpdated

When AI Agents Break the Model

The Machine Identity Problem

Here's a statement that should make any security architect pause. Machine identities (service accounts, API keys, deployment pipelines and, increasingly, AI agents) now vastly outnumber human identities. Palo Alto Networks' 2026 Identity Security Landscape, a survey of more than 2,900 security decision-makers, puts the ratio at 109 machine identities, including AI agents, for every human. CyberArk's 2025 edition, published before Palo Alto Networks acquired CyberArk, reported 82 to 1.

Zero Trust was designed with human users as the primary subject. The model assumes identity belongs to a person who authenticated with credentials, uses a device you can evaluate, and accesses applications in recognizable patterns. AI agents don't fit that model.

What Changed When AI Entered the Picture

AI agents act autonomously. An agent running a workflow might make hundreds of API calls in minutes, query multiple data sources, generate and execute code, and trigger downstream actions on its own. Its behavioral baseline looks nothing like a human user's.

AI agents operate across long contexts. A multi-hop, multi-system access pattern is exactly what lateral movement looks like. Telling legitimate agent behavior apart from adversarial behavior is genuinely hard.

AI agents inherit and amplify permissions. If an agent runs in the security context of a human user or a broadly scoped service account, it can do whatever that identity can do, at machine speed.

AI agents can be manipulated. In a prompt injection attack, malicious content embedded in data the agent processes causes it to perform unintended actions. OWASP ranks it first in its Top 10 for LLM Applications.

Warning

An agent running under a human user's credentials with broad permissions is the equivalent of giving an intern the CEO's master key and asking them to "figure it out." The blast radius is enormous.

How Zero Trust Must Evolve for AI

1. Every AI Agent Needs Its Own Identity

An agent should not run under a shared service account or a human user's identity. It should have its own workload identity, with permissions explicitly scoped to what that specific agent needs.

2. Least Privilege for Agentic Workflows

A more mature approach uses just-in-time permission grants. The agent requests the permission it needs for each step, uses it, and releases it. This is architecturally more complex but significantly reduces blast radius.

3. Protect AI Agent Inputs and Outputs

Prompt injection is the Zero Trust problem for the AI data plane. Treat all external content as untrusted data, not as instructions. Filter and constrain inputs before the agent processes them, and validate outputs before they trigger actions.

4. Behavioral Baselines for AI Agents

UEBA (user and entity behavior analytics) was built for human users. AI agents behave differently and need their own baselines. Log agent activity separately, with agent-specific context.

5. Human-in-the-Loop for High-Stakes Decisions

Irreversible, high-stakes operations should require human review before the agent proceeds. Examples include sending external communications, modifying production data and executing financial transactions.

The Multi-Agent Authorization Challenge

When AI agents call other AI agents, authorization decisions multiply with every level of delegation. A simple illustration: suppose each agent hands work to two sub-agents, and every hand-off needs its own authorization decision. The total doubles with each level of depth.

Delegation depth (each agent calls two others) Authorization decisions in the tree
1 1
3 7
5 31
10 1,023

This is a model, not a measurement; real systems branch unevenly. The point holds anyway: an authorization design that works for one agent breaks down long before a chain is ten levels deep.

Key threats in multi-agent systems include:

  • Agent impersonation: an attacker posing as a legitimate agent in the network.
  • Delegation chain exploitation: accumulating, across a chain, permissions that no single agent should have.
  • Tool poisoning: compromising tools that agents share.

The mitigation has three parts. Verify the cryptographic identity on every agent-to-agent call. Apply permission diminishment, so each delegation carries fewer permissions than the one before it. Set a hard limit on delegation depth.

Key takeaways

  • Every AI agent needs its own identity, scoped permissions and a behavioral baseline.
  • Treat agent inputs and outputs as untrusted, starting with prompt injection.
  • Authorization decisions multiply with every level of agent delegation.
  • Verify identity on each agent-to-agent call, shrink permissions with each delegation and cap delegation depth.