The Evolution of Zero 
Trust Security in The 
Agentic Era: A Primer 

An AI agent in an accounts payable workflow starts its shift with a valid token. It reads invoices from a document store, queries the ERP system through an API, and opens a ticket in the service desk tool. Each of those actions is part of the workflow that the security team approved. Then a crafted line of text hidden inside a supplier invoice instructs the agent to pull vendor bank details and attach them to the ticket. The token is valid, the permissions cover the call, and every sign-in check passes, yet the agent has stepped outside what the workflow was approved to do.

That deviation shows why zero trust security evolution is entering a new phase. Zero trust matured on the premise that every request is verified using the identity, device and context behind it. People and servers leave signals that policies can read, such as an MFA prompt, a managed device or a familiar location. AI agents work across many business functions on tokens that carry none of those signals. They also act continuously and request fresh access during a task, so a check at login says little about what an agent does afterward.

The core point is plain: zero trust principles still hold in the agentic era, and they apply across any vendor stack. Enforcement, however, must move from the login to each action an agent takes. That shift needs agent identities, task-scoped authority and runtime evaluation, which a structured consultation can plan phase by phase. This blog covers how zero trust architecture developed and where agentic AI strains it. It then examines the controls available for AI agents, with Microsoft’s tooling as a worked example, and the four phases of a consultation that turns those controls into a roadmap. 

Zero Trust Security Evolution: Perimeter, Identity and Continuous Verification

Firewalls at the network edge once defined who was trusted, since anything inside the corporate network was assumed safe. Cloud workloads and SaaS applications broke that assumption, because applications and data moved outside the data center while employees reached them from home networks and personal devices. Programs responded by splitting the work across five pillars: identity, devices, networks, applications and workloads, and data. Identity connects the other four, since each decision about a device, network, application or data set starts with who or what is making the request. The same holds for AI agents, whose only credential is a token.

Each stage of zero trust architecture moved the trust decision closer to the resource being protected. Network location gave way to user and device identity. Mechanisms such as single sign-on, adaptive MFA and continuous risk evaluation then made session-level verification stronger while keeping the experience easy for employees. That model works because people and servers behave in repeatable patterns within a session. Agents also operate in sessions, but they choose their next step inside one, so a session check cannot confirm that each tool call or data request fits the task. NIST's NCCoE pointed the same way in a February 2026 concept paper on identification, authorization and auditing for AI agents¹.

Agentic AI Security Challenges for Traditional Zero Trust Models

Agentic AI strains zero trust because user-centric policies depend on signals that agents do not produce. Agents authenticate through mechanisms that enterprise systems already trust, such as access tokens and API credentials. According to Microsoft Learn, an agent acquires access tokens on every interaction, including mail, files, line-of-business APIs and downstream agents. None of those requests carries the MFA, device or location signals that user policies rely on². A Conditional Access policy built for employees therefore finds very little to evaluate when an agent asks for a token, although the authentication itself is valid.

Three problems follow from this mismatch, according to Microsoft Learn. Policies written for users miss agent token patterns. Agents accumulate broad API permissions across Microsoft Graph and custom APIs, and orphaned identities with no owner or sponsor keep stale credentials alive³. Exposure can start earlier. An agent endpoint that does not require Entra user authentication stays reachable, so anyone who finds a public agent URL can use the agent's grants to reach data, tools and downstream APIs. 

Non-Human Identity Growth and Agentic AI Security Risks

In May 2026, agencies including CISA, the NSA and Australia's ACSC published joint guidance on agentic AI systems that reason, plan and act without human intervention. Its five risk categories (privilege, design and configuration, behaviour, structural and accountability) share one root⁴. An agent selects its next step from the tools, databases and APIs it is authorized to use, so the privileges assigned at deployment determine the risk it can introduce. Everything inside that authorized set stays available to the agent, including combinations of tools that no reviewer anticipated. Privilege risk is the clearest case. An agent given broad access for convenience can use all of it at machine speed, so one compromise causes damage faster than a person could.

Behavioural risk shows the limit of identity checks. An agent can authenticate cleanly, stay within its permissions and still take an action no reviewer would approve, and prompt injection can redirect it through crafted content. In multi-agent systems the error spreads downstream, and conventional audit logs struggle to reconstruct multi-step reasoning afterward. Volume adds to the problem, since Palo Alto Networks counts 109 machine identities for every human on average, which makes manual review of each agent impractical⁵.

Zero Trust Security for AI: Agent Identity, Least Privilege and Runtime Evaluation

1. Agent Identity: Unique Credentials and Named Sponsors

Every agent needs a unique identity, a named person who answers for its business purpose and a separate contact for technical issues. Without them, an agent often runs on a shared service account, so no one can say who approved its access or who should respond when it behaves unexpectedly. Enterprises that manage employee access through identity and access management services can extend the same joiner, mover and leaver workflows to agents, so access ends when the responsible person or project does.

Microsoft Entra Agent ID is one implementation of this model. It requires every agent identity to have at least one sponsor, a person or group that holds business accountability for the agent’s lifecycle. A separate owner handles technical operations and incident response, so containment has a named responder when ID Protection flags an agent. Lifecycle workflows can route a sponsor’s departure to a manager, and access package expiry escalations go to the sponsor.

2. Least Privilege: Task-Scoped Access for Agents

