Agentic AI Is Forcing Zero Trust to Confront an Identity Crisis

Agentic AI reached Google News with a stark claim: autonomous systems are turning Zero Trust cybersecurity “on its head.” The Breaking Defense headline identifies a real conflict, even though its underlying details remain difficult to verify independently. Security teams built access controls around people, devices, and predictable applications. AI agents now blur all three categories while acting with delegated authority.

That does not make Zero Trust obsolete. It changes what organizations must verify, how often they verify it, and which identity performed each action. An agent can interpret a goal, select tools, read external content, call APIs, and modify data. Its behavior is not fully captured by the permissions assigned to its human owner.

The result is an uncomfortable reversal. Zero Trust assumes that every request should face evaluation, yet agentic workflows generate long chains of requests at machine speed. The primary contest is therefore not agentic AI versus Zero Trust. It is static access control versus continuous control over autonomous behavior.

The Google News Claim Points to a Real Security Shift

The important change is not that AI can access enterprise systems, but that it can decide what to do after gaining access.

Traditional software follows paths that developers define in advance. It may contain bugs, accept malicious input, or expose vulnerable interfaces. However, defenders can usually map its intended functions to established accounts, processes, and network connections.

Agentic AI adds a decision-making layer between a user’s instruction and the resulting action. An agent can divide a broad objective into smaller tasks, choose among available tools, and adapt when one path fails. NIST describes modern agents as general-purpose models combined with software that lets them manipulate tools beyond text generation.

Those tools can include browsers, databases, calendars, code interpreters, local files, and administrative interfaces. NIST’s tool-use taxonomy distinguishes read-only access from constrained or unrestricted write access. It also separates trusted environments from untrusted ones.

That distinction matters because a single agent often crosses several categories during one assignment. It might read an email, extract a customer number, query an internal database, and update a support record. Each step may appear permitted when reviewed separately.

The combined workflow can still produce an unsafe result. An attacker could place hidden instructions inside the email. The agent might interpret those instructions as part of its task, then use legitimate permissions to disclose data.

This attack is called indirect prompt injection, which means malicious instructions reach an agent through content it processes. The attacker does not need the employee’s password. The attacker targets the agent’s interpretation of trusted and untrusted information.

The Google News headline captures this shift through the phrase “on its head.” Previously, security teams worried that people would misuse software or surrender credentials. Now they must also consider software that interprets a person’s authority and acts independently within it.

This is not merely another endpoint entering the network. An endpoint normally has a relatively stable function, posture, and ownership model. An agent can change its immediate plan while retaining the same identity, credentials, and connection.

That creates a visibility problem. A log may show that a valid service account accessed a database. It may not reveal which user initiated the task, which agent formed the plan, or which external input influenced the decision.

The headline should still be treated as a thesis, not proof of a specific breach. No verified incident details accompany the supplied Google News item. The broader security issue, however, is supported by public research and current standards work.

Security teams are no longer protecting only human-to-application and application-to-application access. They must secure a chain connecting a human, an agent, a model, several tools, and multiple data sources. Trust can leak at every handoff.

Zero Trust Was Built for Requests, Not Open-Ended Goals

Zero Trust remains relevant, but its conventional unit of control is too narrow for autonomous work.

NIST published its foundational Zero Trust architecture in 2020. The model rejects implicit trust based on network location or asset ownership. Authentication and authorization occur before a session reaches an enterprise resource.

The architecture focuses on resources rather than traditional network segments. It assumes that a network may already be compromised. Access should therefore remain limited to the smallest set of permissions required for a specific mission.

This approach counters the old perimeter model. Under perimeter security, authenticated users often received broad access after entering a trusted network. Attackers could then move laterally between systems after compromising one account or device.

Agentic AI does not invalidate those principles. In fact, least privilege and continuous evaluation become more important when machines can perform many actions quickly. The difficulty lies in translating a broad user goal into enforceable, short-lived permissions.

Consider an agent asked to prepare a quarterly customer-risk report. The task sounds informational, but completing it may require several capabilities. The agent needs to locate records, join data, calculate trends, and produce a document.

Should the agent receive access to every customer record during the entire assignment? Should it retain those permissions afterward? Can it email the report, or should distribution require separate approval?

A conventional access system may answer these questions through the user’s existing role. If the employee can read the database and send email, the agent inherits both powers. That inheritance is simple, but it creates excessive authority.

The agent can perform combinations of actions that the employee never intended. It can also repeat them at a scale that manual workflows rarely reach. A small interpretive error can become hundreds of database queries or messages.

Open-ended goals make policy design harder. “Find the relevant evidence” does not specify which repositories should be searched. “Resolve the issue” does not define whether the agent can issue a refund, modify an account, or execute code.

