You Can't Zero-Trust an Agent You Can't See: Why AI Agent Security Starts With Inventory

As with SaaS a decade ago, people adopt agents long before anyone writes a policy for them. A heavy-handed response — blocking every unapproved AI tool — tends to kill legitimate productivity alongside the risky deployments, and pushes usage further out of sight. The aim should be to discover and govern, not simply to forbid.

The SANS write-up illustrates the cost of getting this wrong with an incident at METR. An employee had stood up a personal cloud instance running an agentic application assembled largely through "vibe coding". A fail-open bug had quietly switched off its authentication, letting an outsider talk to the agent directly and coax it into revealing the model provider's API key. Because that key had no spending cap, roughly $600,000 worth of tokens was burned over about three weeks. The organisation's usage dashboard did not surface the rate-limited requests across all users, and raw token volume never tripped an alert.

The practical fix borrows from cloud hygiene: monitor usage, manage credentials centrally, set spend limits on every key, and decommission what nobody owns. Just as important is offering a sanctioned route for teams that genuinely need agents, so that discovery and enforcement happen together and every agent that surfaces can be tied to an owner, a purpose and a defined set of permissions.

Agents live across several layers at once — the network, the endpoint, the browser and the SaaS platforms they connect to. Look through only one of those and you will miss most of the picture. Consider a marketing analyst who installs a browser extension that summarises customer records and drafts outreach emails. Endpoint tooling may register the extension but not what it does inside the CRM. Network monitoring sees encrypted traffic to a domain that also serves several approved products. Meanwhile the extension may hold standing access to a database full of customer data, and no single tool raises a flag.

Visibility therefore has to be assembled from several sources and correlated. Even without decrypting TLS, network metadata such as DNS and SNI records, JA4 fingerprints and egress proxy logs can point to traffic heading to model providers. Endpoints can reveal agent processes, local runtimes, MCP servers and API keys sitting in environment variables. Browser telemetry shows extensions and in-page copilots. Identity and SaaS logs expose OAuth grants, newly issued keys and activity in AI provider admin consoles. Stitched together, these signals become an inventory.

“

A gateway can only govern the traffic that flows through it. Discovery is what finds the agents that were never routed there.

— Maya Verma, AI Security Lead · Furix Feed

Centralising model access behind an LLM gateway is still worthwhile — it gives you a single place to observe usage and enforce policy. But it only covers agents that already use it. The unknown ones, by definition, do not.

Some agents exist for minutes. A quarterly review cycle can produce an inventory that is out of date before it is even signed off. SANS describes a scenario in which a compromised agent spins up short-lived copies of itself to finish a task; if the runtime lets those clones inherit or reuse the parent's credentials, they can pull data out and vanish long before anyone audits them. The answer is to record lifecycle events continuously — creation, permission changes, delegation and termination — and to use audits to confirm those controls are working rather than to build the inventory from scratch.

Automated monitoring helps, but with a caveat: an AI reviewer looking at manipulated evidence can be fooled just as easily as the agent it is reviewing. Agent actions should be checked against independent sources — identity provider, tool and service logs — and the controls that grant authorisation must sit outside the agent's own reach. Somewhere in the chain there also needs to be a named person accountable for what the agent does, regardless of what the automation reports.

Detection thresholds only mean something when an action can be traced back to a specific agent. That argues for issuing each agent a distinct identity rather than letting it borrow a human's or a shared service account, binding its permissions to the task currently in hand, limiting what data can leave the environment, and placing an authorisation layer between the model and the services it connects to. Logging should shift accordingly: prompts alone tell you what an agent was asked; tool calls and resulting actions tell you what it actually did.

Visibility is not a substitute for Zero Trust controls; it is what makes them meaningful. It supplies the context needed to decide what each agent should be allowed to do and the evidence to confirm it is staying within those bounds. The SANS checklist groups the work into three tracks — inventory and governance, architecture and enforcement, and detection and response — and the key point is that all three must mature together as agent deployments grow, rather than one racing ahead of the others.