Zero Trust for AI Agents Starts With Fixing Zero Visibility

AI agents now touch sensitive data across browsers, cloud accounts, endpoints and SaaS tools. Security teams need an accurate inventory, distinct agent identities and continuous monitoring before they can enforce Zero Trust controls.

AI agents can reach sensitive data before security teams know they exist. A Veeam survey found that 70% of organizations have AI workflows touching corporate data without full oversight, while 67% said IT cannot track all autonomous workflows employees create.

That gap changes the order of an AI security program. Teams need to find agents, identify their owners, map their access and monitor their actions before they add enforcement controls.

The SANS Zero Trust for AI Agents security checklist places inventory and governance before architecture, enforcement, detection and response. The sequence reflects a basic security condition: A policy cannot protect an agent that the organization has not identified.

Shadow AI gives attackers an entry point

Employees can build agentic applications with cloud services, browser tools, local runtimes and model-provider APIs. Security teams may discover those applications only after an attacker finds them.

A reported incident at METR showed how that exposure can develop. An attacker found an employee’s personal Amazon EC2 instance running an agentic application. The attacker bypassed its authentication and prompted the agent to reveal a model-provider API key. The key had no spending limit, and the attacker used $600,000 in tokens over three weeks.

METR’s internal dashboard did not display rate-limited requests. Token volume alone failed to trigger a useful alert, so the organization lacked both ownership and behavior data for the exposed application.

Security teams can borrow discovery methods from cloud security. AWS, Microsoft Azure and other cloud platforms give organizations tools to track accounts, virtual machines, usage and spending. AI programs need the same treatment.

Track model-provider accounts, API-key creation, token use and unusual spending. Ask finance and procurement teams to identify model subscriptions and services that security tools cannot see. Give employees an approved path for building agents before blocking unapproved tools. That approach lets security teams find legitimate projects and bring them under control.

One sensor cannot reveal the full agent population

Agents operate across several layers. A user may install a browser extension, run a local command-line tool, connect a SaaS assistant to a CRM or deploy an application in a cloud account. Each layer exposes different evidence.

Network monitoring sees encrypted connections, destinations and traffic volume. It cannot read a prompt, inspect a tool call or determine whether an agent sent sensitive data. Endpoint tools can show local processes and environment variables, yet they may miss an agent that runs inside a browser. SaaS logs can show OAuth grants and API activity, but they may omit an extension or local runtime that initiated the request.

Consider a marketing analyst who installs a browser tool that summarizes customer records and drafts email. An endpoint agent may not list the tool as a separate process. Network logs may show traffic to a domain that hosts several approved services. The browser tool could hold access to a customer database while security staff remain unaware of it.

Teams need to correlate several data sources. Useful signals include DNS and SNI records, JA4 fingerprints, egress-proxy logs, browser-extension inventories, enterprise-browser records, endpoint processes, environment variables, OAuth grants, API-key issuance and provider audit logs.

Each source fills a different gap. Network data can show that a device contacted a model provider. Endpoint data can reveal a local runtime or exposed key. Browser logs can identify an extension. Identity and SaaS records can show which user granted access to a service.

A gateway can add a policy boundary for known agents. LiteLLM offers an open-source gateway that can centralize model access, logging and policy controls. A gateway governs agents that use it. It cannot discover agents that bypass it, so teams still need an inventory built from several sources.

Periodic audits miss short-lived agents

Traditional audits follow a calendar. Agent deployments can appear, clone themselves and disappear within minutes. An annual review cannot account for an application that existed for a short task months after the review ended.

An attacker who compromises an agent could instruct it to create temporary clones. Those clones might inherit the parent agent’s permissions, perform data theft or call external tools, then terminate before a scheduled audit records them.

Continuous monitoring can narrow that gap. Automated systems can watch for new agents, permission changes, unusual tool calls, short-lived workloads and sudden token use. A human still needs to own the result. Someone must decide whether an alert represents an approved experiment, a misconfigured workflow or an attack.

Quality gates can reduce the risk before deployment. Require each agent to register an owner, purpose, model provider, tool list, data scope and expiration date. Review changes to those fields. Revoke access when an agent reaches the end of its task or loses its owner.

Emergency shutdown controls can help during an incident. A shutdown command only works when the organization can identify the agent, locate its credentials and reach the systems that granted its permissions. Inventory and identity make the control usable.

Give every agent its own identity

Treating an agent as an extension of its creator leaves too much access attached to a human account. An agent needs a distinct identity that records its owner, task, permissions, tools and data boundaries.

Bind access to the active task. Limit the agent’s ability to send data outside the environment. Put an authorization layer between the model and connected services. Give the agent short-lived credentials where the platform supports them, and remove those credentials when the task ends.

Logging must cover actions as well as prompts. Record the tools an agent calls, the resources it accesses, the data it sends, the identity it uses and the decision point that granted access. Prompt logs alone cannot show whether an agent read a customer table, changed a cloud setting or sent a file to an outside service.

Teams also need thresholds tied to identity. A token spike from a known test agent may require a review. The same spike from an unregistered agent may require containment. Without attribution, security staff cannot set a useful baseline or assign responsibility.

A workable Zero Trust program for AI agents follows a clear sequence:

Find agents across cloud accounts, endpoints, browsers, SaaS platforms and model providers.

Assign each agent an owner, identity, purpose and expiration date.

Map tools, credentials, data access and external destinations.

Correlate network, endpoint, browser, identity and SaaS telemetry.

Enforce least privilege through gateways, authorization layers and short-lived credentials.

Monitor tool calls, data movement, token use and permission changes.

Test response controls, including credential revocation and agent shutdown.

Security teams can then measure whether an agent has a valid owner, stays within its task, uses approved tools and sends data to approved destinations. They can also investigate activity that falls outside those limits.

AI agents have compressed the time between deployment and risk. Security programs need to compress the time between deployment and discovery. Inventory gives enforcement a target, identity gives monitoring context and continuous observation gives incident responders a chance to act before a short-lived agent disappears.

Please log in or register to join the discussion