Picture a support bot that’s been running happily for months. It answers tickets, looks up orders, and now and then issues a small refund. Then a customer pastes a long, oddly worded complaint into the chat. Buried in it is a line telling the bot to ignore its instructions and export the last 500 customer records. Will it actually do it?
The honest answer depends almost entirely on what the bot was allowed to touch in the first place.
That’s the real issue with AI agents. They don’t just chat anymore. They pull data, trigger workflows, and move money inside live systems, usually with nobody checking each step. Our security habits grew up around people: you log in, you get trusted, you get on with your day. An agent doesn’t get tired or nervous, and it never pauses to wonder whether a request smells off. It just does things, very quickly.
Zero trust, the old “never trust, always verify” idea, turns out to fit this mess rather well. Network access control vendor Portnox frames it bluntly: AI doesn’t replace zero trust; it makes it essential. Hard to argue with that.
The login model was built for humans
For decades, access control has worked like a nightclub bouncer. He checks your ID once at the door, and after that you can wander wherever your wristband allows until you leave.
With people, that’s mostly fine. We’re slow and fairly predictable, and we tend to notice when something feels wrong.
Agents break every one of those assumptions. They spawn sub-tasks, call APIs on their own initiative and make dozens of decisions in the time it takes you to finish reading this paragraph. If someone steals an agent’s credentials, or tricks it with a bad prompt, that one ID check at the door is worthless.
And there are a lot of them. CyberArk’s 2025 research counted 82 machine identities for every human one. Some 42% of those machine identities could reach sensitive data, yet 88% of organisations still only call humans “privileged users.” In other words, most companies are guarding the front door while machines with keys to the vault wander around unlisted.
Permission creep is the quiet killer
No one sets out to give an agent sweeping access. It happens gradually. The agent gets hooked up to the CRM, then the ticketing system, then (because somebody needed a quick demo) the billing API. Access gets added and never taken away.
Six months later the agent can do ten times what any single task requires, and the engineer who set it up has moved to another team. Sound familiar? It’s the same sprawl we’ve seen with service accounts for years, only faster.
What the threat lists actually say
OWASP, the nonprofit best known for its web security top tens, published a Top 10 for Agentic Applications for 2026. It makes for slightly grim reading. Here’s how a handful of its entries map onto zero-trust fixes:
| What OWASP warns about | What it looks like on a Tuesday | What helps |
| Agent goal hijack | Hidden instructions in a PDF send the agent off-task | Check each action, require a human on risky ones |
| Tool misuse | The agent fires off emails or edits billing it shouldn’t | Narrow, task-only permissions |
| Identity and privilege abuse | Borrowed credentials quietly widen access | Credentials that expire in minutes |
| Cascading failures | One bad agent sets off three more | Segmentation, rate limits |
| Rogue agents | The agent goes after goals nobody gave it | Behaviour baselines, full logs |
Look down that right-hand column and you’ll notice nothing exotic. It’s mostly old security hygiene, applied to a new kind of user that never sleeps.
So verify every request, not just the first
This is the core of the whole thing. Zero trust doesn’t hand out trust once and walk away. It checks again whenever something meaningful happens, and it looks at the context each time: where the request came from, whether it matches what this agent normally does, and what the risk signals look like right now.
Back to our support bot. It starts the session summarising tickets. Three minutes later, thanks to that poisoned complaint, it’s trying to query the full customer table. A static API key would wave that through without blinking. A per-request check at least has a shot at stopping it.
Practically, most teams start with the dull wins. They kill long-lived API keys first. Those keys end up pasted into config files and old Git repos, and they stay valid long after everyone has forgotten they exist. Swap them for tokens that expire in minutes, or for certificates.
Next, build a rough picture of normal behaviour, so the system can flag it when an agent suddenly pokes at tables it has never touched. Finally, for anything you can’t undo (deleting records, changing payment details, reading personal data), put a human in the loop. Yes, it slows things down a bit. That’s rather the point.
Least privilege, but sized to the job in front of it
Grant the minimum access needed. Every security course teaches this in week one, and almost nobody sticks to it once deadlines bite.
With agents, you can’t really afford to cut corners. Our support bot doesn’t need standing access to every customer account and an unlimited refund button. It needs read access to one customer’s account for the ticket in front of it, plus refund rights up to, say, a fixed modest amount. Both should vanish when the ticket closes, and anything bigger should go to a person.
The industry calls this just-in-time access. The appeal is simple: if someone hijacks the agent, they inherit a tiny, short-lived set of powers instead of the keys to everything.
The rest is housekeeping, frankly. Roles should map to tasks, not to whole departments. Every credential should have an expiry date baked in. Reading and writing should be separate permissions. Someone should actually review the grants now and then and rip out the ones nobody has used.
One more rule matters more than it sounds: every agent needs a named human owner. When an agent belongs to “the team”, it belongs to no one, and nobody notices its access quietly ballooning. If your identity tools only track people, it’s worth checking how identity governance platforms handle non-human identities like service accounts and AI agents these days.
Fence them in
Segmentation splits your network into walled-off zones, so trouble in one corner can’t spread everywhere. With agents moving between systems at machine speed, those walls earn their keep.
The question to ask of every agent is blunt: what can it reach that it has no business reaching? A procurement agent doesn’t need a network path to HR records just because both happen to live on the same infrastructure.
Microsegmentation goes further and draws a fence around individual workloads instead of whole network zones. Don’t forget the outbound side, either. Agents call out to external services in ways that are hard to predict, which is why AI agent network security now leans heavily on egress rules that control where an agent can send data, not only what it can read.
A nice side effect: when an agent lives in a small, tidy segment, weird behaviour sticks out a mile.
Write everything down
None of this holds together without logs. For every action, you want to know what the agent touched, what set it off, and what came out the other end.
It isn’t about keeping auditors happy, although they’ll be pleased too. When something goes sideways, those logs are how you piece together what happened. They also catch slow drift, the agent whose behaviour wanders a little further from its brief each week, long before it does anything dramatic.
Where should your team start?
If your team is staring at a dozen agents and wondering where to begin, don’t overthink it. Track down every agent you’ve got, including the ones somebody knocked together in a low-code tool without telling security (there are always some). Put an owner’s name next to each one. Kill the static keys. Then tighten permissions, fence off the traffic, and switch on logging, roughly in that order, before you hand any agent more freedom.
NIST SP 800-207, the standard reference for zero-trust architecture, still holds up fine here. Agents just stress-test its ideas harder than people ever did.
Will any of this make agents perfectly safe? No. It means you can give them real work without crossing your fingers, and when one does go rogue, the damage stays small.
Related: Identity Governance Solutions: 7 Things to Check Before Choosing
