For years, Zero Trust programs have focused on a familiar principle: never trust implicitly and continuously verify access based on identity, device, context, and risk.
Agentic AI introduces a new participant into that architecture.
An AI agent may read corporate data, invoke APIs, query databases, create tickets, modify cloud resources, communicate with external systems, or execute workflows on behalf of an employee. Unlike a conventional chatbot, the agent may perform several of these operations autonomously to accomplish a goal.
This is quickly becoming an enterprise security issue rather than a theoretical AI concern.
The next identity problem is not human
Recent industry initiatives are extending AI security guidance toward practical runtime enforcement for agentic systems. At the same time, identity, cloud, endpoint, data, and SASE vendors are increasingly converging around a common idea: AI agents should be treated as first-class identities, with limited access, traceable delegated authority, continuous monitoring, and rapid containment.
The direction is becoming clear: AI agents need to become part of the enterprise identity and Zero Trust architecture.
Why traditional application security is not enough
A traditional application normally operates through relatively predictable workflows. An AI agent is different because it can interpret instructions, make decisions, select tools and perform sequences of actions dynamically.
That creates an important distinction between access and authority.
An agent may legitimately have access to Microsoft 365, a CRM platform, ServiceNow and an internal database. That does not mean it should have unrestricted authority to perform every operation available through those systems.
Consider an AI agent assisting a security operations team. It may reasonably need permission to retrieve an alert, obtain endpoint information, correlate identity activity, query threat intelligence, and prepare a recommended response. Allowing the same agent to disable accounts, isolate production servers or change firewall policy without additional authorization creates a very different risk profile.
The security question changes from “Can this identity access the application?” to “What exactly is this agent authorized to do, under whose authority, for how long, and under what conditions?”
Apply Zero Trust principles to agents
Organizations do not necessarily need an entirely new security philosophy. Many existing Zero Trust principles translate directly to agentic AI.
Give every agent an identity
Production agents should not operate through anonymous access, shared service accounts or embedded long-lived credentials. Their activity should be attributable to a distinct workload or agent identity.
Use least privilege at the action level
Authorization should reflect the agent’s specific business purpose. Read, recommend, modify and execute are materially different privileges.
Make delegation explicit
When an agent acts for a user, the security architecture should preserve the relationship between the human identity, the agent and the resulting action. “The AI did it” cannot become an acceptable audit trail.
Prefer temporary authority over standing privilege
Where possible, provide scoped, task-specific and time-limited authorization rather than permanent access. This limits the blast radius if an agent is manipulated or behaves unexpectedly.
Control tools as well as models
The most consequential risk often is not what an LLM can say—it is what connected tools allow the agent to do. APIs, MCP servers, databases, SaaS connectors, automation platforms and privileged administrative interfaces become part of the AI attack surface.
Monitor runtime behaviour
Authentication alone is insufficient. Organizations should be able to detect unusual tool invocation, abnormal data access, unexpected delegation chains and actions outside the agent’s intended purpose.
Design revocation and containment before deployment
Security teams need the ability to terminate an agent session, revoke credentials, disable tools and isolate an agent without disrupting an entire application environment.
Prompt injection becomes an authorization problem
This architecture also changes how organizations should think about prompt injection.
Preventing malicious instructions from reaching an AI model remains important, but assuming that every malicious prompt can be detected is unrealistic. A stronger architecture assumes that an agent may eventually receive or interpret an unsafe instruction and limits what happens next.
If reading a malicious document can convince an agent to attempt an unauthorized action, the authorization layer should still prevent that action. That is classic defense in depth. The model should not be the final security enforcement point for its own privileges.
Start with an Agent Access Matrix
Before deploying a production AI agent, IFSEC recommends documenting at least five elements:
Agent → Identity → Resource → Permitted Action → Authorization Context
For example:
SOC Investigation Agent → Agent Identity → Endpoint Platform → Retrieve telemetry → Analyst delegated session
SOC Investigation Agent → Agent Identity → Endpoint Platform → Isolate endpoint → Explicit elevated approvalThis simple exercise often exposes excessive permissions before sophisticated AI-security tooling is even introduced. It can then be expanded with data classification, logging requirements, approval thresholds, credential lifetime, network controls and automated response.
The architecture matters more than the model
Enterprise AI security discussions often concentrate on which model is being used or whether one model is safer than another. Those questions matter, but the larger architectural issue is increasingly what surrounds the model.
Identity, authorization, data governance, API security, network enforcement, runtime monitoring and incident response determine how much damage an AI system can cause when something goes wrong.
The organizations best positioned for agentic AI will therefore not be those attempting to eliminate every possible AI failure. They will be those designing environments in which an AI failure does not automatically become a security incident.
That is fundamentally a Zero Trust objective.
