Zero trust is one of the most widely adopted security frameworks of the past decade. Its core principle is simple: no user, device or system should be trusted by default, regardless of where it sits in the network. Authentication and authorisation must happen explicitly, every time, before access is granted.
That principle does not break down when applied to agentic AI, but it does need to be extended. Agents are not users in the traditional sense, as they do not log in with a password, do not follow a predictable access pattern, and their decisions are probabilistic rather than deterministic. When an agent calls a tool, queries a database or sends an email on a user's behalf, the question of who authorised that action and what scope it should carry becomes more complex than any identity provider was originally designed to handle.
For security architects, it calls for a careful approach to translating zero trust principles into agent-specific controls before those agents reach production.
Agents versus other non-human identities
Enterprise security teams have long dealt with non-human identities, such as service accounts, API keys, automation scripts and CI/CD pipelines. Agents share some of these characteristics, but they also introduce new ones that matter for access control.
First, agents are goal-directed. They are not simply executing a fixed sequence of instructions. They perceive inputs, reason about them and decide which tools to call and in what order to reach an objective. This means the scope of their actions is not fully predictable at design time.
An agent given access to an email system, a CRM and a code repository may combine those tools in unanticipated ways, and can potentially be influenced by threats such as prompt injection, model jailbreaking or poisoned data. Meanwhile, agents often operate across trust boundaries that API keys and service accounts previously did not cross. A single agentic workflow could span multiple systems, services and cloud environments, each with its own access model. Without deliberate design, this can create a form of excessive agency, where an agent accumulates permissions across these boundaries in ways that no individual system would permit a human user.
Zero trust for agentic systems
1. Identity and ownership for every agent
While straightforward, this can be frequently skipped in early deployments. However, every agent must have an explicit identity, a defined owner and scoped credentials. Without this, there is no basis for access control, no audit trail and no accountability when something goes wrong. It also makes detection and incident response far harder, because there is no reliable way to attribute actions to a specific agent identity.
This is also where agent architecture matters. Agents typically consist of a perception layer, a reasoning loop, tool integrations, memory and an output channel. Controls need to attach at each of these junctions, rather than only one entry point. An agent may have appropriate input-level controls but unrestricted access to memory or tool outputs can expose sensitive data through a different path.
2. Least privilege for tools and memory
Excessive agency can be one of the most significant risks in agentic deployments. When systems are granted tool and system access beyond task requirements, it creates pathways for unauthorised actions that are difficult to detect and contain.
The principle of least privilege is foundational in identity and access management. Applied to agents, it means:
- Scoping tool access to the task in hand: Tool permissions should be granted dynamically and tied to specific, defined objectives rather than assigned once at deployment.
- Isolating memory. Agents that retain context between sessions create a persistent data store that can accumulate sensitive information over time. Memory access should be scoped, reviewed andcleared on a defined schedule, particularly where regulated data may be involved.
- Reviewing access regularly. Agent use cases evolve quickly. A quarterly review of what each agent can access, and whether that access is still proportionate, is a practical safeguard against permission creep.
Agent-to-agent interactions introduce a further risk: a lower-privilege agent that can influence a higher-privilege one through crafted inputs creates an escalation path that mirrors the confused deputy problem in traditional access control. Designing with this in mind means treating inter-agent communication as an untrusted channel and applying the same verification logic applied to external inputs.
3. Continuous verification and deterministic guardrails
Zero trust is not a one-time authentication event but a continuous process of verifying that the current request is consistent with the established policy, the context and the risk level. For agents, this requires a different kind of control from that used for human users.
Because prompt injection, excessive agency and other threats may remain a risk even with well-designed systems, controls cannot rely solely on the model making the right decision. They must include deterministic checks that sit outside the reasoning loop. These should include policy decision points, human-in-the-loop confirmation steps for high-impact actions, and ongoing observability of tools calls. For example, requiring approval before sending external emails, changing customer records, executing code or accessing regulated data.
These controls help to close the gap between what the model is designed to do and what it might be manipulated into doing.
Evolving your zero trust approach
Extending zero trust to agents means that identity and access management can no longer stop at the human boundary. Service catalogues, identity providers and access policies all need to account for agents as first-class entities with defined permissions, audit trails and a process for ongoing review.
For organisations already running a cloud landing zone, many of the building blocks are in place. Managed identities, role-based access control, centralised logging and policy enforcement are the same capabilities needed to govern agents. The work lies in applying them deliberately to agent workloads rather than assuming existing policies will extend automatically.
For a deeper look at building an AI-ready security posture, including SOC integration, detection engineering and compliance considerations, download our latest e-book.