Zero Trust traditionally evaluates access requests using identity, device health, resource sensitivity, and environmental context. Agentic systems add another question: does this action remain consistent with the task that justified access?

That question requires intent-aware controls. These controls compare an action with the agent’s assigned purpose, current plan, and approved policy. They cannot depend solely on whether an account technically holds permission.

The security boundary also moves during multi-agent work. One agent may delegate research to another agent. That second agent may call a third-party service, which returns content containing new instructions.

Each handoff can alter context while preserving apparent authorization. A static policy sees approved identities passing data. A behavioral policy must determine whether the entire chain still serves the original goal.

This is why agentic AI security cannot stop at network segmentation. The control plane must understand identities, tasks, tools, data lineage, and action history. It must also preserve those relationships for later investigation.

The original Zero Trust promise still holds: never grant trust merely because something is already inside. Agentic workflows simply reveal that “inside” can describe a context window, delegated task, or tool chain. It no longer refers only to a network.

AI Agents Need Identities Separate From Their Owners

An organization cannot govern an autonomous agent if every action appears under a human or shared service account.

Identity is the first pressure point for enterprise security teams. People have employment records, managers, job roles, and departure procedures. Applications have owners, release processes, and service accounts.

Agents combine features from both groups. They can receive goals from people, but they execute through software. They may operate briefly for one task or continue running as persistent digital workers.

Treating an agent as a hidden feature inside an application obscures accountability. Treating it as a normal employee also creates false confidence. The agent needs a first-class machine identity linked to its owner, purpose, and deployment.

That identity should not replace the initiating user’s identity. Both should survive throughout the workflow. Investigators need to know who requested an action and which agent executed it.

A useful audit record should also capture the model, tool, policy, and data source involved. Without this context, a database log shows only the final access. It cannot explain why the agent believed that access was appropriate.

Security teams should avoid shared credentials for agent deployments. Shared accounts prevent reliable attribution and complicate revocation. They also allow abandoned agents to remain active after their original projects end.

An agent identity needs a lifecycle. Creation should identify an accountable owner and approved use. Periodic review should confirm that the agent remains necessary and that its permissions still match its purpose.

Expiration is equally important. Temporary agents should lose access when a task or project ends. Persistent agents should face regular recertification, much like privileged human accounts.

Permissions should also be task-specific and short-lived. An agent preparing a report may receive temporary read access to selected records. Sending that report outside the organization should require a separate permission or human confirmation.

This design reduces privilege creep, which occurs when identities accumulate access that no longer matches their responsibilities. Privilege creep is already difficult with employees. Autonomous agents can multiply the problem because teams can create them quickly.

Agent discovery therefore becomes an operational requirement. Security teams need an inventory across SaaS services, development platforms, internal automation systems, and third-party integrations. Procurement records alone will not identify agents created inside existing products.

Discovery must distinguish an AI feature from an acting identity. A summarization feature that only reads one document carries different risks from an agent that can search drives and send messages. Both may use the same model.

The owner should also be visible in policy and logs. When an agent acts outside expectations, responders need a person or team capable of suspending it. Anonymous automation creates delays during incidents.

Organizations already use non-human identities for services, workloads, and machines. Agent identities extend that discipline rather than replacing it. The difference is that policy must account for variable behavior within the same assigned role.

Major security vendors are moving in this direction. Cisco announced agent discovery, agentic identity controls, and Model Context Protocol enforcement within its agent security update. Model Context Protocol, or MCP, connects models with tools and external data.

Vendor announcements are not independent evidence that the controls work across every deployment. They do show where competition is heading. Identity platforms, access brokers, and security gateways all want to become the control point for agent traffic.

Enterprise buyers should resist treating one gateway as a complete solution. NIST has long noted that no single vendor supplies an entire Zero Trust architecture. Agentic security adds more components and more opportunities for inconsistent enforcement.

The immediate pressure falls on identity and access management teams. They must support rapidly created machine actors without repeating the unmanaged service-account problem. Static role assignments will not be enough.

Agent Hijacking Exposes the Limits of Static Permission Checks

A correctly authenticated agent can still perform the wrong action because authentication does not validate its reasoning.

The strongest argument for reworking Zero Trust comes from agent hijacking research. In March 2026, NIST reported results from a large public red-teaming competition covering 13 frontier models. More than 400 participants made over 250,000 attack attempts.

At least one successful hijacking attack was found against every tested model. The models differed in their resistance, but capability did not consistently predict security. Some attack families also transferred across different models and scenarios.

These results do not mean every deployed agent is easily compromised. A competition encourages focused attackers and may not reproduce every production control. It does establish that model-level resistance alone cannot serve as the security boundary.

