A version of this argument has been sitting on my machine for a few weeks. Then Anthropic published "Zero Trust for AI Agents," and reading it made the whole thing feel timely.
So let me say this clearly before anything else: that eBook is an excellent read. If you design AI systems, lead a security team, or work anywhere in cyber, go read it. It lays out the threats to AI agents well, and it gives you a clear, tiered plan to act on. Nothing here is an attack on it. It is a note the eBook never added, and it is the thing I most want you to walk away thinking about. Because the framework, like almost every framework in this space, assumes you have already done the hard part.
The bottom is lower than they tell you
Every good security plan for AI agents tells you to start at the bottom and work your way up. Foundation first, then Enterprise, then Advanced. Start with the basics, the thinking goes, and add the harder stuff as you grow.
It is good advice. It is also quietly dishonest about where the bottom really is.
Read the current crop of agent security guides closely and you see the same pattern. The "Foundation" tier, the supposed entry point, the floor, asks for short-lived tokens handed out by an identity provider that refresh on their own. A cryptographic identity for every agent. Identity-based isolation, where each service only accepts connections from the exact callers it has been told to trust. Access that is denied by default. All of this is treated as the easy part, the stuff you knock out before the real work starts.
It is not the easy part. It is not even an agent problem. It is the unfinished work of ten years of Zero Trust programs, dressed up as a starting line.
What these guides call Tier 1 sits on top of an unwritten Tier 0: a level of plain, traditional Zero Trust maturity that everyone assumes and nobody names. And the organizations that need the guidance most are exactly the ones that never got there.
The layer below passes nothing up; the layer above inherits it all
Here is how it actually works. An agent does not log in to your systems through some special agent-only door. It uses the same identity setup you already have. It reaches your databases over the same network you already run. It is held back, or not, by the same access controls you already enforce.
So the agent layer inherits every weakness in the layer beneath it, and it inherits them at machine speed. If your agents ride the identity setup you already have, and most will, then any token you cannot hand out and expire for one service account today, you will not be able to hand out for a whole fleet of agents tomorrow. If your network trusts a caller because of where it sits rather than what it can prove, an agent dropped into the right spot is trusted for the same bad reason. The Foundation tier only works if your real foundation, the one built from identity providers, network segmentation, and clean credentials, is already solid.
So the honest question for a security leader is not "can I build the Foundation agent controls?" It is "is my underlying Zero Trust strong enough to hold the agent controls up?" For a lot of organisations the answer is no. And the right first move after reading an agent security guide is not to launch an agent. It is to finish the identity and network work they started years ago and quietly let slide.
The agents do not create that debt. They just make it impossible to ignore.
Three places the floor gives way
The gap is not vague. It opens up in three specific, predictable spots.
The network, where the real world meets cloud-shaped advice. Modern guides now treat network segmentation as a backup plan and put identity-based isolation in charge instead: every workload carries its own cryptographic identity, and services only accept named callers. In a brand-new cloud setup this is fair, because the identity, the control plane, and the policy tools are all sitting there ready to wire together. In the mixed, older setup most companies actually run, it is close to fantasy. You are dealing with old apps that trust a caller based on its IP address, flat networks nobody has dared to rebuild, service accounts with passwords sitting in config files, and internal traffic no one has fully mapped. You usually cannot make a twenty-year-old business system verify a caller's identity by itself. You can sometimes wrap it, putting an identity-aware proxy or a service-mesh sidecar in front so identity is checked at the edge without touching the old code, but that wrap is only as strong as the segmentation that stops traffic going around it, which lands you right back at the same problem. The advice is not wrong. It just assumes a network you do not have.
Identity, where the mess was already winning. Every agent guide depends on being able to tie an action to an actor: a unique ID for each agent, proof of who did what, the ability to filter a log down to one identity. But most companies have never gotten clean control of the non-human identities they already have, with their forgotten service accounts, shared passwords, and an ownership list that is three years out of date. Agents do not ease that pressure. They pour fuel on it. Every agent is a new non-human identity, and they multiply far faster than people ever did, often spinning up short-lived sub-agents that briefly take on their parent's access. If you are already drowning in non-human identities, agents are the wave that closes over your head.
Credentials, where rotation got mistaken for safety. The new Foundation bar throws out static API keys and rotation-only policies. Short-lived credentials handed out by an identity provider are now the price of entry, not the dream. This is right, and it leaves a lot of companies stuck, because their current "good practice" is to rotate a key every ninety days. Rotating a secret that an attacker can find sitting in a file does almost nothing to make the attack harder. But moving from rotation to credentials that truly expire and are tied to an identity is a real project, not a setting you flip. And it has to happen below the agent, before the agent.
Good news, if you already earned it
Turn the warning around and it becomes a reward for the prepared. If you put Zero Trust in place for real, agents do not arrive as a new discipline. They arrive as a new kind of non-human user inside work you already do.
Identity is the clearest case. You onboard an agent through the same identity provider, issue it short-lived tokens from the same source, and run it through the same join-change-leave process you built for people. The access-control model carries over, though you write fresh rules scoped to the exact actions and tools each agent may touch, the idea OWASP calls least agency, rather than reusing human roles. What does not carry over is pace: agents come and go far faster than staff, so quarterly access reviews cannot keep up and governance has to run closer to real time. The other pillars follow suit. Your data classification and DLP already say what an agent must never leak. Your SIEM and baselines already take in behavior, so you add one identity to the picture rather than building a new one. SOAR becomes agentic SOAR, and your acceptable-use and approval rules widen to cover agents instead of being written from scratch.
One honest caveat, on the network. ZTNA closed your user-to-app gap and segmentation cut your blast radius, but neither is the control that matters here. "Accept only the callers you are told to trust" is workload identity: a service mesh with mutual TLS, or SPIFFE-style identities, enforced at the receiving end. Run that east-west and adding an agent is one more rule. Have only ZTNA and segmentation, and this piece is still ahead of you, so do not assume it is in the bag.
For these leaders the move to agents is not a scramble. The unglamorous, years-long work of fixing identity and the network, the work that never made a headline, turns out to have been the agent security program all along. They were building Tier 0 before anyone named it.
The leapfrog, and the trap
There is a way through, and it is worth being clear about it, because the gloomy version of this can leave you frozen, doing nothing.
The starting requirement is not the same everywhere in your environment. Agents are usually brand-new projects, which means you can build them on modern infrastructure even when the rest of the house is a mess. You can stand up a new agent with proper workload identity, short-lived credentials, and identity-based isolation while your older systems stay stuck in the past, as long as you keep what the agent can reach limited to systems that also live in the modern world. A brand-new agent on brand-new infrastructure can skip the old, messy estate entirely.
The trap is the bridge. It is the agent you hand a tool that reaches back into the old world over a connection trusted for no reason other than where it sits. That one agent breaks the boundary you were counting on. It takes the worst habit of the old systems, trusting a caller by location, and hands it to a system that will use it tirelessly, at full speed, and without the second thoughts a person might have before reaching into a system they only half understand. This is exactly where the framework's assumptions and the real world clash hardest, and it is the part most guides skip over.
So the rule is not "lock down everything before you launch a single agent." That advice guarantees you launch nothing. It is tighter and more useful: an agent can only reach as far as the maturity it stands on. Keep what it can touch inside the modern world, and refuse to let any agent bridge into systems that cannot check who is calling. Refuse it in the permissions and the credentials, not in a prompt.
The one test that still works
Most agent guidance assumes infrastructure you may not have. One piece of it does not, and that piece is worth carrying everywhere.
When you weigh up any control, ask one question: does this make the attack impossible, or just annoying? Friction, whether rate limits, extra hops, odd ports, or text-message MFA, falls apart against an attacker with endless patience and almost no cost per try, which is exactly what an AI-driven attacker is. The controls that survive take a capability away rather than slow it down: hardware-bound credentials, tokens that expire, cryptographic identity, network paths that do not exist rather than paths that are merely inconvenient.
The test assumes no particular setup, which is why it holds up in the older world that breaks most of the surrounding advice. Run it across a legacy estate and the answer is uncomfortable: almost everything you have is annoying, not impossible. That discomfort is the point. The test does not fix your foundation. It tells you, honestly, how much of it is real.
Name your Tier Zero
The most useful thing a security leader can do with an agent guide is refuse to read it as a flat shopping list of controls. Read it instead as a maturity model with a hidden bottom rung, and then make that rung visible.
Before the agent program gets a roadmap, write down your Tier 0. Can you hand out and cancel short-lived credentials for a non-human identity today, or can you only rotate long-lived ones? Do you know how many service accounts you have, and who owns each one? Is any part of your environment checking trust at the receiving end, or is it all still trusting the network? Whatever the answers are, they mark your real starting line, not the one printed in the guide.
The organisations that come out ahead in this shift will not be the ones with the smartest agents. They will be the ones honest enough to admit the foundation was never finished, and disciplined enough to build it before they build on top of it. The agents are not the project. They are the push that finally makes the project impossible to put off.
Reference: Anthropic, Zero Trust for AI Agents (2026).