- Zero Trust holds up for AI agents; the common objections point to missing basics, not a broken strategy.
- Agents chaining allowed actions is a permissions problem: switch from just-in-case to just-in-time permissions.
- An agent that is not in your inventory means step 1, defining your Protect Surfaces, was skipped.
- More than 80% of the controls needed to enable AI agents securely already exist.
Zero Trust is still the strategy to follow to combat risks involved with AI. Before I dive deeper into this it is important to recognize there are at least two different perspectives when it comes to AI and security.
Perspective 1
The first one is AI used by an attacker, finding vulnerabilities and exploiting them at machine speed. I wrote about that one in Patching was never the solution and it was never the problem.
Perspective 2
The second one is within organizations that are adopting AI and let agents perform autonomous tasks. This post is focusing on the second one, because I keep reading that Zero Trust would fail on this one.
I would argue the opposite. Zero Trust perfectly holds up. Below you will find some statements that will frequently pop up and I will debunk them.
Statement 1
“The business wants agents faster than security can keep up”
Statement 2
“An agent can chain five allowed actions into something nobody authorized”
Statement 3
“Most agents are not even in your inventory”
Statement 4
“Security gets measured on everything that goes wrong”
Statement 1
“The business wants agents faster than security can keep up”
This one is real, but it is not a Zero Trust problem. It is a priority problem. Security is always weighing your risk against the direction you want to take.
If you have the basics in place, adopting AI agents would not necessarily lead to a security problem, as you can read in the other statements below. However, I'm afraid a lot of companies don't have the basics in place. The good thing is it is never too late to start and this can be done in small steps, even alongside your AI project.
Statement 2
“An agent can chain five allowed actions into something nobody authorized”
This is a good argument. An agent is given intent and if it has the permissions it will do everything in its possibilities to reach its goal: read a document, query the CRM system, create files, send out emails, etc. Every request in itself is fine, but combine them and it might lead to unwanted actions and even data exfiltration.
The given argument here is that Zero Trust is evaluating requests one at a time and that it might be fine at the time of the request, but not during the execution period. The problem here is that the agent had all those permissions.
This is based on the fact that we as humans have just-in-case permissions. Once we need to do something we already have the rights (just in case). This works because we as humans have a conscience and (hopefully) think before we act. An agent does not. This is where we should switch the model to just-in-time permissions: only permissions for what the task needs to run.
Statement 3
“Most agents are not even in your inventory”
If you don't know what agents you have running, or at least have them grouped together, that is a problem. It is however not a failure of Zero Trust. It is not executing step 1 of Zero Trust: define your Protect Surfaces. Build an inventory, know what you have, assign a relevance and risk (CIA) rating to it.
Signal
If you do it well, an unknown agent is isolated. It cannot access other Protect Surfaces and gets the same result as an unknown laptop when Zero Trust is properly implemented.
Statement 4
“Security gets measured on everything that goes wrong”
The statement here is that there is no good way of measuring security and therefore the board doesn't have insights and will choose AI over security, always.
A lot of people still focus on the number of incidents and the number of logs. We have stated for a long time that this is the wrong way to measure security. More events does not mean less secure. On the contrary, it probably means you implemented more controls and now see more of what is happening.
Signal
This is why we report on Zero Trust, implemented Protect Surfaces and implemented controls, because they will tell you how your security posture has improved over time.
What is actually new
I am not saying nothing changes. Agents get spun up and torn down in seconds and they can spawn sub-agents. That means dynamic identities, short-lived credentials and a sub-agent that gets a narrower delegation than its parent, never the full set. These fields are relatively new and not everything has a standard solution yet. Within the Zero Trust strategy, however, it is perfectly clear how you should approach it.
The other thing that stands out more than with humans is audit logging, so you can always see what happened and why.
Conclusion
I would argue that more than 80% of the controls you need to securely enable AI agents in your organization already exist. It is about the (Zero Trust) strategy you take whether these controls are successful or not.
Final signal
The whole debate is not human versus machine. It is non-human identities versus human identities, just-in-time versus just-in-case. Zero Trust already had the answer. Agents only make it urgent.
Get in touch
Is your Zero Trust basis ready for AI agents?
Reach out to discuss how your current Zero Trust controls, Protect Surfaces and permissions hold up once AI agents start acting on your behalf.
Reach outFAQ
Did AI break Zero Trust?
No. Zero Trust perfectly holds up for organizations that adopt AI and let agents perform autonomous tasks. The common objections do not point to a failure of Zero Trust, but to missing basics. It is never too late to start, and this can be done in small steps, even alongside your AI project.
How do you stop an agent from chaining allowed actions into something nobody authorized?
The problem is not that Zero Trust evaluates requests one at a time, but that the agent had all those permissions. Humans work with just-in-case permissions, which works because we think before we act. An agent does not. Switch the model to just-in-time permissions: only permissions for what the task needs to run.
What happens to AI agents that are not in your inventory?
Not knowing which agents you have running means step 1 of Zero Trust was skipped: define your Protect Surfaces. Build an inventory, know what you have and assign a relevance and risk (CIA) rating to it. When Zero Trust is properly implemented, an unknown agent is isolated and cannot access other Protect Surfaces, just like an unknown laptop.
How should you measure security when adopting AI agents?
Not by the number of incidents or logs. More events does not mean less secure; it probably means you implemented more controls and now see more of what is happening. ON2IT reports on Zero Trust, implemented Protect Surfaces and implemented controls, because they show how your security posture has improved over time.
What is actually new about securing AI agents?
Agents get spun up and torn down in seconds and can spawn sub-agents. That means dynamic identities, short-lived credentials and sub-agents that get a narrower delegation than their parent, never the full set. Not everything has a standard solution yet, but within the Zero Trust strategy it is clear how to approach it. Audit logging also matters more than with humans.
Rob Maas is Field CTO at ON2IT, part of the CTO Office under CTO Lieuwe Jan Koning. He works on product strategy and architecture for AUXO, MDR, and ZTaaS, shaping ON2IT's Zero Trust customer journey and AI feature roadmap. He is also a Palo Alto Networks Cyberforce Hero.