NIST defines agent hijacking as an attack that places malicious instructions inside data an agent processes. The goal is to redirect the agent toward harmful behavior. Potential outcomes include data exfiltration or malicious code execution.

The crucial detail is that the agent often uses valid tools and credentials. A firewall may see an approved connection. An identity system may see an authenticated account. The dangerous step occurs in the agent’s interpretation of content.

That makes static allowlists incomplete. Allowing an agent to read email and update a database might be necessary for its job. The policy must still prevent an email from redefining what the database tool should do.

The relevant red-team findings support defense in depth. Models need evaluation, but deployments also need constrained tools, data boundaries, monitoring, and approval points.

Tool permissions should reflect consequence, not convenience. Reading a public webpage presents different risks from running downloaded code. Querying a customer record differs from deleting or exporting it.

High-impact tools should expose narrow operations. An agent that needs to schedule a meeting should not receive unrestricted mailbox control. A finance agent that drafts a payment should not also approve and transmit it.

This principle is called separation of duties. It prevents one identity from controlling every step of a sensitive process. Agentic systems need the same division, even when automation makes consolidation tempting.

Human approval remains useful at irreversible boundaries. Transfers, deletions, external publication, production deployment, and credential changes deserve explicit checks. Approval should display the intended action and relevant context.

A generic “allow” button adds little protection. The reviewer needs to know which agent requested the action, what data it used, and what effect approval will produce. Otherwise, automation simply moves social engineering to the approval screen.

Monitoring should focus on behavior changes. An agent suddenly accessing unfamiliar repositories may indicate hijacking or faulty planning. Repeated failed tool calls can signal that an agent is probing beyond its role.

Rate limits also reduce the damage from mistakes. Machine-speed execution can turn a single bad decision into a widespread incident. Limiting action volume gives monitoring systems and responders time to intervene.

Sandboxing remains valuable, but it should not create an assumption of safety. An agent can cause damage without escaping its runtime. Sending authorized data to the wrong destination may require no software exploit.

The central uncertainty is whether intent-aware systems can make reliable decisions without blocking useful work. Agent plans change, business tasks contain ambiguity, and policies cannot anticipate every legitimate exception.

Overly strict controls will produce constant approval requests. Teams may then grant broader permissions to restore productivity. That response recreates the exact implicit trust that Zero Trust was meant to remove.

Overly permissive controls produce the opposite failure. Agents operate smoothly until a malicious input or planning error exploits their authority. Security teams must measure both blocked work and unsafe actions.

This tradeoff prevents easy claims that an “agentic Zero Trust” product has solved the problem. Product demonstrations usually show selected workflows. Real deployments contain legacy systems, shared identities, and inconsistent logs.

The most credible near-term approach is layered. Give each agent an identity, restrict each tool, preserve the initiating user, validate consequential actions, and monitor behavior. Assume that model safeguards will sometimes fail.

The Competitive Battle Is Moving Into the Control Plane

Security vendors are competing to mediate agent behavior, while enterprises still lack a common model for proving that mediation works.

Agentic AI creates opportunities for identity providers, network-security vendors, cloud platforms, and specialized AI-security companies. Each group controls a different part of the workflow. None automatically sees the full chain.

Identity vendors know who received access. Network platforms observe connections between systems. Cloud providers can monitor workloads and API calls. AI-security tools inspect prompts, model outputs, and tool requests.

The valuable position is the policy decision point. In a Zero Trust architecture, that component evaluates access and decides whether enforcement should permit it. Agentic systems make that decision richer and more contested.

A network vendor may argue that agent communication should pass through a security broker. An identity vendor may center policy on machine identities and delegated authorization. An AI-security provider may prioritize prompt inspection and behavioral evaluation.

All three views contain part of the answer. Network context cannot reveal every malicious instruction. Prompt inspection cannot enforce a blocked database query by itself. Identity verification cannot guarantee that an authenticated agent follows its purpose.

MCP has become one focus because it standardizes connections between models and tools. A gateway can inventory servers, restrict operations, and record calls. However, not every agent uses MCP, and a gateway cannot govern tools that bypass it.

Agent-to-agent communication presents another challenge. Delegation may cross models, vendors, or organizational boundaries. The receiving agent needs evidence about the sender’s identity, authority, and requested scope.

A signed message can authenticate the sender. It does not prove that the sender’s plan is safe. Policy must separate provenance, which identifies where a request came from, from authorization, which determines whether it should proceed.

Standardization work is beginning to address these gaps. NIST launched its agent standards initiative in February 2026. Its agenda includes interoperability, open protocols, security, identity, and trusted adoption.

That initiative matters because organizations need comparable representations of agent identity and authority. Without common formats, each platform creates proprietary identities and policy signals. Security teams then struggle to enforce controls across environments.

