Zero Trust AI Agents: How to Discover Shadow Workflows and Control Access

SANS instructor Ismael Valenzuela places an agent inventory at the start of his Zero Trust guidance, ahead of defining permitted actions, authorizing tool calls and monitoring behavior. That order matters to teams administering Windows endpoints, cloud workloads, identity systems and SaaS applications: an access policy has little value if an employee’s browser-based assistant or personal cloud deployment sits outside it.

The visibility gap is measurable—but not universal​

In a Veeam-commissioned survey of 1,000 enterprise IT, data and security decision-makers across Europe, the Middle East and Africa, 70% said automated AI workflows interacted with sensitive corporate data without full oversight. Another 67% said employees created autonomous workflows that IT could not fully track. Censuswide collected the responses in April 2026 from organizations with at least 500 employees. These are respondents’ reports from that region, not a global count of unmanaged agents or proof that every affected workflow leaked data.

The distinction between using an AI service and running an agent is also important. An agent may hold a credential, call connected tools and continue working after the employee who started it has stepped away. Security teams therefore need to identify not just model usage, but the workload and permissions behind it. Valenzuela recommends recording an agent’s purpose and permitted actions when it is onboarded, then checking attempted actions against that scope.

The takeaway: Survey results point to an oversight problem; an inventory turns that broad concern into specific workloads that can be reviewed.

METR’s exposed dashboard shows why attribution matters​

A March 2026 incident described by AI research organization METR offers a concrete example. A researcher ran an agent-orchestration application on a personal Amazon EC2 instance that was meant to be publicly reachable behind Google authentication. A fail-open defect silently disabled that authentication, leaving the application exposed for several days. An attacker prompted an agent to disclose a model-provider API key, added an SSH key for persistent access and used the stolen credential for roughly three weeks. METR estimates that the consumed model credits would have been worth about $600,000; the provider had granted those credits for free, so that figure was not a bill METR paid.

This was an external attacker exploiting an exposed application and stealing a key—not an autonomous agent deciding to attack METR. METR says the researcher lacked access to its more sensitive credentials and that it found no evidence its most sensitive data categories were accessed. It also says some sensitive model-output data was accessible in principle, though it believes attackers did not access it. Those qualifications matter more than a tidy claim of either a confirmed data breach or zero possible exposure.

Why did the usage persist? METR was accustomed to high token volumes and unusual API errors. Its internal dashboard did not show rate-limited requests to all users, and free credits provided no natural spending ceiling. After identifying the source, METR says it stopped and imaged the instance, rotated credentials, expanded monitoring and formalized reviews for researchers’ public applications. The lesson is not simply “alert on big token counts.” An alert needs enough ownership and workload context to distinguish an authorized experiment from credential abuse.

No single console sees every agent​

An agent might run as a cloud application, a local process, a browser extension or a SaaS integration. Each leaves a different trail. Network or proxy records may reveal a destination and traffic volume without exposing an encrypted request’s contents. Endpoint records may identify a local runtime but miss activity contained within a browser or remote service. SaaS and identity records may show an OAuth grant without explaining the workflow that requested it.

For administrators, the useful approach is correlation, not a hunt for one perfect sensor:

• Cloud and provider records: Identify workloads, accounts, issued API keys, usage and unusual spending or request patterns.
• Endpoints and browsers: Review available process, application and extension inventories for tools employees actually use.
• Identity and SaaS records: Connect service permissions and OAuth grants to a human owner and an approved task.
• Network and proxy records: Compare observed destinations with those the agent is expected to contact.

Those are potential evidence sources, not a promise that every organization collects every signal. Procurement and finance records can help expose subscriptions that technical monitoring misses; an approved route for employee experiments gives security teams a better chance of learning about them before they become production dependencies.

A model gateway can help with known, routed traffic. LiteLLM’s documentation, for example, describes virtual-key budget checks, rate limits and usage logging. That can provide a useful control and accounting point. It cannot inventory an agent that calls a provider directly and never passes through the gateway. Nor does governing model requests, by itself, authorize every downstream action an agent takes in a connected tool.

The takeaway: Treat telemetry as overlapping clues. A gateway is a boundary for traffic that uses it, not an organization-wide discovery system.

Make identity useful at the action layer​

A workable inventory should give each production agent an accountable human owner, a defined purpose and a distinct workload identity where the platform supports one. Record its credentials, connected tools, accessible data, permitted destinations and expected lifetime. Review changes to that scope, and remove access when the task ends or the owner leaves.

Then ask the question authentication alone cannot answer: Is this particular action allowed for this particular task? An agent approved to read documents and draft a response should not inherit permission to export a database or send credentials to an unfamiliar destination. Valenzuela recommends placing an authorization point between agents and their tools, defining permitted actions at onboarding and monitoring deviations in request volume, destinations and API-call sequences. Least-privilege permissions and shorter-lived credentials can limit damage if that boundary fails.

Logging should capture consequential actions—not just prompts—including the identity used, tool called, resource accessed and authorization decision. That gives responders a route from a suspicious request to the owner and the credential that must be revoked. Periodic audits still have a place, but they need a continuously updated inventory alongside them: a short-lived workload can appear and disappear between reviews. A rehearsed shutdown process should establish whether responders can locate the agent, stop its workload and revoke access to each connected service.

The sensible sequence is therefore discover, attribute, map access, enforce, monitor and test response. It is less glamorous than buying an “agent security” dashboard and declaring victory. It is also the sequence that gives every later control something real to protect.