AI Agents Are Forcing Zero Trust to Leave the Network
The newest guidance on managing the cyber risk of agentic AI lands on a point enterprise security teams should already be acting on: an AI agent is not just another application user.
It reads untrusted content, forms a plan and uses credentials to act across systems. That combination breaks a comfortable assumption behind many zero trust programmes: that an authenticated identity, inside an approved workflow, is sufficiently predictable.
It is not.
A human employee may have a broad role. A conventional service has a narrow function. An agent occupies an awkward and risky middle ground. It can inherit a person's access, consume a malicious email or document, call a connected tool and keep trying variations of an action. Its identity might be valid while its next step is completely outside the intent of the person who launched it.
That is why the enterprise AI conversation is changing. The question is no longer simply whether the model is approved. It is whether every action the model can trigger is explicitly authorised, bounded and observable.
Zero trust must apply to every tool call
A good zero trust programme asks for verification before access is granted. Agentic AI needs the same principle at a finer level: before every consequential tool call.
Consider an agent that helps a procurement team review supplier contracts. Reading a document and producing a summary is low risk. Creating a draft in the contract system is more consequential. Changing a supplier's payment record, exporting a folder of contracts, or sending a message externally is different again.
Those actions should not be protected by the same standing OAuth grant just because they appear in one workflow.
Treat each action as a decision with five inputs:
- **Agent identity:** Which specific agent and version is making the request?
- **Human and business context:** Who initiated it, and what approved task is it completing?
- **Data context:** What data will be read, written or sent, and how sensitive is it?
- **Tool and environment:** Which connector is involved, and is this a sandbox or production system?
- **Action impact:** Is the request reversible, bounded and internal, or does it change money, permissions, records or external communications?
A policy engine does not need to make every low-risk workflow slow. It does need to distinguish a search from a payment change. If it cannot, the organisation has granted ambient authority: credentials that are technically valid but too broad for the task at hand.
The prompt is not the policy boundary
Teams still try to solve agent risk with better instructions. They write a rule saying, "Never send customer data externally," then connect the agent to email, a file store and a CRM with a long-lived token.
That is direction, not enforcement.
Indirect prompt injection makes the gap obvious. An agent may encounter hostile instructions embedded in a webpage, a ticket, a spreadsheet or a document. Even a well-designed model can be manipulated into choosing an unsafe tool call. The control that matters is not whether the agent was told to behave. It is whether the connector rejects an action that violates the policy.
For high-impact work, move the boundary out of the chat and into identity and access controls. Use dedicated agent identities. Issue short-lived credentials tied to a task. Restrict tool scopes to the smallest useful set. Require an approval checkpoint for actions that are irreversible, externally visible or high value.
This is familiar security engineering. The difference is the speed at which agent builders can now create a workflow that crosses all of these boundaries without opening a traditional change request.
Shadow AI is becoming shadow authority
Most organisations have started their AI governance work by inventorying models and approved chat tools. That remains important. But the harder problem is discovering where AI has acquired authority.
A browser-based assistant that can open a cloud document, a no-code workflow with a mailbox connector, a coding agent using a developer token, and a sales tool that can update a CRM all carry different risks. None need to look like a formal "AI platform" to become production-adjacent.
This is the next form of shadow AI: not just unapproved model use, but unobserved AI-to-system access.
A useful inventory should therefore record more than the vendor and owner. For every agent or AI-enabled workflow, security leaders should be able to answer:
- What data can it access, including through downstream connectors?
- What actions can it perform, and in which environments?
- Which identity, token or delegated user context makes those actions possible?
- What event triggers it, and what untrusted content can influence it?
- What stops it when the task, user access or business approval expires?
If the answer lives only in a vendor admin console or a project owner's memory, governance has not caught up with adoption.
Build an action ledger, not another spreadsheet
The practical answer is an action ledger: a living record that joins discovery, identity, data access, tool permissions and policy decisions. It should show the path from an initiating user and business purpose to the exact action an agent attempted and whether the control allowed, blocked or escalated it.
That gives security teams something they can operate. It supports incident response when an agent behaves unexpectedly. It lets compliance teams demonstrate oversight. And it gives business teams a route to deploy useful agents without waiting for a blanket yes or no.
Start with four action tiers:
1. Read and draft: Allow within approved data boundaries; log it. 2. Recommend: Let the agent prepare a change, but keep execution with a person. 3. Bounded execution: Permit reversible actions with transaction, destination and time limits. 4. High-impact execution: Require an explicit approver and just-in-time authority for money movement, privilege changes, production changes, bulk exports, deletion or external sends.
The important word is execution. A model risk review can tell you whether a tool is suitable. It cannot, on its own, control what a connected agent does at 2am with a valid token.
Make authority visible before it becomes an incident
Agentic AI can make teams much faster. The sensible response is not to ban it, or to force every request through a manual review. It is to make authority deliberate.
Aona helps security and governance teams discover AI use across the environment, identify where agents and tools can touch sensitive data, and apply controls that are enforceable at the data, identity and action layers. [See how Aona approaches AI governance](https://aona.ai/?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust) and [explore our Shadow AI resources](https://aona.ai/resources?utm_source=blog&utm_medium=internal&utm_campaign=agent-zero-trust).
This week's guidance is a useful prompt for a direct question: can your team trace an agent's next consequential action to a named owner, a current approval and a time-bounded permission? If not, you do not yet have zero trust for AI agents. You have trust that has not been tested.
