Identiverse 2026 in Las Vegas put enterprise AI agents at the center of the identity-security debate, with vendors pitching registries, control planes, gateways, and governance fabrics while practitioners pressed a harder question: how do organizations authorize autonomous software that moves across applications at machine speed? The answer emerging from the conference is uncomfortable for anyone hoping for a clean new product category. Agent identity is not a greenfield problem. It is the old IAM mess, accelerated.
The cybersecurity industry has a habit of turning every architectural anxiety into a platform war. Identiverse 2026 appears to have done exactly that for AI agents. Vendors arrived with familiar nouns: fabric, plane, gateway, registry, lifecycle, posture, governance. The packaging was new, but the subtext was ancient: enterprises still struggle to answer who or what is acting inside their systems.
That distinction matters because “AI agent” is not merely a more glamorous name for a bot. A traditional service account typically executes a bounded workflow with predictable permissions. An agent, at least in the way Microsoft, OpenAI, Anthropic, Salesforce, ServiceNow, Workday, and nearly every SaaS vendor now use the term, is expected to reason through tasks, invoke tools, call APIs, delegate work, and act on behalf of users across multiple systems.
That turns identity into the control surface. If an agent can read email, summarize files, update tickets, trigger workflows, and call another agent, then the old question of authentication is no longer enough. The serious question is authorization: should this actor, for this user, in this context, be allowed to perform this action against this destination right now?
The SC Media perspective from Identiverse captured the conference’s most important shift. Day one was about finding agents. Day two was about understanding their authority. Day three was about admitting that the applications receiving those actions are where the real governance problem lives.
But the danger is mistaking a strong starting point for a complete map. Copilot Studio agents are not the entire agent universe. Azure AI Foundry agents are not the entire agent universe. Even Microsoft’s own ecosystem now stretches across Copilot, Security Copilot, Microsoft 365, Teams, Power Platform, Entra, Defender, and partner integrations. The moment an organization assumes that “registered in Entra” equals “governed,” it recreates the same blind spot that has haunted IAM for decades.
The problem gets worse outside Microsoft’s perimeter. Enterprises are already experimenting with Claude, ChatGPT Enterprise, Gemini, internal LangChain-style applications, SaaS-native agents, automation built into CRM and HR platforms, and user-created workflows that never went through a formal identity architecture review. Some will use delegated user credentials. Some will run through API keys. Some will hide behind shared accounts. Some will inherit permissions from the application rather than the directory.
That is why the Identiverse critique lands. Agent registries are necessary, but they mostly describe what the organization already knows enough to register. The frontier risk lives in the messy layer between directories, SaaS apps, local accounts, OAuth grants, API tokens, embedded automation, and business workflows.
That fragmentation was survivable when most access decisions were human-paced. A user requested access, a manager approved it, an entitlement was granted, and a quarterly review eventually asked whether it still made sense. The system was imperfect, but its tempo matched office bureaucracy. Agents break that rhythm.
An agent does not wait for a quarterly certification campaign. It may act continuously, call APIs repeatedly, generate new artifacts, manipulate data, or chain tasks across applications in seconds. If the underlying permissions are stale, excessive, or poorly understood, the agent will not fix them. It will operationalize them.
This is the core lesson from Identiverse: agent governance is not a separate branch of identity. It is a stress test of everything identity programs already failed to normalize. Orphaned accounts, local admin roles, unmanaged service principals, overbroad OAuth consent, API keys in scripts, and unclear application ownership all become more dangerous when autonomous systems can use them at scale.
But discovery has layers. Seeing agents created in a known platform is the easiest version. Seeing service principals tagged as agents is harder. Seeing agent-like behavior from a user’s delegated credentials is harder still. Seeing a SaaS-native agent that never leaves the application’s own permission model may be invisible to the IAM stack entirely.
The SC Media piece argues that the ultimate destination — the application being touched — is where visibility must eventually land. That is correct, and it is also why this problem is so large. Enterprise applications are not passive resources waiting behind a neat identity gateway. They often contain their own roles, groups, permission models, workflows, APIs, audit logs, and local exceptions.
An IAM platform may know that a user authenticated successfully. It may know that an app was accessed. It may not know that the user’s agent exported compensation data, changed a workflow approval rule, generated a customer communication, or triggered a downstream integration. Without application context, “access allowed” can be a dangerously shallow answer.
Delegation has always been a weak point in enterprise identity. “On behalf of” events improve auditability, but they do not automatically preserve intent. If Alice asks an agent to prepare a quarterly account summary, and that agent calls a finance agent, which calls a CRM API, which invokes a workflow in a revenue platform, where does Alice’s intent stop? Which system knows the difference between summarization, modification, exfiltration, and execution?
Traditional audit logs tend to flatten this complexity. They show a user, an app, a token, a time, and sometimes a permission scope. That may be enough for post-incident reconstruction in a simple workflow. It is not enough for real-time authorization in a chain of autonomous actions.
This is where identity teams need to think less like directory administrators and more like transaction-risk engineers. The relevant facts include the user, the agent, the tool, the credential, the data class, the application, the business process, the device posture, the session risk, the delegation chain, and the requested action. Any product that sees only two or three of those facts is a partial control.
That model still matters. It is not obsolete. But it was designed for a world where human actors initiated most meaningful work and where business systems could tolerate slow governance loops. Agents compress those loops.
If an agent can take action every few seconds, stale access becomes active risk. If an agent can interpret broad instructions, over-permissioning becomes unpredictable blast radius. If an agent can use the same credential across multiple systems, credential hygiene becomes an authorization problem rather than merely an authentication concern.
The industry’s answer is moving toward real-time authorization, but that phrase can easily become another slogan. Real-time authorization means the decision is made at the moment of action, using the context of the action, not merely the standing permission assigned months earlier. It means “Can this agent do this?” is answered differently depending on what it is trying to do, which user it represents, what data is involved, and what system will be changed.
That is a harder architecture than agent registration. It also cuts against how many enterprise applications were built. A surprising amount of business software still treats authentication as the major security boundary and internal authorization as a configuration problem. Agentic AI exposes how thin that assumption has always been.
A CRM platform knows who can modify an opportunity. An HR system knows who can view compensation bands. A ticketing system knows who can close incidents. A data platform knows who can query regulated records. The IAM layer may broker access to those systems, but the application often decides what the actor can actually do after entry.
Now add agents. A SaaS vendor may introduce its own native assistant. A business unit may connect a third-party agent through OAuth. A power user may build an automation that calls APIs under their account. A developer may wire an internal agent to a service account. Each path may be reasonable in isolation. Together, they produce a governance surface that no single registry can fully describe.
This is why application-level telemetry becomes central. The decisive evidence is not merely that an agent exists. It is what the agent did, which authority it used, what data it touched, and whether the action matched the user’s role, business intent, and risk posture.
Some of those claims will be true. None will be sufficient alone.
The winning control plane is unlikely to be a single pane of glass in the old marketing sense. Enterprises have heard that promise too many times. More plausibly, the winning architecture will combine identity records, application telemetry, policy decision points, privilege controls, audit trails, data classification, and workflow context. It will need to interoperate because the agent universe will not belong to one vendor.
Microsoft has a strong position because Windows, Microsoft 365, Entra, Defender, Copilot Studio, Power Platform, and Azure AI Foundry give it deep enterprise reach. But even Microsoft cannot see every SaaS permission, every local application role, every third-party agent, every API key, or every delegated workflow by default. The same limitation applies to every other platform vendor.
That is the practical message for WindowsForum readers managing real environments: do not buy the slide that says the registry is the control plane unless it also explains how decisions are enforced at the application and API layer. Inventory is the beginning. Authorization is the fight.
That puts pressure on familiar admin practices. Consent policies matter more. App registrations matter more. Service principals matter more. Conditional Access exclusions matter more. SharePoint oversharing matters more. Power Platform environment governance matters more. The permissions that once looked like harmless convenience can become fuel for automated action.
It also changes how admins should think about user training. The old advice — do not click suspicious links, do not approve strange prompts, report phishing — remains necessary. But users may soon be asked to approve agents, connect tools, delegate access, or authorize workflows they barely understand. Consent becomes a business-risk decision disguised as a productivity feature.
The most mature organizations will treat agent rollout like a privileged-access and application-governance program, not like a chatbot deployment. That means defining who can create agents, where they can run, what data they can reach, how they are reviewed, how they are revoked, and how their actions are logged. It also means preparing for incidents in which the agent did exactly what it was technically allowed to do, but not what the business intended.
Agents blur the line between workload identity and user delegation. Sometimes they will act as themselves. Sometimes they will act for a user. Sometimes they will use an application permission. Sometimes they will carry delegated scopes. Sometimes the same workflow may involve all of the above.
That creates a governance problem that cannot be solved by simply labeling agents as “non-human identities.” A database service account does not have intent. An agent is designed to interpret intent. That makes provenance, delegation, and policy enforcement far more important.
Security teams should therefore resist two bad shortcuts. The first is treating agents as ordinary apps with a prettier interface. The second is treating them as digital employees with a simple owner field and a lifecycle workflow. They are neither. They are software actors that can exercise authority through multiple identity paths, and the governance model has to reflect that.
A file read becomes exposure. A CRM update becomes customer impact. A payroll query becomes privacy risk. A workflow change becomes process manipulation. A ticket closure becomes operational risk. Identity systems can describe the actor, but applications describe the effect.
This is where many zero-trust programs remain underdeveloped. They enforce stronger authentication, device compliance, network conditions, and session policies, but they often stop short of fine-grained, action-aware authorization inside core business applications. Agents make that gap impossible to ignore.
The next phase of identity security will therefore be less glamorous than the keynote language suggests. It will involve mapping application entitlements, cleaning up local roles, reducing standing privilege, governing OAuth grants, monitoring API usage, classifying sensitive actions, and building policy enforcement points closer to business systems. In other words, the future of AI security may look suspiciously like finally doing the IAM homework enterprises postponed for twenty years.
The Agent Boom Has Found Its First Security Bottleneck
The cybersecurity industry has a habit of turning every architectural anxiety into a platform war. Identiverse 2026 appears to have done exactly that for AI agents. Vendors arrived with familiar nouns: fabric, plane, gateway, registry, lifecycle, posture, governance. The packaging was new, but the subtext was ancient: enterprises still struggle to answer who or what is acting inside their systems.That distinction matters because “AI agent” is not merely a more glamorous name for a bot. A traditional service account typically executes a bounded workflow with predictable permissions. An agent, at least in the way Microsoft, OpenAI, Anthropic, Salesforce, ServiceNow, Workday, and nearly every SaaS vendor now use the term, is expected to reason through tasks, invoke tools, call APIs, delegate work, and act on behalf of users across multiple systems.
That turns identity into the control surface. If an agent can read email, summarize files, update tickets, trigger workflows, and call another agent, then the old question of authentication is no longer enough. The serious question is authorization: should this actor, for this user, in this context, be allowed to perform this action against this destination right now?
The SC Media perspective from Identiverse captured the conference’s most important shift. Day one was about finding agents. Day two was about understanding their authority. Day three was about admitting that the applications receiving those actions are where the real governance problem lives.
Microsoft’s Agent ID Is Useful, but It Is Not the Finish Line
Microsoft has become one of the clearest examples of both the promise and the limits of first-generation agent identity. Entra Agent ID and Copilot Studio integration give organizations a way to assign identities to agents, register them, associate them with owners, and bring some familiar Entra controls into the agent world. For Microsoft-centric shops, that is not trivial. It gives admins a vocabulary and a console path where previously there was a fog of service principals, app registrations, delegated permissions, and end-user automation.But the danger is mistaking a strong starting point for a complete map. Copilot Studio agents are not the entire agent universe. Azure AI Foundry agents are not the entire agent universe. Even Microsoft’s own ecosystem now stretches across Copilot, Security Copilot, Microsoft 365, Teams, Power Platform, Entra, Defender, and partner integrations. The moment an organization assumes that “registered in Entra” equals “governed,” it recreates the same blind spot that has haunted IAM for decades.
The problem gets worse outside Microsoft’s perimeter. Enterprises are already experimenting with Claude, ChatGPT Enterprise, Gemini, internal LangChain-style applications, SaaS-native agents, automation built into CRM and HR platforms, and user-created workflows that never went through a formal identity architecture review. Some will use delegated user credentials. Some will run through API keys. Some will hide behind shared accounts. Some will inherit permissions from the application rather than the directory.
That is why the Identiverse critique lands. Agent registries are necessary, but they mostly describe what the organization already knows enough to register. The frontier risk lives in the messy layer between directories, SaaS apps, local accounts, OAuth grants, API tokens, embedded automation, and business workflows.
IAM’s Original Sin Is Becoming the Agent Era’s Inheritance
The identity industry has spent years trying to retrofit order onto environments that were never designed around a single control plane. Active Directory, Entra ID, Okta, SailPoint, CyberArk, Ping, Duo, device management, SaaS admin consoles, local app roles, shadow IT, privileged accounts, and legacy databases all carry some part of the truth. No one system sees everything.That fragmentation was survivable when most access decisions were human-paced. A user requested access, a manager approved it, an entitlement was granted, and a quarterly review eventually asked whether it still made sense. The system was imperfect, but its tempo matched office bureaucracy. Agents break that rhythm.
An agent does not wait for a quarterly certification campaign. It may act continuously, call APIs repeatedly, generate new artifacts, manipulate data, or chain tasks across applications in seconds. If the underlying permissions are stale, excessive, or poorly understood, the agent will not fix them. It will operationalize them.
This is the core lesson from Identiverse: agent governance is not a separate branch of identity. It is a stress test of everything identity programs already failed to normalize. Orphaned accounts, local admin roles, unmanaged service principals, overbroad OAuth consent, API keys in scripts, and unclear application ownership all become more dangerous when autonomous systems can use them at scale.
Visibility Is the Easy Part, and Even That Is Hard
The first wave of agent-security products naturally starts with discovery. That is sensible. You cannot govern what you cannot see, and many enterprises probably do not know how many agents, bots, automations, scripts, copilots, plug-ins, and service identities are already operating across their estate.But discovery has layers. Seeing agents created in a known platform is the easiest version. Seeing service principals tagged as agents is harder. Seeing agent-like behavior from a user’s delegated credentials is harder still. Seeing a SaaS-native agent that never leaves the application’s own permission model may be invisible to the IAM stack entirely.
The SC Media piece argues that the ultimate destination — the application being touched — is where visibility must eventually land. That is correct, and it is also why this problem is so large. Enterprise applications are not passive resources waiting behind a neat identity gateway. They often contain their own roles, groups, permission models, workflows, APIs, audit logs, and local exceptions.
An IAM platform may know that a user authenticated successfully. It may know that an app was accessed. It may not know that the user’s agent exported compensation data, changed a workflow approval rule, generated a customer communication, or triggered a downstream integration. Without application context, “access allowed” can be a dangerously shallow answer.
Delegation Is Where the Audit Trail Starts to Fray
The most interesting question in the Identiverse commentary is also the most awkward: what happens when a user runs an agent that runs another agent? This is not a philosophical edge case. It is the inevitable operating model of agentic software.Delegation has always been a weak point in enterprise identity. “On behalf of” events improve auditability, but they do not automatically preserve intent. If Alice asks an agent to prepare a quarterly account summary, and that agent calls a finance agent, which calls a CRM API, which invokes a workflow in a revenue platform, where does Alice’s intent stop? Which system knows the difference between summarization, modification, exfiltration, and execution?
Traditional audit logs tend to flatten this complexity. They show a user, an app, a token, a time, and sometimes a permission scope. That may be enough for post-incident reconstruction in a simple workflow. It is not enough for real-time authorization in a chain of autonomous actions.
This is where identity teams need to think less like directory administrators and more like transaction-risk engineers. The relevant facts include the user, the agent, the tool, the credential, the data class, the application, the business process, the device posture, the session risk, the delegation chain, and the requested action. Any product that sees only two or three of those facts is a partial control.
Static Entitlements Cannot Keep Up with Machine-Speed Workflows
Enterprise IAM was built around a relatively static model of authority. Users have roles. Roles contain entitlements. Entitlements grant access. Reviews periodically clean up the worst excesses. Privileged access tools add time-bound elevation for sensitive systems. Conditional Access and zero-trust policies improve the front door.That model still matters. It is not obsolete. But it was designed for a world where human actors initiated most meaningful work and where business systems could tolerate slow governance loops. Agents compress those loops.
If an agent can take action every few seconds, stale access becomes active risk. If an agent can interpret broad instructions, over-permissioning becomes unpredictable blast radius. If an agent can use the same credential across multiple systems, credential hygiene becomes an authorization problem rather than merely an authentication concern.
The industry’s answer is moving toward real-time authorization, but that phrase can easily become another slogan. Real-time authorization means the decision is made at the moment of action, using the context of the action, not merely the standing permission assigned months earlier. It means “Can this agent do this?” is answered differently depending on what it is trying to do, which user it represents, what data is involved, and what system will be changed.
That is a harder architecture than agent registration. It also cuts against how many enterprise applications were built. A surprising amount of business software still treats authentication as the major security boundary and internal authorization as a configuration problem. Agentic AI exposes how thin that assumption has always been.
SaaS Is the New Identity Dark Matter
The phrase identity dark matter has usually referred to accounts, entitlements, and access paths that exist outside formal governance. In the agent era, SaaS applications may become its richest habitat. That is not because SaaS vendors are uniquely careless. It is because SaaS is where business process lives.A CRM platform knows who can modify an opportunity. An HR system knows who can view compensation bands. A ticketing system knows who can close incidents. A data platform knows who can query regulated records. The IAM layer may broker access to those systems, but the application often decides what the actor can actually do after entry.
Now add agents. A SaaS vendor may introduce its own native assistant. A business unit may connect a third-party agent through OAuth. A power user may build an automation that calls APIs under their account. A developer may wire an internal agent to a service account. Each path may be reasonable in isolation. Together, they produce a governance surface that no single registry can fully describe.
This is why application-level telemetry becomes central. The decisive evidence is not merely that an agent exists. It is what the agent did, which authority it used, what data it touched, and whether the action matched the user’s role, business intent, and risk posture.
The Vendor Race Will Reward Whoever Integrates, Not Whoever Renames
The agent-governance market is going to be noisy. Identity vendors will extend IGA and IAM. Privileged-access vendors will frame agents as non-human identities. CASB and SSE vendors will pitch traffic-level controls. API-security vendors will watch tool calls. SaaS-security posture tools will inspect application permissions. Observability vendors will follow event chains. Cloud providers will insist their native registries are the natural home.Some of those claims will be true. None will be sufficient alone.
The winning control plane is unlikely to be a single pane of glass in the old marketing sense. Enterprises have heard that promise too many times. More plausibly, the winning architecture will combine identity records, application telemetry, policy decision points, privilege controls, audit trails, data classification, and workflow context. It will need to interoperate because the agent universe will not belong to one vendor.
Microsoft has a strong position because Windows, Microsoft 365, Entra, Defender, Copilot Studio, Power Platform, and Azure AI Foundry give it deep enterprise reach. But even Microsoft cannot see every SaaS permission, every local application role, every third-party agent, every API key, or every delegated workflow by default. The same limitation applies to every other platform vendor.
That is the practical message for WindowsForum readers managing real environments: do not buy the slide that says the registry is the control plane unless it also explains how decisions are enforced at the application and API layer. Inventory is the beginning. Authorization is the fight.
Windows Shops Will Feel This First Through Microsoft 365
For many organizations, the agent-governance problem will arrive not as an abstract AI architecture debate but as a Microsoft 365 administration problem. Copilot, Teams apps, SharePoint content, Outlook data, Power Platform connectors, Graph permissions, and Entra policies are already close to the daily work of Windows administrators. Agents will simply increase the number of actors trying to use those surfaces.That puts pressure on familiar admin practices. Consent policies matter more. App registrations matter more. Service principals matter more. Conditional Access exclusions matter more. SharePoint oversharing matters more. Power Platform environment governance matters more. The permissions that once looked like harmless convenience can become fuel for automated action.
It also changes how admins should think about user training. The old advice — do not click suspicious links, do not approve strange prompts, report phishing — remains necessary. But users may soon be asked to approve agents, connect tools, delegate access, or authorize workflows they barely understand. Consent becomes a business-risk decision disguised as a productivity feature.
The most mature organizations will treat agent rollout like a privileged-access and application-governance program, not like a chatbot deployment. That means defining who can create agents, where they can run, what data they can reach, how they are reviewed, how they are revoked, and how their actions are logged. It also means preparing for incidents in which the agent did exactly what it was technically allowed to do, but not what the business intended.
Security Teams Need to Stop Treating Non-Human Identity as a Side Quest
Non-human identity has long been the neglected sibling of workforce identity. Service accounts, workload identities, machine certificates, automation accounts, API tokens, and secrets often receive less lifecycle discipline than human users. That neglect was risky before agents. It is reckless after them.Agents blur the line between workload identity and user delegation. Sometimes they will act as themselves. Sometimes they will act for a user. Sometimes they will use an application permission. Sometimes they will carry delegated scopes. Sometimes the same workflow may involve all of the above.
That creates a governance problem that cannot be solved by simply labeling agents as “non-human identities.” A database service account does not have intent. An agent is designed to interpret intent. That makes provenance, delegation, and policy enforcement far more important.
Security teams should therefore resist two bad shortcuts. The first is treating agents as ordinary apps with a prettier interface. The second is treating them as digital employees with a simple owner field and a lifecycle workflow. They are neither. They are software actors that can exercise authority through multiple identity paths, and the governance model has to reflect that.
The Application Layer Is Where Theory Meets Consequence
The strongest claim in the SC Media commentary is that agent governance must observe agents at every application they touch. That may sound operationally brutal, but it is hard to argue with. The destination application is where abstract permission becomes concrete consequence.A file read becomes exposure. A CRM update becomes customer impact. A payroll query becomes privacy risk. A workflow change becomes process manipulation. A ticket closure becomes operational risk. Identity systems can describe the actor, but applications describe the effect.
This is where many zero-trust programs remain underdeveloped. They enforce stronger authentication, device compliance, network conditions, and session policies, but they often stop short of fine-grained, action-aware authorization inside core business applications. Agents make that gap impossible to ignore.
The next phase of identity security will therefore be less glamorous than the keynote language suggests. It will involve mapping application entitlements, cleaning up local roles, reducing standing privilege, governing OAuth grants, monitoring API usage, classifying sensitive actions, and building policy enforcement points closer to business systems. In other words, the future of AI security may look suspiciously like finally doing the IAM homework enterprises postponed for twenty years.
The Las Vegas Lesson for Admins Is Smaller Than the Hype and Bigger Than the Product
The immediate lesson from Identiverse is not that every enterprise needs to buy an agent-governance platform tomorrow. It is that agentic AI collapses several slow-moving identity problems into one urgent operating risk. The practical work starts with discovery, but it cannot end there.- Organizations should inventory agents across Microsoft platforms, third-party AI services, SaaS applications, internal development frameworks, and user-created automation rather than limiting discovery to a single registry.
- Security teams should distinguish between an agent’s identity, its owner, its delegated user, its credential path, and the application authority it can actually exercise.
- Administrators should review OAuth consent, app registrations, service principals, API keys, Power Platform connectors, and SaaS-native automation before broad agent deployment accelerates existing sprawl.
- Governance teams should move from periodic entitlement review toward action-aware authorization for high-risk applications, APIs, and data classes.
- Incident responders should prepare for chains of delegation where a human instruction, an agent decision, and a downstream tool action all appear in different logs.
- Buyers should pressure vendors to explain how their agent controls work outside their own ecosystem and how they enforce decisions at the application layer.
References
- Primary source: SC Media
Published: 2026-06-22T11:00:14.032101
Lessons from Identiverse 2026 | perspective | SC Media
The big lesson: too many organizations still don’t understand how identity works inside their applications.www.scworld.com