AI agent Zero Trust requires discovery before enforcement
Organizations deploying AI agents should establish visibility before attempting Zero Trust enforcement. Veeam research cited in a security checklist reports that 70% of organizations already have AI workflows interacting with sensitive corporate data without full oversight, while 67% say IT cannot fully track the autonomous workflows employees are building.
The argument is straightforward: an authorization layer or policy proxy cannot effectively control an unknown agent population. An agent with no named owner, defined scope or inventory record leaves security teams unable to determine what it can access, how it is used or whether misuse would be detected.
Shadow AI creates an inventory problem
Unapproved agent deployments can resemble a new form of shadow IT. Blocking unfamiliar tools before establishing a picture of existing use can also interrupt legitimate work, so the recommended operating order is to discover first and restrict later. AI spending, model-provider API-key issuance, procurement records and approved-provider processes can all serve as discovery signals.
An incident involving METR illustrates the exposure. An attacker found an employee's personal EC2 instance running a vibe-coded agentic application, bypassed its authentication and prompted the agent to disclose its model-provider API key. The intruder then used roughly $600,000 in tokens over three weeks. The internal dashboard did not display rate-limited-request data, and token volume alone did not trigger an alert.
No single telemetry source sees every agent
Agents can operate across networks, endpoints, browsers and SaaS platforms. TLS-encrypted traffic can reveal a destination and byte count but not necessarily a prompt, tool call or data exfiltration. Endpoint products can miss browser-embedded AI, while SaaS-embedded functions may be invisible to both endpoint and network monitoring.
A fuller inventory requires correlated evidence. The checklist points to DNS and SNI data, JA4 fingerprints and egress-proxy logs for model-provider activity; endpoint telemetry for processes, environment-variable API keys and local runtimes; browser data for extensions and in-page copilots; and identity or SaaS records such as OAuth grants, provider consoles and API-key issuance. A gateway such as LiteLLM can centralize visibility and governance for connected agents, but it cannot discover agents that are not pointed to it.
Continuous monitoring needs accountable identities
Annual audits become stale quickly when agents can be deployed and cloned in seconds. Short-lived clones may inherit a parent agent's access, perform a task and disappear before a periodic review occurs. Continuous monitoring can improve coverage, but the article stresses that a named person must remain accountable for the result of automated oversight.
The pattern also aligns with Borrowed trust tactics in cybersecurity because inherited access can let a compromised component act with permissions it did not independently earn. Each agent should therefore have a distinct identity, permissions bound to its active task and controls over what data may leave the environment. Logging should capture actions and tool calls, not prompts alone.
For businesses, the immediate implication is to build an accurate, continuously updated agent inventory before relying on gateways, authorization policies or emergency shutoffs. Ownership, identity and correlated telemetry make later enforcement and response controls meaningful.