After spending three days at Identiverse 2026, I heard discussions on security for AI agents, where agent identity is heading, and one question almost everyone I spoke with is still trying to answer.
How do we secure AI agents?
This show built its reputation on workforce identity, single sign-on and access reviews, but there is a new focus this year: AI Agents. And more importantly, how they behave.
How do you give an AI agent an identity?
How do you decide what it’s allowed to touch?
How do you prove, after the fact, that it behaved?
That was the conversation on the main stage, in the breakouts and at most of the booths.
What caught my attention was the language. A year ago, "runtime authorization," "keep the credential away from the agent" and "identity as the control plane" were phrases only a small group of us used while the market conversation was somewhere else. Now they’re everywhere. Keynote after keynote made the case that trust must be decided continuously, at the moment of action, not handed out once and assumed for the rest of the session. After a few years of making that argument, it was satisfying to hear it echoed back. But it also made our jobs harder.
When everyone says the same words, they stop meaning anything to the people who have to act on them
I had a lot of conversations on the show floor that stuck with me more than the keynotes did. Almost everyone was in some stage of an AI rollout. Securing it was a different story. Most of them, across different industries and stages of deployment, admitted they were not sure how they’d do it.
Long after the show buzz fades, these three themes should guide you through securing your AI agents.
1. Every AI agent needs a human behind it
This was the one point nobody argued with. An AI or non-human identity (NHI) must trace back to a named person. Who built it? Who is accountable for it? Whose authority does it borrow when it calls a tool or opens a database connection? The framing I heard most was about lifecycle: When a person leaves, the agents they created should leave with them.
It’s not a new idea. Most enterprises already run dozens of AI agents for every human on staff, and it’s impossible to keep ignoring them. An AI agent with no owner is an agent no one can review, govern or shut off. Assigning human owners to machine and AI identities is how accountability survives once NHIs outnumber people. In most cases, they already do at almost 40 to 1.
2. Discover every AI agent before you grant access
If there was a runner-up theme, it was discovery. Agents are showing up everywhere, often spun up by people outside IT. Many of the sessions and demos focused on finding them before doing anything else. You must be aware of agent registries, shadow AI discovery, inventories that tie an agent back to the systems and data it can reach.
It sounds basic, and it is, but it’s also the step most teams haven’t finished. You cannot put an owner on an agent you have not found, and you cannot authorize an action for one you cannot see. Discovery is becoming the foundation everything else depends on.
3. Use an agent gateway to authorize each action at runtime
The third pattern was architectural, and it was more consistent than I expected. A gateway sits between an agent and the tools, models and APIs it wants to reach, and it authorizes each call at the individual tool level. Allow this one. Step up for that one. Deny the third, on the same connection, in real time. Vendors gave it different names, but the shape repeated often enough to call it an emerging reference architecture. The open-source work here is moving fast, which usually tells you the plumbing is about to become a commodity.
One moment stuck with me: is the cost of getting this wrong in the other direction, by being too restrictive? A CISO from a humanitarian organization that runs blood-manufacturing sites put a number on friction: A control that adds 15 to 30 seconds at the point of access can mean, in a single shift, thousands of units of blood never get processed. Security that slows the mission isn’t free. That’s the bar these agent controls have to clear.
What to ask before you trust an AI agent's security
So the vocabulary converged. Fine. The question to ask when evaluating these tools is no longer whether a vendor says "runtime authorization." It’s whether the product actually enforces a decision the instant an agent acts, and whether the credential to the target system ever lands in the agent’s hands. Many approaches stop at granting access or scoring risk, then trust the downstream system to honor a token. Far fewer sit in the path of the connection, broker it and make sure the agent never holds the key.
That’s the line I watch. Discovery tells you which agents exist, and ownership tells you who answers for them, but the real risk sits in what an agent is allowed to do the moment it acts, and whether it ever touches the live credential. Our approach to securing AI agents starts from a simple position: An agent should get its job done without ever being handed a standing secret.
The industry now agrees on the problem. The future is about who can show that the controls are working.
Secure AI agents without handing them standing secrets
The Delinea Platform gives AI agents the same identity security model it brings to people and machines .
It discovers the agents already running across your environment and ties each one to a named human owner. Credentials stay under centralized control. When an agent acts, the platform authorizes that action at runtime and brokers the connection, so the live credential to the target never reaches the agent. The agent gets least-privilege access and leaves a full audit trail, with no standing secrets behind it for an attacker to find.
Get a personalized demo of the Delinea Platform.
For a closer look at giving agents access without handing over secrets, read our blog: Unlocking AI agents with the Delinea MCP Server.
