We came to the Identiverse 2026 conference in Las Vegas to announce Aembit’s integration with Microsoft Copilot Studio. We left with a clearer picture of where the market actually is on AI agent security – and where it isn’t.
Everyone’s talking about AI agents, and it seemed like every vendor had “agentic” in their pitch (including us: see our IAM for Agentic AI). Attendees were trying to make sense of it all. And underneath the noise, we noticed a gap forming: Most conversations focused on visibility as the answer to the AI agent problem, but visibility is not the same as enforcement.
Is “Agentic AI Security” a Real Category or a Marketing Term?
Attendees seemed to know that “agentic” was something they should be talking about – after all, the term appeared on what felt like half the booth displays on the floor, applied to products ranging from agent-native platforms to SIEM dashboards that simply added an AI tab. Many attendees understood that AI agents were becoming a security issue, but the next step was less clear. One attendee said it best: “It seems chaotic. I’ll just wait for things to calm down.”
That reaction is understandable, but it’s also a risk. The organizations that wait for the market to consolidate before addressing AI agent security are the ones that will spend the next 12 months accumulating agents, credentials, and access paths with no governance model in place. By the time things “calm down,” the problem will be significantly harder to retrofit.
Security teams already know the cost curve here: It is far cheaper to design controls up front than to clean up after a failure. The same is true for AI agent access. The longer teams wait, the more agent access turns from an architecture decision into a cleanup project: more agents in production, more credentials embedded in workflows, more exceptions to unwind, and more business processes built around access patterns that were never governed in the first place.
The chaos on the show floor is a signal – the category is early, the terminology isn’t settled, and the market needs clearer definitions – but the underlying security problem is real.
What’s More Important: Visibility or Enforcement?
The dominant theme among AI security offerings at Identiverse was visibility: discover your agents, map their connections, understand what’s running in your environment. Visibility is an easy pitch to make – after all, how can you solve a problem if you don’t understand its scope? But visibility on its own is insufficient, because it only tells you what’s happening. Enforcement determines what’s allowed to happen.
A security team with excellent visibility into their AI agent landscape – complete maps of which agents are connecting to which resources, detailed dashboards of access patterns – but no runtime enforcement is in a specific kind of precarious position. They have comprehensive documentation of a problem they haven’t solved. In 12 months, that team will have great data on what their agents have been accessing, without being any closer to enforcing their access.
Human IAM didn’t stop at discovery. It built identity verification, access policy, credential management, and audit infrastructure because visibility alone doesn’t constitute control. The same logic applies to agent identity, but most of what was on the floor at Identiverse hasn’t made that leap yet.
What Questions are Buyers Asking About Agentic AI Access?
Finally, the most interesting questions we heard were not only about discovering agents or assigning them identities. They were about what agent access should actually mean in practice: Which tools should an agent be allowed to use? Which actions should be filtered or blocked? How should user context, agent context, and policy shape the decision? When should a human approval be required? And how do you prevent an agent from routing around the control point entirely?
As teams move from AI agent experiments to production deployments, “access” gets more granular: It has to account for the user, the agent, the tool, the action, and the context of the request.
Those questions point to where the market is going. AI agent security is not just an inventory problem, and it is not just an authentication problem. The harder problem is runtime authorization: deciding, at the moment of access, whether a specific agent acting on behalf of a specific user should be allowed to use a specific tool, take a specific action, or reach a specific system.
Why Can’t Agents Be Governed with Human IAM or Workload Identity?
One of the more useful conversations we had at the show was about why existing tools keep getting applied to this problem and why they keep producing gaps.
Human IAM is built around a durable insight: a person needs a documented identity because that identity grants rights to access resources and creates an accountable trail of what was accessed. Remove the identity and you lose both the authorization mechanism and the audit record. That model works well for humans, but AI agents aren’t humans.
An agent needs some of what a human identity provides – documented authorization, access rights, an audit trail – but not all of it, and not in the same form. An agent shouldn’t hold rights indefinitely, and it shouldn’t hold the same scope of rights a human user would need to do a comparable job. An agent that can impersonate a user, access any resource that user could access, and hold those rights across sessions is an agent with too many rights for too long.
Workload identity tooling runs into a different version of the same problem. It works for deterministic software because you can model the access pattern and scope the credential to match it. AI agents make runtime decisions about what to access based on the content of requests. Because their behavior, logic, and access path aren’t fixed, the credential can’t be pre-scoped to fit.
The category that actually addresses these gaps is one that borrows from both disciplines without being reducible to either. Aembit calls this blended identity.
What is a Blended Identity?
Blended identity is an access model that gives agents a verified identity tied to – but distinct from – the associated human user’s session, issues short-lived credentials at runtime scoped to the specific task, and enforces least-privilege at the point of access.
An agent identity that ignores the human user context loses attribution – you know what the agent accessed but not on whose behalf. An agent identity that is simply inherited from the human user collapses the distinction between what the human is authorized to do and what the agent should be permitted to do. Blended identity creates an agent identity based on both the agent context and the user context.
What Now?
If you were at Identiverse and found yourself overwhelmed by the volume of AI security offerings, ask yourself: Does the product govern and enforce what agents can access at runtime, or does it document what they have accessed after the fact? Visibility is a starting point, but enforcement is what actually manages the risk associated with AI agents.
If you’re deploying (or have already deployed) Copilot Studio agents – or Claude, ChatGPT, Gemini, or custom LLMs – and you want a concrete starting point, three resources worth your time:
Check out how Aembit’s blended identity model helps organizations secure Copilot Studio deployments.
The Agentic AI deployment checklist is a platform-agnostic set of questions every security team should answer before AI agents go live – useful whether you’re in early evaluation or already running agents in production.
And if you want to hear Aembit CEO David Goldschlag work through the market dynamics, the identity gap, and a real-world enterprise case study in more depth, his interview with SC Media’s Security Weekly podcast is worth 20 minutes of your time.
The agents are already entering your environment. The question is whether their access model gets designed now or retrofitted later.
