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.
FAQs
What is blended identity for AI agents?
Blended identity is Aembit’s term for an access model that gives AI agents a verified identity tied to – but distinct from – the associated human user’s session. Rather than inheriting the user’s full access rights or operating with a generic service account, each agent receives short-lived credentials at runtime scoped to the specific task it’s performing. The result is an identity that captures both user context (on whose behalf the agent is acting) and agent context (what the agent itself is authorized to do) – which is what makes attribution in audit logs meaningful.
What’s the difference between AI agent visibility and AI agent enforcement?
Visibility tools discover which agents are running in your environment, map their connections, and log what they’ve accessed. Enforcement tools make runtime decisions about what agents are allowed to access – evaluating each request against a policy before it’s fulfilled. A team with visibility but no enforcement has comprehensive documentation of a problem they haven’t solved. Enforcement is what actually reduces the risk; visibility is a prerequisite, not the destination.
Why doesn’t existing IAM or workload identity tooling cover AI agents?
Human IAM was built for people who authenticate with credentials they control and follow stable, auditable access patterns. Workload identity was built for deterministic software whose access paths can be modeled in advance. AI agents are neither: they make runtime decisions about what to access based on the content of the request they received, so their access patterns can’t be pre-scoped the way a microservice’s can. And unlike humans, they shouldn’t hold rights indefinitely or at the same scope – an agent that can impersonate a user and retain those rights across sessions has too many rights for too long. Blended identity addresses both gaps.
What questions should security teams be asking about AI agent access?
Beyond discovering which agents are running, the questions that matter in production are: 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 access decision? When should a human approval be required? These point to runtime authorization: deciding, at the moment of access, whether a specific agent acting on behalf of a specific user should be permitted to take a specific action. That’s the problem blended identity is designed to solve.
How does Aembit’s blended identity model work with Microsoft Copilot Studio?
Aembit sits between Copilot Studio agents and the enterprise resources they need to reach. When an agent makes a request, Aembit evaluates it against the organization’s access policies – checking agent identity, user context, the resource being requested, and the conditions of the request – and issues a short-lived, scoped credential if the request is authorized. The credential expires when the task is done. Every event is logged with full attribution: which agent, which user session, which resource, which policy decision. See the Secure Copilot Studio use case page for full details.