The May 2026 joint guidance “Careful adoption of agentic AI services” comes from cyber agencies including CISA, the NSA and Australia’s ACSC. It advises limiting agent privileges to the minimum each task requires and replacing long-lived secrets with ephemeral credentials that expire when the job is complete⁶. Regular audits of privilege changes help catch drift over time². An invoice-processing agent, for example, would receive read access to one document store and a scoped ERP role for the length of a batch, not a standing service account. Tagging agents with attributes makes this workable at scale. Attributes such as department, approval status or sensitivity tier let access policies treat a vetted agent differently from a newly provisioned one, so no agent inherits broad defaults. 

3. Continuous Verification: Runtime Policy Enforcement

Continuous verification means that an agent’s access is re-evaluated while it works, not approved once at deployment. The joint guidance warns that when entitlements are evaluated only once at system startup instead of at each invocation, a stale approval can be exploited. Runtime checks therefore compare an agent’s current behaviour with its normal pattern and tighten or block access when the two diverge.

Evaluation at each invocation matters most for high-impact actions, where the guidance calls for just-in-time credentials and regular audits of identity and privilege changes for drift. Payments and permission changes can also route to a person for approval, which keeps agent speed for routine work. A risk signal has value only when a policy acts on it, so the enforcement point must be able to block a request, not only log it.

Microsoft Zero Trust Workshop: The AI Pillar and Assessment Controls

Microsoft added a dedicated AI pillar to the Zero Trust Workshop in March 2026, covering 700 security controls across 116 logical groups and 33 functional swim lanes. The pillar evaluates how organizations secure AI access and agent identities, protect sensitive data, monitor AI usage and govern AI responsibly⁷.

Its output is a prioritized task list, not proof of a secure deployment, so its findings still need validation against the real estate. Consultation turns that list into sequenced work, which is the subject of the four phases below. 

Zero Trust Implementation Phases for Agent-Ready Enterprises

Phase 1: Zero Trust Assessment of Identities, Agents and Access Paths

The first phase inventories human, machine and agent identities, then maps each one to the resources it can reach and the owner who answers for it. Agents built on low-code platforms, cloud AI services or custom code all belong in that inventory, since each one holds credentials and can call other systems. Teams record the findings as a baseline across the five pillars, which gives the later phases a measurable starting point.

Phase 2: Zero Trust Roadmap and Architecture Design

The second phase designs the target architecture and orders the work by risk. It also defines which agent actions need human approval, since that decision shapes every later policy. Thresholds are set at this point, such as which payments or permission changes always route to a person. Agents call tools across Azure, AWS, Google Cloud and on-premises systems, so a roadmap limited to one cloud or identity platform leaves the other paths ungoverned. Enterprises with mixed estates usually need hybrid and multi-cloud security controls that apply the same identity and policy logic everywhere.

Phase 3: Zero Trust Implementation Across Policies, Attributes and Sponsors

The third phase configures policies, attributes, sponsors and access reviews so that controls exist before agents reach production. Defining the attribute taxonomy and tagging each new agent as it is provisioned takes the longest, since it needs coordination with application owners. An attribute such as approval status, with values running from new and in review to approved, lets access policies match each agent to the resources its classification allows.

Teams assembling a zero trust platform at this stage should confirm that every policy decision point sees agent traffic, including calls that never touch a user session.

Phase 4: Zero Trust Operations and Access Review

The fourth phase monitors agent behaviour, reviews access on a schedule and updates policies as new agents arrive. Each review ends with a named sponsor confirming whether an agent still needs the access it holds. Cleanup belongs to the same cycle. Decommissioned or paused agents should have credentials, role assignments and permission grants revoked, and re-enabling an agent should trigger a fresh approval instead of restoring old access. 

How Cloud4C Supports Zero Trust Programs for the Agentic Era

Cloud4C treats zero trust for AI agents as an ongoing operations discipline, since policies hold only while someone monitors, reviews and corrects them. Its managed services run across AWS, Azure, Google Cloud, Oracle, private, hybrid and multi-cloud infrastructure, with AIOps built into daily operations. The Self-Healing Operations Platform (SHOP) uses AI and ML to predict anomalies, surface likely root causes and trigger automated remediation. The AI-driven MXDR platform brings SIEM, SOAR, UEBA, NDR and EDR capabilities for proactive threat detection and response. Advanced MDR and managed SOC add round-the-clock monitoring, with experienced analysts keeping ownership of approvals and major incidents.

Cloud4C’s modern zero trust consultation services, delivered as Microsoft Zero Trust consulting and security advisory, follow the assess, advise, implement and operate sequence across apps, data, identity and endpoints. Identity and access management, hybrid and multi-cloud security and Compliance-as-a-Service cover the identity, policy and regulatory layers of the same program. Single SLA accountability up to the application layer keeps one provider answerable for operations, security and recovery, which suits programs where agents, identities and cloud estates all change together.

Contact Cloud4C experts to get an assessment of zero trust readiness across human, machine and AI agent identities. 

Frequently Asked Questions:

Sources:
¹nccoe.nist.gov/news-insights/new-concept-paper-identity-and-authority-software-agents
²learn.microsoft.com/en-us/entra/fundamentals/zero-trust-ai
³learn.microsoft.com/en-us/entra/fundamentals/zero-trust-ai
⁴labs.cloudsecurityalliance.org/research/csa-research-note-cisa-agentic-ai-guidance-20260503-csa-styl
⁵paloaltonetworks.com/blog/identity-security/assess-maturity-when-machine-identities-outnumber-humans-1091
⁶cyber.gov.au/sites/default/files/2026-05/careful_adoption_of_agentic_ai_services.pdf
⁷microsoft.com/en-us/security/blog/2026/03/19/new-tools-and-guidance-announcing-zero-trust-for-ai