Standards alone cannot settle risk tolerance. A hospital, bank, defense contractor, and marketing agency will assign different consequences to the same tool action. Interoperability provides shared plumbing, not a universal policy.

The Breaking Defense framing is especially relevant to high-assurance environments. Defense systems often combine classified data, mission constraints, legacy equipment, and strict accountability. An autonomous action can have consequences beyond ordinary office automation.

Those environments also create pressure to automate. Analysts face large volumes of alerts, documents, and sensor data. Agents can help correlate information and execute repetitive steps, but broader autonomy increases the need for traceable control.

The competition should therefore be judged through evidence, not product vocabulary. Buyers need to test whether a control identifies agents reliably, binds actions to owners, limits tools, and produces usable audit records.

They should also test failure cases. What happens when the identity provider is unavailable? Can an agent fall back to cached permissions? Does a broker fail closed, or does traffic bypass inspection?

Cross-platform coverage matters as much as individual features. An organization might use one cloud model, another vendor’s coding agent, and several SaaS assistants. A control that sees only one environment leaves significant blind spots.

The market will likely consolidate around integrated platforms, but integration can create its own concentration risk. One compromised policy plane could affect many agents. Independent logging and enforcement remain important safeguards.

Google News may amplify headlines about agentic AI replacing familiar security models. The more accurate conclusion is narrower. Existing vendors must extend Zero Trust from connection decisions into identity, intent, and action governance.

What Security Teams Should Watch Next

The next phase will be decided by measurable deployment evidence, not by broader claims about autonomous security.

The first signal is whether standards groups produce usable specifications for agent identity and delegated authorization. NIST said its initiative would develop research, guidance, and other deliverables. Enterprises should watch for formats that survive across vendors.

A useful identity specification must connect an agent to an owner, purpose, model, and approved tools. It should also preserve the initiating user during delegation. If platforms adopt incompatible representations, governance will remain fragmented.

The second signal is independent security testing. NIST’s competition found successful attacks against every tested frontier model, but organizations need evaluations at the deployment level. Tests should include models, tools, permissions, memory, and external data.

Comparative testing should measure more than prompt-injection success. It should examine whether agents exceed task scope, misuse legitimate tools, or hide consequential actions inside long workflows. It should also test recovery and audit quality.

If attack success falls while agents retain useful capabilities, confidence in intent-aware controls will strengthen. If improved models remain vulnerable across tool-rich deployments, infrastructure controls will become even more important.

The third signal is enterprise behavior after pilots. Security teams should track how many agents receive unique identities, limited credentials, and defined owners. They should also measure abandoned agents and unreviewed permissions.

Adoption numbers alone reveal little. A company can deploy thousands of agents while keeping them read-only and isolated. A single agent with broad production access may carry greater risk than that entire population.

Incident reports will provide another reality check. Public cases should explain whether failures came from prompt injection, excessive privileges, identity confusion, or missing approval boundaries. Without that detail, the industry cannot compare defenses.

Security leaders should ask direct questions before expanding a pilot:

• Does every agent have a unique identity and accountable owner?

• Can permissions expire automatically when the task ends?

• Do logs retain both the requesting person and acting agent?

• Which tools can create irreversible changes?

• Can external content influence those tool calls?

• What action volume triggers review or suspension?

• Can responders disable one agent without stopping the entire platform?

• Are delegated agents constrained by the original task?

• Does the system fail closed when policy services are unavailable?

• Can auditors reconstruct why a sensitive action occurred?

These questions turn the “on its head” claim into an implementation test. If a platform cannot answer them, its Zero Trust language remains incomplete. If it can, the architecture may already be adapting.

The most important conclusion is that organizations should not abandon Zero Trust. They should apply it to smaller, more dynamic units of authority. Every agent, tool call, delegation, and consequential action deserves its own policy context.

That approach will introduce friction. Some automated tasks will require narrower tools or human confirmation. Some pilots will slow while teams build inventories and lifecycle controls.

The alternative is hidden authority. Agents will inherit broad human permissions, process untrusted content, and leave incomplete records. Security teams will then discover autonomous workflows only after an incident.

Agentic AI has not defeated Zero Trust. It has exposed where many Zero Trust programs stopped at authentication, network access, or device posture. The next version must govern what authenticated machines decide to do.

The question raised through Google News is therefore worth keeping, even if the headline overstates the reversal. Can your organization trace an agent’s identity, purpose, evidence, and authority before its next action executes?

Start with one production workflow and reconstruct that chain from beginning to end. If any handoff becomes invisible, treat it as a control gap. That exercise offers more value than adopting another security label, because it tests whether Zero Trust follows the agent through actual work.