Zero Trust for AI Agents Starts With Fixing Zero Visibility

The way we talk about AI agents is shifting, and the way we implement them requires an even more fundamental shift. While earlier discourse focused on how quickly organizations could stand up agents and how much productivity they could promise, a string of recent incidents, including a widely discussed intrusion at Hugging Face during an evaluation of OpenAI agents, has spurred organizations to examine whether speed has outpaced the ability to secure what gets deployed. Security teams are increasingly asking what an agent can reach once it's running, and whether anyone would notice before it mattered. However tempting it may be to jump directly into enforcement controls and detections, you need to look before you leap.

Research from Veeam reveals that 70% of organizations admit that AI workflows are already in contact with sensitive corporate data without full oversight in place, and 67% report that IT cannot fully track the autonomous workflows that employees are building. Shadow AI is just one of the challenges to visibility of AI agents, but it exemplifies how quickly and pervasively this fundamental first step can slip through your grasp.

Zero Trust principles can support an AI governance program, but only in the right order. "You cannot govern what you cannot see" is the underlying principle right at the top of the SANS cheat sheet, Zero Trust for AI Agents: The Security Checklist. The cheat sheet places inventory ahead of every enforcement control and treats this as a foundational prerequisite for a reason. In practice, organizations may skip to a policy enforcement point or an authorization scheme for an agent that has no named owner, no defined scope, and no entry in any inventory. That order of operations is a diagnosis of where Zero Trust programs can fail. A proxy or an authorization layer sitting in front of an unknown population of agents has nothing real to enforce against.

Here are three visibility challenges to look for, with implications for you to consider when you “Think Red” like an attacker, and the solutions you can employ when you “Act Blue” as an informed defender.

Challenge One: Agent Use Is a New Form of Shadow IT

With any new technology, adoption moves first, and governance follows later, if it follows at all. Once security teams notice this gap, the first instinct is often prevention, which can include blocking unapproved tools, cutting off access, or just shutting down anything unfamiliar. Budget and attention accumulate for these processes first, but blocking things before anyone has a picture of what already exists risks shutting down legitimate use along with the shadow deployments. While the problem of Shadow IT has been acknowledged and addressed in other technologies for a long time, we are still crawling when it comes to doing this for AI.

Think Red: When the agent is effectively invisible to you, an attacker doesn't need to breach much of anything to gain a foothold. A recent example in the news was an incident at METR, the nonprofit known recently for their evaluation of the Hugging Face incident. An attacker discovered an employee’s personal EC2 instance running a vibe-coded agentic app, then trivially bypassed authentication and prompted the agent to hand over its model provider API key. Over three weeks, the intruder used the equivalent of $600,000 in tokens, as there was no spending limit on the API key. METR’s internal dashboard simply didn’t show data on rate-limited requests at all, and token volume alone was not enough to raise any flags.

Act Blue: Cloud technology has experienced these same growing pains, and we can look there for the road to visibility. Every company now has tighter controls around cloud, such as monitoring AWS/Azure usage and spending, and ensuring unused VMs are turned off or destroyed; but nobody does this for agents yet. Treat AI and agent spend, along with API-key issuance, as discovery signals. Finance and procurement are another vantage point that may also be overlooked. Publish an approved-provider path before blocking anything, so legitimate use has somewhere to go, and when it comes the operating order, start with the principle of "know first, then restrict."

Challenge Two: No Single Camera Can Take the Full Picture

Even once an organization commits to discovery, there is no single vantage point that gives you the whole population. Agents live across the network, the endpoint, the browser, and inside SaaS hosted elsewhere, and any one lens leaves large blind spots.

Traffic to AI providers is TLS-encrypted, so an inline sensor sees a destination and a byte count, not a prompt, a tool call, or a data exfiltration, often going to the exact same domains as legitimate apps. Network analysis alone can't tell this apart from anything else on the wire. Endpoint tools miss browser-embedded AI, and SaaS-embedded AI is invisible to both.

