Zero Trust for AI Agents: Why Separate Identity Alone Is Not Enough

Denis Korbakov, Technical Director at Smart-Soft, argues that conventional identity and access management systems are ill-equipped for the new class of autonomous AI agents that independently choose tools, switch contexts, and delegate permissions.

NIST SP 800-207 has long included non-person entities in its Zero Trust model, yet most corporate IAM implementations remain designed either for interactive human sessions or for long-lived static service accounts. AI agents sit between these two paradigms, requiring dynamic, task-specific credentials rather than persistent broad rights.

February 2026 data from the Gravitee State of AI Agent Security report reveal that only 21.9% of teams assign agents their own identity. Meanwhile 45.6% reuse shared API keys across agents and 44.4% rely on generic tokens. Cloud Security Alliance and Aembit findings indicate that 68% of organizations cannot clearly separate agent actions from human actions, 74% observe excessive access grants, and 52% record rights inheritance from users or other systems.

Reducing Zero Trust to three operational principles—explicit verification, least privilege, and assume breach—Korbakov maps each to agent workloads. Explicit verification demands that every tool invocation carries a verifiable agent identity together with a short-lived, narrowly scoped authorization decision that records the resource, operation, task, and initiator.

Least privilege requires binding rights to the exact task at hand rather than to the agent’s theoretical maximum permissions. Each logical agent receives a base machine identity, while every delegated sub-task obtains a short-lived derived context that preserves the full delegation chain: user → agent → sub-agent → tool.

Assume breach means that even if an agent is compromised through indirect prompt injection—an attack highlighted in OWASP LLM01:2025—or its runtime credentials are stolen, the resulting damage must be technically limited by architecture. The proposed three-layer model comprises machine identity, tool-level authorization, and independent policy enforcement points at the network (NGFW), Kubernetes (service mesh), or external API/MCP gateway layers.

A practical ticket-diagnosis workflow demonstrates the difference. Instead of a single broad token, the agent receives a 300-second credential limited to reading one specific repository and writing a single comment. Network traffic is forced through a dedicated VLAN segment enforced by Traffic Inspector Next Generation, producing both rule-hit syslog records and NetFlow metadata that can be correlated with agent-platform logs.

The article leaves open the question of sub-agent identity inheritance versus independent credentials and invites practitioners to share where they store and verify delegation chains—in IAM, API gateways, agent runtimes, or MCP gateways. Reference materials including OPA/Rego policies, stop-criterion matrices, and prompt-injection incident runbooks are provided for pilot deployments.