Think Red: Imagine a marketing analyst installing a browser tool that summarizes customer records and drafts outbound email. Endpoint tools never see it, since it runs inside the browser. Network monitoring sees only encrypted traffic to a domain that also hosts a dozen sanctioned SaaS products. The tool, and whatever attacker can compromise it, could hold access to a CRM full of sensitive data without anyone else realizing the tool exists.

Act Blue: Recovering visibility means giving up on any single source and instead correlating a variety of sources that each give you a section of visibility. While traffic can camouflage easily or hide in local MCP servers or CLI tools, metadata can tell you something is talking to a model provider, through DNS/SNI, JA4 fingerprints, and egress-proxy logs. Layer your network visibility with endpoint telemetry about processes, API keys sitting in environment variables, or local agent runtimes. Also look for telemetry at the browser level, about extensions, in-page copilots, and enterprise-browser logs, as well as identity and SaaS logs like OAuth grants, API-key issuance, provider admin consoles. When you work to correlate all these signals, they can give you an inventory.

An LLM gateway such as LiteLLM can centralize both visibility and governance by acting as the policy enforcement point the cheat sheet calls for, but it only governs agents already pointed at it, which loops the problem back to our missing inventory. A gateway can control agents you know about, but it doesn't discover the ones you don't.

Challenge Three: Audits Need to Keep Pace With What You’re Auditing

Traditional audits and monitoring are inadequate for maintaining visibility. An annual review can only see assets observed a year ago, which tells you almost nothing. When it takes seconds for agents to get deployed and cloned, by the time a review cycle closes, the inventory it produced is already inaccurate. Continuous monitoring is the most obvious answer, but removing a human from that loop carries its own risk

Think Red: If an organization audits periodically, an attacker could take advantage of this by telling a compromised agent to spawn short-lived clones to complete a task, where each clone inherits the parent's access before it gets terminated. The clones exist just long enough to exfiltrate data or carry out other malicious activities, but they are gone before the regular review would ever see them.

Act Blue: Several changes work together here. You can have humans observe agents and agents observe each other, so your visibility doesn't rest on a single point of failure. Keep in mind, though, if automated systems are watching automated systems, who is accountable? Auditability still needs a named person who is responsible for the outcome, whatever the automation reports. You can mitigate some risk ahead of time with quality gates.

Recent US legislative pressure to institute an emergency shutoff shows that the idea of an “kill switch” for autonomous AI is also being taken seriously. But remember our prerequisite here: Kill switches are only meaningful if you know what to switch off, which brings us back to visibility first.

Agent identity is part of this prerequisite, and it’s what makes your monitoring thresholds meaningful. To echo the cheat sheet again, you cannot threshold what you cannot attribute. Douglas McKee and I raised some concepts that can be helpful here in The Monday Brief on Substack: "Agent tool access must be modeled as a distinct identity and policy enforcement problem, not as an extension of the user who deployed the agent. Give every agent its own identity, bind permissions to the active task, constrain what data may leave the environment, and place an authorization layer between the model and connected services." Logging needs the same shift, from logging prompts alone to recording the tool calls and actions an agent takes.

Where This Puts Your Program

Where visibility appears in your order of operations is the foundation for every other governance step you need to take. Each challenge covered above traces back to this same root: An enforcement layer built before an inventory exists has nothing real to enforce against. Start with discovery, then correlate the sources at your disposal that can each cover part of the picture, and build continuous monitoring around every agent holding its own identity. The full Zero Trust For AI Agents security checklist walks through all three tiers — inventory and governance, architecture and enforcement, and detection and response — in the order they're meant to happen.

For a deeper walkthrough of these controls, join me for SEC530: Defensible Security Architecture and Engineering, Implementing Zero Trust for the Hybrid Enterprise, this December at SANS Cyber Defense Initiative 2026.

Note: This article has been expertly written and contributed by Ismael Valenzuela.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.