Linx Blog

Identiverse has always been one of the best places to understand where the identity market is headed. This year, the conversations felt especially clear: identity teams are being asked to govern more identities, more access, and more risk than ever before.

Across sessions, booth conversations, customer meetings, and hallway discussions, one theme kept coming up. Identity is expanding beyond the workforce. It now includes non-human identities, AI agents, autonomous workflows, and new access paths that many organizations are still learning how to control.

For Linx, Identiverse was an opportunity to listen, learn, and share what we have been building. We talked with identity leaders about modern IGA, AI governance, MCP, non-human identity security, user access reviews, and the future of real-time identity governance.

Here are the biggest themes we heard.

1. Identity Is Expanding Beyond Humans

For years, identity governance centered around employees, contractors, partners, and privileged users. That work is still critical, but the identity landscape has changed.

Organizations are now managing service accounts, API keys, machine identities, cloud roles, AI agents, and autonomous systems. These identities may not sit in HR systems or follow traditional joiner, mover, leaver processes, but they still hold access to business-critical applications, sensitive data, and production environments.

One identity leader at a Fortune 100 enterprise put it simply:

"Five years ago, my biggest concern was making sure the right people had the right access. Now I'm asking how many AI agents exist in my environment, what they're connected to, and who is responsible for them. The challenge isn't just governing people anymore."

That shift came up constantly. Identity leaders are not just asking who has access anymore. They are asking what has access, how that access was granted, whether it is still appropriate, and how it can be governed consistently.

This is why conversations around identity governance, non-human identities, and AI identity governance are becoming increasingly connected. Organizations do not want separate programs for every new identity type. They want one identity strategy that can scale across humans, non-human identities, and AI agents.

2. AI Governance Has Moved From Theory to Reality

Last year, many AI governance conversations were still hypothetical. This year, they felt much more practical.

Security and identity teams are no longer only asking whether employees are using AI tools. They are asking how AI agents interact with enterprise systems, how access should be granted, how policies should be enforced, and who is accountable when an autonomous system takes action.

A security architect at a global financial services organization shared one of the clearest versions of the challenge:

"We know how to review employee access. We know how to review service accounts. But when an AI agent is connected to multiple systems and making decisions on behalf of users, the question becomes: who owns it, who reviews it, and who is accountable when something goes wrong?"

That is where AI governance becomes an identity governance issue. The challenge is not simply whether AI is safe. The challenge is whether organizations have the visibility, policy controls, and accountability needed to govern AI-driven access, and the AI access control tools required to do so.

The Four Questions Every Identity Leader Is Asking About AI Agents

As organizations move from AI experimentation to production deployments, the conversation is increasingly shifting from innovation to governance.

Across sessions, roundtables, and customer conversations, four questions surfaced repeatedly:

• Who should have access to AI agents?
• What actions should AI agents be allowed to perform?
• How should organizations enforce policy across AI-driven workflows?
• How do organizations maintain accountability for decisions made by autonomous systems?

These are fundamentally identity governance questions, which is why AI governance and identity security are becoming increasingly intertwined.

3. Why MCP Became Part of the Identity Conversation

Model Context Protocol, or MCP, came up in more conversations than many people expected.

That is not because identity leaders suddenly became focused on protocols for the sake of protocols. It is because MCP represents a much larger shift in how AI agents connect to enterprise systems. As organizations begin using MCP-connected applications and AI-driven workflows, they need to understand what agents can access, what actions they can take, and how those actions are governed.

One identity architect at a global technology company told us:

"MCP came up in more conversations than I expected. Organizations are excited about the possibilities, but they're also asking the same questions we ask about every new identity surface: who has access, what can it do, and how do we control it?"

That is exactly the conversation identity teams should be having.

MCP creates enormous potential for AI adoption, but it also introduces new governance requirements. If an AI agent can connect to business applications, retrieve data, invoke tools, and take action, then organizations need visibility and control over that activity. They need to know what the agent is doing before it becomes a blind spot.

This is why we announced the Linx MCP Gateway. The goal is to help organizations govern AI agents and MCP-connected systems with the same identity-first approach they already use for human and non-human identities.

4. Real-Time Governance Is Replacing Periodic Governance

Another major theme at Identiverse was the move from periodic governance to continuous governance.

Traditional identity governance has often been built around scheduled access reviews, quarterly certifications, and point-in-time reporting. Those processes still matter, especially for compliance. But identity leaders are increasingly looking for governance programs that can keep pace with how modern environments actually operate.

Access changes constantly. People move teams. Contractors leave. Service accounts accumulate privileges. AI agents connect to new systems. Permissions drift. Risk changes faster than quarterly review cycles can capture.

That is why so many conversations at Identiverse centered on real-time visibility, automated remediation, continuous controls, and AI-powered decision support.

Identity governance is no longer just about proving that a review happened. It is about knowing what changed, understanding why it matters, and taking action before risk accumulates.

This is also where Autopilot resonated with many of the identity leaders we spoke with. The idea of moving from manual identity work to autonomous identity security is becoming less futuristic and more necessary.

5. Organizations Want One Identity Strategy

One of the most consistent takeaways from Identiverse was that identity teams do not want another silo.

They do not want one process for workforce identities, another for non-human identities, another for AI agents, and another for privileged access. They want a unified identity strategy that gives them visibility and control across the full identity landscape.z

One of the customers who joined us on stage summarized this well:

"We've spent years building governance processes for our workforce identities. Now we're applying those same principles to non-human identities and AI agents. The biggest lesson for us has been that these shouldn't be treated as separate problems. The more we can govern everything through a single identity strategy, the easier it becomes to maintain visibility, reduce risk, and operate efficiently."

That point captures where the market is headed.

The future of identity security is not about adding more disconnected tools. It is about building a governance model that can support every identity type across the enterprise. Humans, non-human identities, and AI agents all represent access paths into critical systems. They should be governed with the same level of visibility, accountability, and control.

For us, this is the larger story behind what we shared at Identiverse. MCP Gateway, AI Access Control, Autopilot, and our broader identity governance platform are all part of the same mission: helping organizations govern every identity from one place.

The Future of Identity Security Is Already Here

If there was one thing Identiverse 2026 made clear, it's that the future of identity security isn't something organizations need to prepare for years from now. It's already here.

AI agents, MCP-connected systems, non-human identities, real-time governance, and autonomous workflows are no longer emerging concepts. They're actively changing how organizations think about access, risk, and identity governance today. The challenge for identity leaders is no longer whether these technologies will become part of their environment. It's how quickly they can build the visibility, controls, and governance frameworks needed to manage them.

That's why so many of the conversations we had at Identiverse ultimately pointed back to identity. Whether the topic was AI governance, MCP security, user access reviews, non-human identities, or compliance, the underlying challenge was the same: understanding who or what has access, what they can do, and how that access should be governed.

At Linx, that's exactly the problem we're focused on solving. From modern identity governance and AI-powered access reviews to AI Access Control, MCP Gateway, and Autopilot, we're helping organizations govern human, non-human, and AI identities through a single platform and a single identity strategy.

The future of identity security will belong to organizations that can unify governance across every identity type. Based on what we heard at Identiverse, that future is arriving faster than most people expected.

If you'd like to see how Linx is helping organizations tackle these challenges, schedule a demo with our team. We'd love to continue the conversation.

FAQ

What were the biggest identity security trends at Identiverse 2026?

The biggest themes we heard were AI governance, non-human identity governance, MCP security, real-time identity governance, and the need for unified visibility across human, non-human, and AI identities.

How is AI changing identity governance?

AI is changing identity governance by introducing new identity types, including AI agents and autonomous workflows. These systems can access applications, retrieve data, invoke tools, and take action, which means they need the same visibility, policy enforcement, and accountability as other identities.

What is MCP and why does it matter for identity security?

Model Context Protocol, or MCP, helps AI agents connect to tools and enterprise systems. From an identity security perspective, MCP matters because it creates new access paths that organizations need to govern, monitor, and control.

What is AI access control?

AI Access Control is the ability to govern what AI agents can access, what actions they can take, and how those actions are monitored and enforced. It extends identity governance principles to AI agents and autonomous systems.

What is agentic identity governance?

Agentic identity governance refers to the governance of AI agents as part of the broader identity landscape. It focuses on visibility, ownership, access control, policy enforcement, and auditability for AI-driven identities.

How can organizations govern AI agents?

Organizations can govern AI agents by inventorying where agents exist, understanding what systems they can access, enforcing least privilege, reviewing agent permissions regularly, monitoring activity, and applying policy controls through platforms like Linx MCP Gateway and AI Access Control.

MCP gateways give enterprises a control point for AI agent traffic, but authentication and routing alone don't solve the deeper governance problem: knowing who is behind an agent, what it should actually be allowed to do, and maintaining a full audit trail tied to real human identities. Without tool-level enforcement, identity lifecycle management, and inline real-time inspection, organizations end up with agents that have far broader access than any individual person they represent, no deprovisioning process when that person leaves, and no attributable record of what the agent did in their name.

Your MCP Gateway Has an Identity Blind Spot

AI agents have moved from pilots to production. They are no longer summarizing documents or drafting emails — they are reading records, writing data, querying databases, and calling APIs inside the systems your business runs on. The Model Context Protocol (MCP) is the most popular way to connect them to those systems, and an MCP gateway is the control plane that sits in between.

But here's what most security teams discover after deploying one: a gateway alone doesn't provide you with governance. It handles authentication and enforces rules. What it doesn't answer are the identity questions that actually keep CISOs up at night — who is this agent acting on behalf of, what should it be allowed to do, and what did it actually do? Those are identity problems. And most MCP gateways weren't built to solve them.

What Is an MCP Gateway?

An MCP gateway is a control plane that sits between AI clients — Claude, Cursor, ChatGPT, internal agent frameworks — and the MCP servers those clients connect to. Every tool call an agent makes passes through it. The gateway's job is to enforce who can reach what, inspect traffic in both directions, log activity, and route requests to the right upstream system.

Think of it as the equivalent of an API gateway, but purpose-built for the MCP protocol. Where a generic API gateway understands HTTP methods and endpoints, an MCP gateway understands tool calls, resource requests, and the context in which agents invoke them. That protocol-level awareness is what separates a real gateway from a proxy with some auth bolted on.

How an MCP Gateway Works

An MCP gateway works by placing one enforcement point in front of every MCP server, so each tool call goes through the same checks before it reaches a business system.

1. The AI client sends a tool call. An agent running in a client such as Claude, Cursor, or an internal framework sends a request intended for an MCP server. The request goes to the gateway instead of the server.
2. The gateway authenticates the client. It verifies the agent and the user behind it, typically with OAuth 2.1 and your existing identity provider through OIDC or SAML.
3. It checks policy at the tool level. The gateway evaluates whether this role, team, or persona may call this specific tool and action, not just reach the server.
4. It inspects the call before it runs. The request is reviewed and approved or blocked in real time, before anything executes.
5. It forwards approved calls with brokered credentials. The gateway stores downstream credentials server-side and exchanges them for each tool call, so the AI client never holds raw credentials.
6. It inspects the response and logs the result. Traffic is checked on the way back, and every approved and denied call is timestamped and recorded with the identity behind it.

For enterprise security teams, an MCP gateway is the foundational infrastructure layer for governing AI agent activity — but it is the starting point, not the finish line.

MCP Gateway vs API Gateway vs Identity-Aware MCP Gateway

An API gateway manages general API traffic, an MCP gateway adds protocol-level awareness of tool calls, and an identity-aware MCP gateway adds the identity context needed to govern agents. The table compares the three.

The last three rows matter most. Without identity context, a gateway can enforce who reaches what, but it cannot say who authorized an agent or whether its access is still appropriate.

Agent Gateway vs MCP Gateway

An MCP gateway governs how AI agents call tools and data sources over the Model Context Protocol. “Agent gateway” is used less consistently: vendors apply it to broader traffic control that can include agent-to-agent calls and model requests. An MCP gateway is the narrower, tool-level control point.

What MCP Means for the Enterprise Attack Surface

MCP has become the dominant integration layer for connecting AI agents to enterprise data and tools. It is supported by Anthropic, OpenAI, Google, and Microsoft, and as of early 2026, the official MCP registry lists thousands of registered servers, with tens of thousands more available through community directories. Gartner predicts that 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% in 2025.

That scale creates a new attack surface. Agents don't browse — they act. An agent connected to your Salesforce, GitHub, and Jira instances through MCP isn't reading information for a human to evaluate. It is making decisions, executing tool calls, and producing effects in your production systems. The blast radius of a misconfigured or compromised agent is no longer theoretical.

Why Legacy Access Controls Can't See MCP Traffic

The access controls enterprises rely on today were built for a different threat model: human-initiated, session-based access, where a person logs in, does something, and logs out. Agents don't work that way. They operate at machine speed, autonomously, chaining multiple tool calls across multiple systems in a single session — and they don't appear in the downstream application logs your security team relies on.

When an agent calls a tool through MCP, that action doesn't surface in Salesforce's audit log. It doesn't appear in your SIEM. It isn't captured by your DLP. The audit trail simply doesn't exist without an inline enforcement point. According to McKinsey's 2026 AI Trust Maturity Survey of approximately 500 organizations, nearly two-thirds cite security and risk concerns as the top barrier to fully scaling agentic AI — outranking regulatory uncertainty and technical limitations combined. The NSA's AI Security Center reinforced that signal in May 2026, publishing formal guidance on MCP deployments that identified authentication failures and trust boundary vulnerabilities as active, structural risks in enterprise AI stacks.

The gap isn't theoretical. It is the default state for most organizations deploying MCP today.

The Enforcement Gap: Server-Level Control Isn't Enough

Many organizations deploying an MCP gateway configure it at the server level: this role can reach this MCP server, that role cannot. It's a reasonable starting point. It is not sufficient.

A single MCP server can expose dozens of tools with entirely different risk profiles. The Stripe MCP server exposes balance retrieval, charge creation, refund processing, and customer record access in the same package. A finance analyst with read-only responsibilities should be able to query balances. She should not be able to initiate a refund. An engineer troubleshooting an integration should see neither.

Server-level AI access control can't express that distinction. Without tool-level policy enforcement mapped to roles, teams, and personas, organizations face a binary choice: block AI adoption entirely, or accept ungoverned access at a scope far broader than any individual's actual job requires. If you are comparing approaches to this problem, see our guide to the top AI access control tools.

‍

AI Agents Need Authorization, Not Just Authentication

The common mistake is treating MCP governance as an authentication problem. OAuth 2.1, OIDC, SSO integration — these verify that the agent is who it claims to be. They say nothing about what it should be allowed to do in this specific context, for this specific task, invoked by this specific person.

Real MCP governance requires authorization at granular scope: not just which server, but which tools within that server, which actions within those tools, and which data those actions can touch. And it requires that authorization to be enforced in real time, before the action executes, not logged after the fact when the damage is done.

The Identity Gap: Who Is Behind the Agent?

Here is where most MCP gateways stop, and where the real governance problem begins. A gateway that inspects tool calls but has no view into the identity behind them is enforcing policy on an entity it doesn't understand.

Agents are not users. They are not service accounts. They are a unique type of identity — acting on behalf of humans, operating under machine credentials, with permissions that frequently exceed those of the person who invoked them. Most IAM programs have no framework for that. There is no provisioning workflow, no access review cadence, no deprovisioning trigger when the employee behind the agent leaves or changes roles.

The questions no standalone MCP gateway can answer are the ones identity security posture management (ISPM) was built for:

• Who provisioned this agent and what is it authorized to do?
• Does its current access reflect least privilege, or has it drifted?
• When this employee's access was revoked, did the agent's access get revoked as well?
• Can you provide an auditor with a complete, attributable record of what this agent did and on whose behalf?

Without answers to those questions, MCP governance is incomplete regardless of how well the gateway is configured - the human context is an integral part of the equation.

What Identity-Aware MCP Governance Looks Like

Governance that actually closes these gaps requires connecting the MCP layer to your broader identity program. Here is what that looks like in practice.

Linx is the identity governance platform already running across your humans and non-human identities. The MCP Gateway extends that same program — same access profiles, same access reviews, same JML — to AI agents. Not a new silo. The identity governance and administration (IGA) you already run, reaching one layer deeper.

Enforce at the Tool Level, Not the Server Level

Access policy should specify which tools within each MCP server a given role, team, or persona can invoke — and which actions within those tools are permitted. An agent operating under a read-only finance persona should be able to call retrieve_balance. It should not be able to call create_charge. That distinction needs to be enforced by policy at the gateway layer, mapped to the same access profiles that govern human identities.

Agentic identity governance done right means the same access profile model governing your humans and NHIs extends to agents — one policy framework, not three across your environment.

Inspect and Adjudicate Before the Action Executes

Every tool call should be inspected and approved or blocked before it runs. This sounds obvious. Most deployments don't do it. Logging after the fact tells you what happened; it doesn't prevent the harm. Inline, real-time enforcement at machine speed is what governance actually requires when agents are taking actions faster than any human can review them.

Build a Complete AI Agent Audit Trail

Every approved and denied tool call should be captured, timestamped, and tied back to the specific human identity, non-human identity, or agent that initiated it. Not a generic service account. Not an agent ID with no owner. A complete chain of attribution that connects the action to the person behind it.

Identity intelligence that spans human and machine identities makes this possible — and makes it investigable when something goes wrong.

Connect Agent Lifecycle to Your Identity Program

Agents should be provisioned, reviewed, and deprovisioned with the same rigor as human access. Identity lifecycle management that covers agents means access reviews include agent permissions alongside human ones, and offboarding a person also terminates the agent access they owned.

For high-sensitivity operations, JIT access for agents — scoped, time-limited permissions minted at task execution time rather than standing access — significantly reduces blast radius when an agent is compromised or misdirected.

Why MCP Governance Is an Identity Problem

A gateway is the enforcement point. An IGA program is the context that makes enforcement accurate. Linx has both built in - not a gateway bolted onto identity, but identity governance that reaches the gateway layer.

Regulatory pressure is arriving:. 

• Regulatory pressure is arriving. The EU AI Act’s obligations for stand-alone high-risk AI systems now apply from December 2027 after the AI Omnibus delay, which still makes audit-grade records something to plan for in any agent touching credit, employment, or critical infrastructure data.
• The NSA's May 2026 guidance elevated MCP security from a best practice to a formal design consideration for any organization running agents against sensitive systems.
• Gartner predicts that 25% of enterprise GenAI applications will have at least five minor security incidents a year by 2028, up from 9% in 2025, and cites MCP’s interoperability-first design as a factor.

Organizations that treat MCP governance as an identity problem — not just a network or protocol problem — will be significantly better positioned to meet these requirements. The gateway is the enforcement point. Identity is the context that makes enforcement accurate.

Linx MCP Gateway sits inline between AI clients and the enterprise applications they connect to, enforcing tool-level policy in real time, logging every action with full attribution, and extending the same identity governance framework that covers your human and non-human identities directly to your agents. One platform to manage all policies across your entire identity landscape, rather than a separate tool trying to govern AI in isolation.

Ready to see it in action? Get a demo and see how Linx closes the identity gap in your MCP governance program.

MCP Gateway FAQs

What is an MCP gateway?

An MCP gateway is a control plane that sits between AI clients and the MCP servers they connect to, enforcing authentication, access policy, and audit logging for every tool call that passes through. It gives enterprise security teams a centralized point to govern what AI agents can reach, what actions they can take, and a complete record of what they did.

How does an MCP gateway differ from an API gateway?

An MCP gateway is purpose-built for the Model Context Protocol, meaning it understands tool calls, resource requests, and the agentic context in which they occur — not just HTTP methods and endpoints. Generic API gateways can proxy MCP traffic, but they lack the protocol-level awareness needed to enforce tool-level access policies or attribute actions to the human identity behind an agent.

How does an MCP gateway handle authentication?

Enterprise MCP gateways typically implement OAuth 2.1 with PKCE for the client-facing layer, integrated with your existing identity provider via OIDC or SAML for SSO. On the upstream side, a gateway brokers credentials on behalf of users — storing them server-side and exchanging them per tool call — so the AI client never holds raw credentials for downstream systems.

What are the security risks of deploying AI agents without an MCP gateway?

Without an MCP gateway, agents connect directly to MCP servers, which creates credential sprawl, no central audit trail, and no way to block an unauthorized tool call before it runs. Actions taken through MCP also don’t appear in downstream application logs, so security teams lose visibility into what agents do inside business-critical systems.

What is MCP governance?

MCP governance is the set of policies and controls that decide what AI agents can do through the Model Context Protocol, and that record what they did. It covers tool-level access policy, real-time enforcement, and audit logging, and it extends identity governance to agents: provisioning, access review, and deprovisioning tied to the human who owns each one.

What should enterprises look for when evaluating an MCP gateway?

Traditional access control governs human, session-based access: a person logs in, acts, and logs out. AI agent authorization must govern autonomous, machine-speed tool calls chained across systems, so it works at the level of individual tools and actions, not application logins. It also has to trace each call back to the human the agent acts for.

What is AI access control?

AI access control is the practice of defining and enforcing what AI agents are permitted to do within enterprise systems — not just which systems they can reach, but which specific tools, actions, and data they can interact with. Effective AI access control operates at the tool level, maps to role-based access profiles, and enforces policy in real time before agent actions execute.

What are AI access control tools?

AI access control tools are platforms that govern what AI agents and AI-driven systems are authorized to access across your environment. They cover discovery (finding every agent, including shadow deployments), AI identity governance (enforcing least privilege and just-in-time access for non-human identities), inline enforcement (blocking unauthorized actions as they happen), and monitoring (tracking what agents do with the access they hold).

How does AI agent authorization differ from traditional access control?

Traditional access control governs human-initiated, session-based access to resources. AI access control must govern machine-speed, autonomous, multi-step tool invocations made by agents that act on behalf of humans but under their own credentials. This requires enforcement at a finer granularity — individual tool calls rather than application logins — and attribution logic that connects agent actions back to the human identity behind them.

What is AI governance in enterprise security?

AI governance in enterprise security is the set of policies, controls, and processes that organizations use to ensure AI systems operate within defined boundaries, with appropriate oversight and accountability. For agentic AI, this includes inventorying AI agents as identities, enforcing least-privilege access, maintaining auditable records of agent activity, and integrating agent lifecycle management into existing identity and security programs.

Over the past year, several important developments have emerged across the security industry.

Researchers have demonstrated how AI can accelerate vulnerability discovery and exploit development. Security teams have uncovered new ways to manipulate AI agents through prompt injection and tool abuse. Governments have begun restricting access to advanced AI models due to national security concerns.

At first glance, these may seem like separate stories. In reality, they are all pointing to the same shift.

AI is no longer simply a tool employees use. It is becoming an active participant in enterprise environments. AI agents can access systems, retrieve information, invoke actions, and interact with sensitive data. In many cases, they can do so with a level of speed and autonomy that exceeds traditional software systems.

Most discussions around AI security focus on models, prompts, and productivity. The more important story may be what AI is teaching us about identity. As organizations deploy AI agents, MCP-connected applications, and autonomous workflows, they are introducing a new class of identities into their environments. These identities require the same visibility, accountability, and governance as human and non-human identities.

AI Is Changing the Economics of Cyberattacks

One of the most significant security shifts happening today has very little to do with AI-generated content or productivity gains. It is about speed.

Historically, organizations could rely on a window of time between vulnerability disclosure and widespread exploitation. Security teams could assess risk, prioritize remediation, deploy patches, and respond before attackers operationalize newly discovered weaknesses.

That assumption is becoming increasingly difficult to defend.

Research from Anthropic's Project Mythos demonstrated how advanced AI systems can assist in vulnerability discovery and exploit chain development at a scale previously impossible for human researchers alone. At the same time, organizations continue to face record volumes of disclosed vulnerabilities, making it increasingly difficult to distinguish critical risks from background noise.

The implication is not necessarily that AI is creating more vulnerabilities. It is that AI is dramatically reducing the effort required to find them.

This is creating a new reality for defenders. The challenge is no longer finding vulnerabilities. The challenge is fixing them before attackers can weaponize them. Security leaders are increasingly facing an environment where vulnerabilities are discovered, analyzed, and exploited faster than traditional remediation cycles can keep pace.

As AI continues to reduce the cost and complexity of vulnerability discovery, the balance between offense and defense begins to shift. Attackers require less expertise, less time, and fewer resources to identify opportunities. Defenders, meanwhile, are being asked to move faster than ever before.

That alone would be enough to reshape security priorities. However, it is only half of the story.

AI Agents Are Becoming a New Identity Attack Surface

While AI is accelerating vulnerability discovery, organizations are simultaneously introducing entirely new forms of access into their environments.

The most interesting AI security incidents emerging today are not necessarily about the models themselves. They are about what happens when those models are connected to systems, applications, and data.

Microsoft's research into AI agent security has highlighted a growing class of risks, including prompt injection, credential abuse, unauthorized tool usage, and unintended actions triggered through manipulated inputs. Projects such as OpenClaw have further demonstrated how AI agents can be influenced through seemingly legitimate interactions and then use their existing permissions in ways their operators never intended.

These examples all point to the same issue.

The issue is not that the AI became malicious.

The issue is that the AI already had access.

For decades, organizations have invested heavily in security awareness programs designed to reduce human risk. Employees are taught how to recognize phishing attempts, avoid suspicious links, and identify social engineering tactics designed to manipulate behavior. Those programs are built around the assumption that humans can learn from mistakes and adapt their actions.

AI agents do not operate under the same assumptions.

An AI agent may have access to business applications, customer data, development environments, internal documentation, or financial systems. It may be capable of retrieving information, invoking tools, updating records, or executing workflows. When an attacker successfully manipulates that agent, they are often not breaking into a system. They are convincing a trusted identity to use the permissions it already possesses.

This is what makes AI agents fundamentally different from traditional software. They are increasingly acting on behalf of users, making decisions, and interacting with systems using permissions granted by the organization itself.

At some point, the conversation stops being about AI and starts becoming about identity.

Why Traditional Identity Governance Doesn't Account for AI Agents

The challenge organizations face today is not that identity governance is broken.

It is that the identity landscape has changed.

Most identity programs were designed around identities that were relatively easy to understand and manage. Employees have managers. Contractors have sponsors. Service accounts have owners. Access requests follow established workflows, and periodic reviews help ensure permissions remain appropriate over time.

AI agents challenge many of those assumptions.

Who owns an autonomous agent operating across multiple systems? Who reviews its permissions? How do organizations determine whether an agent should retain access six months after it was deployed? Who is accountable when it performs an action nobody anticipated?

These are fundamentally identity governance questions.

Historically, identity governance evolved from managing human identities to managing non-human identities. Service accounts, API keys, machine identities, and workloads all required organizations to expand governance beyond people.

AI agents represent the next stage of that evolution.

Unlike traditional applications, AI agents can operate with varying degrees of autonomy. They can access multiple systems, make decisions, invoke tools, and interact with sensitive data in ways that are difficult to predict in advance. In many organizations, those capabilities are being deployed faster than governance processes can adapt.

The result is not a technology problem as much as a governance problem.

Organizations need answers to fundamental questions:

• What AI agents exist in our environment?
• What systems can they access?
• What permissions do they hold?
• Who approved that access?
• Who reviews it?
• How is it monitored?
• How is it revoked?

Without those answers, AI becomes another source of identity sprawl.

Why AI Access Control Matters

If the incidents we have seen over the last year have anything in common, it is this:

The problem was not the model. The problem was the access.

The AI agent already had permission. The workflow already had credentials. The system already had the ability to act.

As organizations deploy more AI agents through MCP and similar frameworks, visibility into those permissions becomes critical. Security teams need to understand what agents can access, what tools they can invoke, what actions they can perform, and whether those actions align with organizational policy.

This is where AI access control begins to emerge as an important security discipline.

At its core, AI access control is about answering the same questions identity teams have asked for years: Who has access? What can they access? Why do they have that access? And is that access still appropriate? The difference is that those questions now apply to AI agents and autonomous systems as well.

Just as identity governance introduced oversight for human and non-human identities, organizations are beginning to apply those same principles to AI agents: visibility, ownership, least privilege, policy enforcement, access reviews, and auditability.

MCP governance plays an important role in this evolution. As AI agents become increasingly connected to enterprise systems through MCP servers and similar architectures, organizations need control points that allow them to understand and govern agent behavior. Without those controls, organizations risk creating highly privileged identities that operate with little visibility or oversight.

The future of AI security is increasingly identity-centric.

Unifying Human, Non-Human, and AI Identity Governance

One of the biggest mistakes organizations can make is treating AI governance as a completely separate discipline.

In practice, AI agents are simply the newest category of identity.

Whether organizations refer to it as AI identity governance, agent governance, agentic identity governance, or AI access control, the underlying challenge is the same: AI agents are becoming participants in enterprise systems and must be governed accordingly.

Human users, service accounts, machine identities, API keys, and AI agents all represent access paths into critical systems and sensitive data. Creating separate governance programs for each introduces complexity, inconsistency, and blind spots. Instead, organizations should focus on a unified approach to identity governance that gives security teams visibility and control across every identity type.

That is why we introduced Linx AI Access Control.

AI Access Control extends identity governance to AI agents, MCP-connected systems, and autonomous workflows. Rather than treating AI governance as a separate security discipline, Linx helps organizations apply the same visibility, ownership, least privilege, access reviews, and policy enforcement they already use to govern human and non-human identities.

As AI agents become increasingly embedded within enterprise environments, organizations need a way to understand what those agents can access, who approved that access, how it is being used, and when it should be revoked. AI Access Control was built to help answer those questions.

As part of this approach, the Linx MCP Gateway provides organizations with a governance layer for AI agents and MCP-connected systems. It gives security teams visibility into agent activity and the ability to apply identity governance principles to emerging AI workflows before they become blind spots.

But the larger philosophy matters more than any individual product announcement. Organizations should not need separate governance programs for humans, non-human identities, and AI. They need one identity strategy that encompasses all three.

The same principles that govern employee access should govern agent access: visibility, ownership, least privilege, accountability, and continuous monitoring. The technology may be changing, but the principles of identity governance remain the same.

As AI becomes more deeply embedded within enterprise environments, identity teams have an opportunity to apply decades of governance experience to this new category of identities. The organizations that succeed will not view AI governance as a separate problem. They will treat it as part of their broader identity security strategy.

Conclusion

The AI security challenge is not simply that AI is helping attackers move faster.

It is that organizations are simultaneously creating thousands of new identities with access to critical systems, applications, and sensitive data.

The stories making headlines today, whether they involve accelerated vulnerability discovery, AI agent manipulation, model restrictions, or emerging governance concerns, are all pointing in the same direction.

AI is becoming part of the identity landscape.

Identity security has always been about controlling access. As AI becomes a participant in enterprise workflows rather than simply a tool, that mission remains the same.

The organizations that succeed will not be the ones that deploy AI the fastest.

They will be the ones who govern it best.

If you're looking to govern AI agents, MCP-connected systems, and every identity across your environment, schedule a demo with Linx to see AI Access Control and the Linx MCP Gateway in action.

Over the past few months, we have spoken with many security and IT leaders who are in the same position: their organizations are deploying Claude broadly across teams, but they have no idea who actually has access to it, what level of privilege those users hold, or what's happening with the API keys their developers have created. They're governing other application in their stack with rigor, but treating Claude as an exception.

That disconnect has always bothered us. Not only because Claude is unique, but because the same identity logic that protects every other application should apply here as well.

When Anthropic launched the Claude Compliance API, we ceased that opportunity. We're genuinely proud to be one of the integration partners building on it. Anthropic is setting the bar for what responsible enterprise AI deployment looks like, and the Compliance API is a direct expression of that: giving security and IT teams the programmatic access they need to govern Claude the same way they govern everything else that matters. Building on that foundation is something we are excited about.

Here's what we built.

The Linx x Anthropic Integration in Action

Setting it up is simple. Follow the step-by-step integration guide and connect in just 60 seconds. Linx begins pulling data automatically.

Once connected, Claude shows up in Linx as a fully governed application, the same way Salesforce, Okta, GitHub, or any other app in your estate does. From that point forward, everything Linx does for your other applications, it now does for Claude.

What You Can See and Do

Account, Role, and Permission Visibility

The first thing security teams want to know is: who has access, and what can they do? With this integration, Linx gives you a complete view of every account provisioned in Claude, the roles assigned to each user, and the groups they belong to.

You can easily surface administrative roles and identify who holds elevated privileges, and drill into the specific permissions attached to each role. For compliance and least-privilege reviews, this alone is a significant step forward.

AI-Powered Access Certifications

The AI-powered access certifications take the heavy lifting off identity and compliance teams, meaning faster turnaround, fewer errors, and a smoother process end to end.

The new integration allows you to easily review and certify access in Claude, using Linx’s AI-powered access review campaigns. The campaign surfaces every user and their entitlement type, along with AI context and recommendations on whether that access should be approved or denied, powered by Anthropic's own models.

So, you're combining Linx's identity governance context with Claude's intelligence to make faster, smarter access decisions. The reviewer doesn't have to make every call from scratch. They have a recommendation in front of them and the data to act on it.

For teams running quarterly or annual access reviews, this changes the economics of the process considerably. What used to require manual triage across hundreds of accounts can now move in a fraction of the time.

API Key Visibility

One of the less visible but high-stakes risks in any AI deployment is unmanaged API keys. Developers create them, projects get deprecated, people leave the company, and the keys keep existing. Then something goes wrong.

Linx allows identity teams to closely monitor API keys created within Claude: when it was created, associated metadata, and enough context for a security team to evaluate whether it should still exist.

This is the kind of visibility that used to require a manual audit. Now it's continuous.

Project and Resource Governance

Finally, with this integration Linx provides the tools for real governance over projects and shared resources within Claude, with an access graph for each project that shows exactly how access is provisioned.

You see which roles exist, which users hold them, and how access flows through the system. For organizations with multiple teams working across different Claude projects, this provides the resource-level clarity that broad account views can't.

Why This Matters

Security teams have spent years building strong identity governance programs: access reviews, offboarding workflows, least-privilege enforcement, audit trails. Claude is a critical app, and should be governed as such. With this integration, it is.

What makes this feel right to us as product builders is that we didn't create a separate Claude governance tool. We extended the identity fabric that our customers already rely on. Claude is governed in Linx as part of a whole, not as an exception. This means it benefits from everything Linx already does, and security teams don't have to learn a new workflow or platform to govern it.

We're proud to of this integration and to be shaping the future of AI security and governance. Being part of the ecosystem that makes Claude governable at scale is something the Linx team doesn't take lightly.

If you’re new to Linx, schedule a demo to experience truly unified identity governance.

MCP changed how AI agents interact with enterprise systems. By creating a standardized way for AI platforms to connect to applications, databases, and business tools, it dramatically lowered the barrier between AI and enterprise systems.

It also created a governance gap most organizations are not prepared for.

As AI agents gain access to business-critical applications, security teams have no reliable way to inspect actions, enforce policy, or establish accountability before those actions occur. Existing access controls were built for humans. They were not built for agents operating autonomously at machine speed across multiple systems.

Today, we're introducing Linx AI Access Control, a real-time enforcement layer that gives organizations visibility and control over every action taken through MCP.

Why Your Existing Access Controls Can't See MCP Traffic

Most enterprise access controls were designed around a fairly simple model. A user authenticates, receives permissions, performs actions within an application, and those actions are captured in logs that security teams can review later. The process is familiar, and while it isn't perfect, it creates a chain of accountability.

MCP changes that model.

When an AI agent receives a request, it doesn't operate inside a single application. It can invoke multiple tools across multiple systems, make decisions dynamically, and execute actions in seconds. A single prompt might trigger activity across Salesforce, Jira, GitHub, Snowflake, and several internal applications before a human ever sees the result.

The challenge is that traditional access controls cannot inspect activity at the point where those decisions are being made. Application logs can tell you that something happened. They cannot reliably tell you which agent initiated the action, which user was behind it, whether the activity aligned with policy, or whether it should have been allowed in the first place.

Without an enforcement layer sitting between the AI platform and the target application, that context simply doesn't exist.

This is quickly becoming one of the biggest barriers to enterprise AI adoption. According to McKinsey's State of AI Trust in 2026 report, nearly two-thirds of organizations cite security and risk concerns as the primary obstacle to scaling agentic AI initiatives.

Consider a simple example. An organization grants an AI agent read access to Salesforce so it can retrieve customer information. Later, that same agent is prompted to perform actions outside its intended purpose. Who evaluates the request? Who determines whether the action complies with policy? Who records what happened?

For most organizations today, the answer is nobody.

Introducing Linx AI Access Control

As we spoke with customers exploring AI adoption, we kept hearing the same concern.

Organizations understood how to govern people. They understood how to govern service accounts and non-human identities. It’s not perfect, and implementation is hard, but the principles are there. What they didn't understand was how to govern agents.

The problem wasn't a lack of visibility into MCP servers. The problem was a lack of visibility into what agents were actually doing once they got there.

That's why we built Linx AI Access Control.

The MCP gateway creates a dedicated enforcement point between AI platforms and the enterprise systems they access. Every MCP tool call passes through that control point before execution, creating a place where requests can be inspected, policy can be evaluated, and activity can be recorded before actions reach downstream systems.

One of the first design decisions we made was to focus on tool-level governance rather than server-level governance. Connecting to an MCP server is one thing. Determining what an agent can actually do once it's connected is something entirely different. Linx allows organizations to define which specific read, write, and administrative tools an agent can invoke, with policies mapped directly to Linx Access Profiles and governed by role, team, department, or persona.

The gateway also performs policy evaluation in real time. Every request is inspected before execution and evaluated against organizational policy. Approved actions proceed. Violations are blocked before they reach the target application. The goal isn't to investigate risky behavior after it occurs. The goal is to prevent it from occurring in the first place.

Just as importantly, every approved and denied action is captured, timestamped, and attributable. Security teams gain a complete record of activity, including the identity behind the request, the tool being invoked, the action attempted, and the outcome. For the first time, organizations have an investigable record of what agents actually did, not simply what downstream systems recorded.

The Unified Identity Context Advantage

Most MCP governance solutions evaluate requests in isolation. They can see the agent making the request, but they lack the broader identity context required to make accurate policy decisions.

That context matters more than most organizations realize.

When a policy decision is made, Linx can evaluate the human behind the request, the non-human identity the agent is operating as, the access profile associated with that activity, and the specific action being attempted. Rather than looking at a single request in isolation, Linx evaluates the entire identity chain behind it.

This is what allows enforcement to be precise rather than blunt. Without that context, organizations are often forced into a familiar tradeoff. Either permissions become so restrictive that productivity suffers, or access becomes so broad that risk increases.

Because AI Access Control is built directly into the Linx identity governance platform, the same access profile logic already used to govern human and non-human identities extends naturally to AI agents. Organizations don't need a separate governance model for agents. They can extend the one they already trust.

Summary

As AI adoption increases rapidly, we believe AI identity governance should not just keep up, but stay ahead.

We view the MCP Gateway as the core foundation of a broader AI governance strategy, providing real-time enforcement of granular, context driven, policy. We believe it must be coupled with comprehensive agent coverage and the full suite of governance capabilities. That is the only way to treat your agents as the first-class identities they are, and the only path to responsible AI acceleration.

That's why we’re so excited about building a unified, humans and agents, governance platform.

If you want to see Linx AI Access Control in action, join us for an in-person demonstration during Identiverse (June 15-17). To see Linx AI Access Control virtually, schedule a demo with our team to see it live.

Another week, another ShinyHunters headline.

First Canvas. Then 7-Eleven and Charter Communications. A roughly combined 317.2 million identities compromised in these three breaches, just in the last month alone. The details of these incidents are still emerging, and in moments like this it is important not to overstate what we know. But what is already clear is that the same attacker name keeps showing up in conversations about data theft, extortion, SaaS platforms, and trusted enterprise access.

That is the part worth paying attention to.

The security industry still talks about breaches as if attackers are always finding more sophisticated ways to break in. Sometimes they are. But increasingly, the story is different. Attackers are not always breaking through the front door. They are finding identities that already have keys.

What if the real story is not that attackers have become dramatically better at bypassing the enterprise?

What if the real story is that attackers have become exceptionally good at using the trust enterprises have already created?

That is what makes ShinyHunters such an important case study. Not because the group is unique in every tactic it uses, and not because every incident follows the exact same pattern. They are important because their campaigns keep exposing the same uncomfortable truth: identity has become one of the most valuable attack surfaces in the modern enterprise.

The Pattern Behind the Headlines

The recent Canvas incident is still being investigated, but it has already shown the operational impact of compromising a widely used digital platform. Instructure, the company behind Canvas, said it reached an agreement with the attackers to have stolen data deleted, though the company did not disclose the terms or confirm whether a ransom was paid. The attackers had claimed access to data tied to millions of students, teachers, and staff, and the incident disrupted schools during one of the most sensitive windows of the academic year.

The 7-Eleven incident followed a different path. The company confirmed unauthorized access to systems used to store franchisee documents. Reports linked the incident to ShinyHunters and described exposed franchise applicant data, including sensitive personal information. Some reports said stolen files were published after 7-Eleven declined to pay.

Different organizations. Different environments. Different circumstances.

The economics look familiar.

Sensitive data is exposed. Operations are disrupted. Organizations are pressured to negotiate. Customers, students, employees, partners, or applicants are left wondering where their information went and what happens next.

This is why these attacks continue. They work. The criminal economy around data theft and extortion is not built on novelty. It is built on repeatability. Attackers do not need a new zero-day every week if they can find exposed credentials, overprivileged accounts, vulnerable integrations, weakly governed service accounts, or trusted access paths that lead to valuable data.

That is the pattern behind the headlines.

Why Snowflake Changed the Conversation

The most important ShinyHunters campaign was not the one that happened in the last month.

It was Snowflake.

When the Snowflake campaign became public, the initial instinct across the industry was to look for the platform flaw. That is how we have been trained to think about breaches. A major cloud platform is involved, large volumes of customer data are exposed, and the first question becomes: what vulnerability did the attacker exploit?

But the Snowflake story was more instructive than that. Mandiant said it found no evidence that unauthorized access stemmed from a breach of Snowflake’s enterprise environment. Instead, the incidents it investigated were traced back to compromised customer credentials. In many cases, those credentials had been previously stolen by infostealer malware. Some accounts reportedly lacked multi-factor authentication. Attackers then used those legitimate credentials to access customer Snowflake instances, enumerate data, and exfiltrate information.

That should have changed the industry conversation.

The attack did not begin with a vulnerability in the traditional sense. It began with an identity. The attackers did not need to defeat every control in the environment. They needed to find a trusted path that already existed.

From there, the playbook becomes familiar. Use stolen credentials. Access a cloud or SaaS environment. Determine what the identity can reach. Locate high-value data. Extract it. Extort the victim.

The most important lesson from Snowflake was not that attackers had become better at breaking in. It was that attackers had become better at using the trust we already created for them.

That distinction matters because it changes how defenders need to think. If the threat is only exploitation, then the solution is patching, hardening, and vulnerability management. Those things still matter. But if the threat is trusted access being misused, the problem becomes much broader. It becomes a question of identity governance, privilege, context, monitoring, and trust.

Snowflake became one of the clearest examples of a larger shift already underway. The enterprise attack surface is no longer defined only by networks, endpoints, and applications. It is increasingly defined by identities and the access paths those identities create.

What ShinyHunters Understands

Groups like ShinyHunters understand something many organizations are still struggling to operationalize: the fastest path to valuable data is often not through infrastructure. It is through identity.

This does not mean every ShinyHunters incident is purely an identity attack. Real-world breaches are messier than that. They involve social engineering, stolen credentials, exposed systems, third-party platforms, weak configurations, and gaps in monitoring. But across many of these campaigns, the theme is consistent. The attacker looks for a way to inherit trust.

That trust may come from a stolen employee credential. It may come from a compromised contractor account. It may come from an account without MFA. It may come from a service account that has accumulated far more access than anyone realizes. It may come from a SaaS integration connected to sensitive data. It may come from an identity provider relationship, an API token, or an admin workflow that was designed for speed and convenience rather than adversarial use.

Attackers do not care whether an identity belongs to a human, a workload, a third-party integration, or an AI agent. They care whether that identity can take them somewhere valuable.

That is the shift.

For a long time, identity was treated primarily as a control for access. Authenticate the user. Grant the right permission. Remove access when someone leaves. Review access periodically for compliance. That model made sense when the enterprise was simpler, applications were fewer, and most access was tied to human employees inside relatively well-defined boundaries.

That world no longer exists.

The Identity Explosion Nobody Is Talking About

The average enterprise has lost track of how many identities it actually has.

Not users. Identities.

There was a time when identity mostly meant employees. Then contractors became a meaningful part of the workforce. Then partners and vendors were brought into internal systems. Then SaaS applications exploded. Then cloud infrastructure created workloads, roles, and service accounts at a scale most governance programs were not designed to handle. Then APIs and third-party integrations connected systems that were never originally designed to work together. Now AI agents are entering the environment, taking actions on behalf of users, systems, and business processes.

Every one of those changes created new identities. Every new identity created permissions. Every permission created trust. Every trust relationship created a possible attack path.

This is the part many organizations cannot see clearly. They may know how many employees they have. They may know how many applications they manage. They may have a list of privileged users in one system or a quarterly access review process in another. But far fewer can answer the more important question: how many identities exist across the entire environment, what can they reach, and how do they connect to one another?

That is where the risk accumulates.

A service account gets created for a project and never removed. A contractor keeps access after the engagement ends. A SaaS integration is granted broad permissions because it was faster than scoping them properly. A cloud role inherits access from another role. A machine identity is exempted from the controls applied to human users. An AI agent is connected to systems before the governance model is fully understood.

None of these decisions may look catastrophic in isolation. Most of them happen for reasonable business reasons. Teams are moving quickly. Applications need to connect. Data needs to flow. Employees need to work. Automation needs to run.

But attackers do not experience the environment as isolated decisions. They experience it as a graph of trust.

That is what makes identity-based attacks so effective. The attacker does not need to understand the company the way an org chart describes it. They only need to understand the paths between identities, systems, and data. If one identity gives them access to another system, and that system gives them access to another dataset, the business logic behind those connections is irrelevant. The path exists.

And if the path exists, an attacker can use it.

What Security Leaders Are Realizing

This is why many security leaders are starting to ask a different set of questions than they were five years ago. The old questions still matter: who has access, who approved it, and when was it last reviewed? But they are no longer enough.

The better questions are more contextual. Which identities are overprivileged relative to what they actually do? Which service accounts have accumulated access no human would ever be allowed to keep? Which machine identities can reach sensitive systems? Which third-party integrations have permissions that no one has reviewed in months? Which AI agents are beginning to act with privileges inherited from the humans or systems that created them? Which trusted relationships would become dangerous if a single credential were compromised?

Those are not just compliance questions. They are security questions.

They are also difficult questions to answer with legacy identity tooling. Traditional IAM and IGA systems were built around granting access, removing access, and proving to auditors that access was reviewed. That work remains important, but it was not designed for the speed, complexity, and adversarial pressure of the current environment.

The question is no longer only whether an identity is authorized. The question is what becomes possible once that identity is trusted.

That is exactly what the ShinyHunters playbook keeps demonstrating. The breach begins with access. The damage comes from what that access can reach.

What Organizations Need To Do Differently

The lesson from ShinyHunters is not that organizations need more security tools. It is that they need a better understanding of trust.

The challenge with identity-based attacks is that the attacker rarely starts with their final objective. They start with a foothold. A credential. A service account. A contractor account. A SaaS integration. An API token. Then they follow the trust relationships that already exist inside the environment.

That means organizations need to focus on four things:

• Inventory every identity. Human identities are only part of the attack surface. Service accounts, machine identities, third-party integrations, cloud workloads, and AI agents all create access paths that need modern IGA solutions.
• Continuously evaluate access. Knowing who has access is no longer enough. Organizations need to understand whether access is still needed, whether it is being used, and whether the level of privilege matches the risk.
• Understand attack paths. Attackers do not think in accounts. They think in pathways. An identity that appears low risk on its own can become high risk when combined with the systems, applications, and data it can reach.
• Treat identity governance as continuous. Modern environments change too quickly for periodic reviews to be the primary control. Trust relationships need to be evaluated continuously as identities, permissions, and systems evolve.

The goal is not to eliminate trust. The goal is to understand it well enough that attackers cannot exploit it first.

Why We Started Linx

This shift is one of the reasons we started Linx. Not because another attacker group made the news, and not because fear is a compelling business strategy. We started Linx because we saw the enterprise changing faster than the identity tools designed to secure it.

The challenge facing security teams today is not simply managing identities. It is understanding trust across an environment that has become dramatically more complex over the last decade. Human identities are only one part of the equation. Organizations now need to govern machine identities, service accounts, cloud workloads, SaaS applications, APIs, third-party integrations, contractors, vendors, and AI agents. Every one of those identities creates access. Every access decision creates a relationship. Every relationship changes the shape of the attack surface.

Legacy identity governance was built for a world where periodic review was enough. Modern identity security requires continuous understanding. It requires knowing not only who has access, but why they have it, whether they still need it, what risk it creates, and what an attacker could do with it.

That is the problem Linx is focused on solving.

The lesson from ShinyHunters is not that attackers are becoming unstoppable. It is that attackers are following the architecture we have built. And the architecture we have built increasingly runs on identity.

What Comes Next

I think the next decade of security will be defined by a simple idea: organizations will need to continuously validate trust across their environments, not just authenticate it once.

Historically, identity programs have focused on granting access, removing access, and periodically reviewing access. That model was built for a world where identities were relatively static and environments changed slowly. Today’s environments are dynamic. Permissions change constantly. New identities are created every day. Machine identities, AI agents, and automated workloads are introducing entirely new categories of access that most organizations are still learning how to govern.

The companies that succeed will not necessarily be the ones that react fastest to the next breach. They will be the ones that understand their trust relationships deeply enough to identify and eliminate attack paths before attackers can exploit them.

That is the future we are building toward at Linx.

And if the last few years of ShinyHunters headlines have taught us anything, it is that the industry is moving there whether we are ready or not.

At Linx Security, we help organizations build robust identity security that addresses each stage of the attack chain. Book a demo with one of our engineers to learn more about how we can keep your systems safe from identity breaches.

If your organization runs user access reviews, you already know the pain. Spreadsheets, manual exports, managers rubber-stamping hundreds of permissions in a single afternoon, audit evidence scattered across email threads. The process is supposed to enforce least privilege and satisfy auditors but in most organizations, it does neither well.

This post covers what an effective access review program actually looks like in practice, how to automate it, and how to fix the most common failure modes. If you came here for a checklist, you can download the complete user access review checklist here.

What Is a User Access Review?

A user access review (UAR) — also called an access certification, entitlement review, or certification campaign — is the process of periodically validating who has access to which systems and data, and whether those permissions are still appropriate. Organizations run them to enforce least privilege, meet compliance requirements, and reduce the risk of unauthorized access.

Common Mistakes in User Access Review Programs

Most UAR programs fail for the same handful of reasons:

• Identity fragmentation. Dozens of SaaS apps, multiple clouds, and on-prem AD, but no single source of truth tying them together. Answering "who has access to what" takes days, not minutes.
• Manual data collection. Exporting user lists, reformatting them, and chasing managers via email is slow, error-prone, and a poor use of security team resources.
• Reviewer fatigue. Managers handed spreadsheets of hundreds of permissions with no context will rubber-stamp them. Every time.
• Delayed remediation. Even when risky permissions are correctly flagged, removing those permissions requires coordination across teams and manual ticketing. Identified risk stays open for weeks.
• Poor documentation. Auditors want to see specific decisions and rationales, not "the review was completed." Email threads and ad-hoc spreadsheets don't hold up.

User Access Review Checklist

Knowing what UAR programs get wrong is only half the equation. Here's exactly what a complete review should cover, stage by stage, plus a template you can adapt for your own program:

What Your User Access Review Process Should Cover

A complete UAR program follows six stages. If any of these are missing or poorly executed, that's where risk accumulates and where auditors find gaps.

#1 Planning & Scoping 

Define which systems, applications, and data repositories are in scope before anything else. Prioritize by sensitivity, with financial systems, customer data, and privileged infrastructure first. Confirm which compliance frameworks apply and what they require.

#2 Data Collection

Pull current access lists from all in-scope systems to get a clean, consolidated snapshot of who has access to what, at what permission level. This means normalizing disparate permission formats, flagging orphaned accounts and terminated users, and attaching context (last activity, business role, usage patterns) to every record before review begins.

#3 Reviewer Assignment

Assign the right reviewer to every access record based on system ownership, management hierarchy, or data sensitivity. Ensure no record goes unassigned, set clear deadlines, and brief reviewers on what is expected: explicit Approve/Deny decisions, not passive acknowledgment.

#4 Access Certification & Remediation

Reviewers approve or revoke access based on risk, not volume. Flag the highest-risk and most anomalous permissions for priority attention, pair every record with context-rich recommendations to prevent rubber-stamping, and require an explicit Approve or Deny from every reviewer, never passive acknowledgment. Automated reminders keep the cycle on schedule, and tracking approval patterns (a reviewer clearing hundreds of permissions in minutes, for example) catches rubber-stamping before it undermines the review.

#5 Documentation & Evidence Collection

Capture a full UAR audit trail: who reviewed what, when decisions were made, and what was revoked. Every decision needs a timestamp, a reviewer identity, and a rationale, stored in an immutable format that an auditor can reconstruct on demand.

#6 Reporting & Continuous Improvement

Formally close the cycle with a summary report covering scope, completion rate, access modified or revoked, and remediation times. Use the findings to identify bottlenecks, address rubber-stamping patterns, and refine the next cycle toward a more automated, continuous review model.

User Access Review Template

Every UAR program runs on the same core record, regardless of the tooling behind it. Use this template as the baseline for your next review cycle, then adjust the columns to match what your compliance framework actually requires.

For periodic reviews (quarterly or annual, tied to SOC 2, SOX, or similar frameworks), run this template on a fixed schedule across every in-scope system, and keep a dated copy of each cycle as audit evidence.

For ad hoc reviews (triggered by a role change, offboarding, or a flagged anomaly), the same fields apply, just scoped to the identity or system that triggered the review instead of the full environment.

Download the complete UAR Checklist →

Ways to Automate Access Reviews

Automation is the highest-leverage improvement available to most UAR programs. Here's what it looks like at each stage:

Continuous data collection. Automated platforms aggregate identity and permission data across all connected environments in real time, eliminating manual exports and ensuring reviewers always see current data. This includes automatically surfacing known bad access — orphaned accounts, dormant privileges, and accounts belonging to terminated users — as well as unknown bad access, such as permissions that deviate significantly from peer baselines and wouldn't be caught without behavioral analysis.

AI-driven risk prioritization. Machine learning ranks entitlements by risk, surfacing the permissions most likely to represent a genuine threat. Reviewers focus on what matters instead of weighing every record equally. AI serves as a "bridge" to solving the rubber-stamping problem and increasing review speed.

Context-enriched reviewer workflows. Reviewers receive pre-enriched access lists with last activity, business role, and AI-generated recommendations, replacing hours of cross-referencing with immediate, actionable insight.

API-driven remediation. When access is denied, revocation triggers automatically via API. No tickets, no lag, no waiting for IT to action the change.

Continuous compliance evidence. Every decision is logged, timestamped, and rationale-tagged in an immutable audit trail. UAR audit readiness becomes a permanent state rather than a quarterly fire drill.

How to Stop Rubber-Stamping in Access Reviews

Rubber-stamping happens when reviewers are overwhelmed by volume and lack the context to make real decisions, so they approve everything. It is the single biggest threat to UAR program validity, and it cannot be solved by reminding managers to "be more thorough."

The fix is structural:

• Reduce volume by filtering. Show reviewers only the permissions that genuinely warrant scrutiny — high-risk, anomalous, or out-of-pattern entitlements. Hide the rest.
• Enrich every decision with context. Last activity, business role, peer comparison, and a clear recommendation. A reviewer with context makes decisions in seconds; without it, they default to approval.
• Track reviewer behavior. If a manager approves 100% of records in five minutes, that is data worth surfacing.

Eliminate friction. A clean interface with structured Approve/Deny captures decisions faster than a spreadsheet and produces better audit evidence.

How to Create an Audit Trail for Access Certifications

A user access review audit is an evaluation, internal or by an external auditor, of whether the decisions made during your review cycle actually hold up. It asks a simple question: can you prove that every access decision was appropriate, documented, and made by the right person?

That's different from an audit trail. The audit trail is the evidence. The audit is the test that evidence has to pass.

A defensible audit trail requires:

• Per-decision logging. Every Approve or Deny captured with a timestamp, reviewer identity, and rationale.
• Immutable storage. Decisions can't be retroactively edited or lost in an email thread.
• Full chain reconstruction. For any access change, you can show who requested it, who approved it, when it was actioned, and what risk score it carried at the time.
• Continuous, not retrospective. The audit trail is generated automatically as decisions are made, not assembled the week before an audit.

Manual processes can technically produce all of this. They almost never do.

Get the Complete Access Review Checklist

The best practices above point you in the right direction. The checklist gives you the full roadmap — every step of the UAR lifecycle, what good looks like, and how to automate it.

Download the User Access Review Checklist →

User Access Review Best Practices

The user access review best practices below determine whether your program actually works once you're running it, and whether it holds up when an auditor starts asking questions.

These five principles show up consistently in programs that catch risk early. Skip them, and you're left with a program that technically runs reviews but doesn't actually reduce exposure.

The highest-leverage improvements to any UAR program:

• Start with visibility. You cannot review what you cannot see. Unified, continuously updated identity data is the prerequisite for everything else.
• Enrich before you review. Context-rich, risk-ranked lists produce real decisions. Raw permission lists produce rubber-stamping.
• Automate identity risk remediation, not just collection. The security benefit is only realized when identified risk is closed automatically.
• Treat documentation as a byproduct. The audit trail should generate itself as decisions are made.
• Measure what matters. Detection-to-remediation time, approval rate, and percentage of rights modified — not just completion rate.

Automate Your Reviews with Linx Security

Linx Security is a next-generation modern identity governance platform purpose-built to make user access reviews continuous, intelligent, and measurable. With a graph-powered view of every human and non-human identity in your environment, and AI-driven workflows to act on what it surfaces, Linx handles the full UAR lifecycle in one platform.

What takes most teams weeks takes Linx days.

See Linx in action: book a demo at linx.security/demo

Frequently Asked Questions

What is the difference between a user access review and an access certification?

In practice, the two terms are used interchangeably. Access certification technically refers to the formal, compliance-driven step of signing off on access (tied to frameworks like SOC 2 or SOX), while user access review is the broader term for the full process. Other names for the same practice: entitlement review, certification campaign, permission audit. For more on certification-specific terminology, see our guide to automating user access reviews.

How do you automate user access reviews?

By using an identity governance platform that continuously aggregates permission data, enriches it with risk scores and context, delivers structured workflows to reviewers, and triggers automatic remediation on denial. Automation removes the manual exports, ticketing, and chasing that slow traditional reviews down.

What should a user access review template include?

A user access review template should at minimum include: the user's identity, the system or application, their current access level, the business justification for that access, last activity, a risk flag, the reviewer's decision, and the date reviewed. Mature programs also log reviewer comments to support the audit trail. See the template above for a field-by-field breakdown so you can adapt to your own review cycle.

How often should UARs be performed?

Most compliance frameworks set the cadence: quarterly reviews for sensitive systems (financial data, admin-level access, customer PII) and annual reviews for lower-risk applications. The exact requirement depends on which framework you're being audited against, SOC 2, SOX, and PCI DSS each specify slightly different expectations, so check yours before setting a schedule. For teams moving beyond fixed-cadence reviews entirely, see our guide to automating user access reviews.

What are the most common UAR mistakes?

Reviewing without context, relying on manual data collection, failing to automate remediation, and treating documentation as a separate task rather than a byproduct of the review process.

What is the principle of least privilege (PoLP) and how does it relate to access reviews?

Least privilege means every user has access only to what they need and nothing more. Access reviews are the primary mechanism for identifying and revoking the excess permissions that accumulate over time as roles change.

What compliance frameworks require UARs?

SOC 2, ISO 27001, HIPAA, SOX, and PCI DSS all require some form of periodic access review or certification. Demonstrating that permissions are actively managed and promptly remediated is a baseline expectation across nearly every major framework.

What is reviewer fatigue and how do you prevent it?

Reviewer fatigue is when managers are so overwhelmed by review volume that they approve everything without scrutiny. The fix is filtering to high-risk records only, enriching each one with context and recommendations, and removing friction from the decision interface.

What is just-in-time access and how does it improve UARs?

Just-in-time (JIT) access grants permissions only for the duration of a specific task, then automatically revokes them. It prevents standing privileges from accumulating in the first place, shrinking both the attack surface and the review workload.

What is a user access review audit?

A user access review audit is an internal or external evaluation of whether your access review decisions are complete, accurate, and defensible, often performed as part of a SOC 2, SOX, or ISO 27001 compliance audit. It relies on the audit trail (the logged evidence of who reviewed what, when, and why) to reconstruct and verify each decision. A strong audit trail makes the audit itself fast, a weak one turns it into a scramble.

How do you measure the effectiveness of a UAR program?

Completion rate is the most-tracked metric but the least meaningful. Better indicators: detection-to-remediation time, reviewer approval rate, and percentage of access modified or revoked per cycle.

The State of IGA in 2026

If you’re evaluating identity governance and administration (IGA) solutions in 2026, you already know that the average enterprise has more non-human identities than human ones. At the same time, identity-related breaches continue to rise, and the traditional process of manually reviewing access or defining static roles is simply too slow. A strong IGA platform should handle all of these challenges out of the box. 

In this article, we’ll explore the top 10 IGA tools to consider, organized by category, so you can quickly identify what type of platform suits your organization.

IGA Tools Comparison

Modern IGA Platforms

Modern IGA solutions automate the full identity lifecycle and continuously enforce the principle of least privilege across human and non-human identities.

1. Linx Security

At a Glance

Founded: 2023
Headquarters: New York, New York
Category: AI-native IGA & Identity Security
Deployment model: SaaS (cloud-native)
Customer rating: 5/5 on Gartner Peer Insights 

Linx - Best for AI-Driven Identity Security and Governance

Linx is best for organizations that want a modern, AI-native IGA solution with fast deployment, real-time governance, and strong automation across both human and non-human identities.

Description and Features

Linx is an AI-native platform that combines deep identity visibility, automated governance, and continuous security enforcement into a single product. At its core is the Linx Identity Graph, which normalizes and correlates data across human, non-human, and agentic identities, mapping the full access path from identity to resource. 

The Linx Identity Graph empowers you to make informed decisions: You understand, at a glance, who had access, how they gained it, whether they used it, and the blast radius in the case of a compromise. With a single click, you can remediate the root cause of an issue straight from the Identity Graph.

Linx gives you this full visibility into your identity environment by pulling data from every application and system you use. This full coverage is thanks to an extensive library of out-of-the-box connectors, which also include legacy and on-premises systems that many competitors overlook.

Linx also offers automated access review and remediation workflows that continuously evaluate entitlements and detect drift. When access needs to be adjusted or even revoked, remediation happens directly inside the platform: You don’t need any ticketing loops or manual intervention.

Additionally, Linx has introduced Autopilot, the first AI agent built for identity security and governance. Unlike AI systems that only operate on demand, Autopilot monitors identity environments 24/7, detects changes in real time, evaluates risk in context, and takes action to remediate issues. With Autopilot, you get an always-on, autonomous coverage that eliminates the manual work of chasing access reviews, freeing up security teams to focus on implementing new features rather than firefighting.

The bottom line? With Linx, you get a single solution that covers visibility, governance, lifecycle automation, and identity security without the complexity and cost of legacy IGA vendors.

Pros

• Combines IGA and identity security posture management (ISPM) in one platform.
• AI-native architecture built from the ground up — not a legacy platform with AI bolted on.
• Well-suited for the modern era with strong support for non-human and agentic identities, quick deployment, and industry-leading time-to-value.
• Identity Graph provides unified, real-time visibility across human, non-human, and AI agent identities in a single view.
• Autopilot performs autonomous remediation, not just recommendations. It detects, evaluates, and acts without requiring human intervention.
• In-platform remediation eliminates ticketing loops and manual handoffs.
• Clean, non-technical UI makes the platform accessible to GRC and security personas without developer involvement. No query language needed.

Cons

• Smaller connector library and SI partner ecosystem than legacy IGA leaders.
• On-premises application support is more limited than platforms like SailPoint.
• Fewer community resources, public documentation, and third-party implementation partners.
• As a newer company, Linx has been recognized by Forrester but doesn’t have the same analyst recognition as some of the others.

2. Veza

At a Glance

Founded: 2020
Headquarters: Los Gatos, California
Category: Identity Security
Deployment model: SaaS (cloud-native)
Customer rating: 4.8/5 on Gartner Peer Insights

Veza - Best for Permissions-level Access Visibility

Veza is best for security teams that need deep visibility into permissions and authorization across cloud and data systems, especially across complex data environments like Snowflake, AWS, and custom applications.

Description and Features

Veza's Access Graph maps an organization’s entire identity ecosystem, with a deep focus on data and infrastructure. This approach makes Veza strong for access visibility and least-privilege enforcement.

Recently, Veza has introduced Access Agents, which are AI agents designed for governance tasks. Veza has also invested in AI agent security to provide visibility into MCP servers, AI agent permissions, and LLM infrastructure. You can evaluate Veza further in our article on top Veza alternatives.

Pros

• Access Graph delivers the most granular permissions visibility in this category — mapping down to specific data objects, tables, and resources, not just users and groups.
• Exceptionally strong for data system governance across Snowflake, databases, and cloud infrastructure.
• 300+ integrations covering cloud, SaaS, and custom environments.
• AI Agent Security product provides visibility into MCP servers, AI agent permissions, and LLM infrastructure.
• Recognized in the 2025 Gartner Market Guide for Identity Governance and Administration.

Cons

• Acquired by ServiceNow in December 2025, meaning product roadmap, pricing, and support structure are subject to change.
• Veza has no true in-platform remediation, meaning it can surface risk but cannot execute remediation without leaving the platform.
• Traditional IGA workflows — access requests, lifecycle management, provisioning automation — are recent additions, not core strengths.
• Less mature for end-to-end IGA compared to vendors built around the full lifecycle from day one.

(Note: ServiceNow acquired Veza in December 2025) 

3. Lumos

At a Glance

Founded: 2020
Headquarters: San Francisco, California
Category: SaaS Management IGA
Deployment model: SaaS (cloud-native)
Customer rating: 4.6/5 on Gartner Peer Insights

Lumos - Best for SaaS Access Automation

Lumos is best for mid-market companies focused on automating access requests and approvals across SaaS apps, especially those prioritizing employee self-service and productivity.

Description and Features

Lumos is a modern IGA platform that offers real-time visibility into enterprise SaaS ecosystems and allows companies to automate access requests through channels like Slack. When you connect Lumos to your organization’s cloud applications, it can check and map all user permissions and simplify access requests through a self-service portal. Compare Lumos to its competitors with our article on best Lumos alternatives.

Pros

• Strong SaaS access automation and self-service workflows.
• Access reviews surface only what has changed since the last cycle, reducing reviewer fatigue.
• Self-service access requests through Slack reduce IT tickets without sacrificing governance.
• Intuitive user experience for business users and employees.

Cons

• Lumos is built around what the IdP knows, not deep, fine-grained entitlements inside each app, resulting in a shallow data model.
• Lumos was built as a SaaS management platform, so support for NHIs and agentic identities is weak compared to competitors.
• Fewer connectors for legacy and on-prem systems compared to enterprise-focused competitors.
• Not well-suited for organizations with complex regulatory compliance requirements or deep ERP governance needs.

4. Opal Security

At a Glance

Founded: 2020
Headquarters: San Francisco, California
Category: Modern IGA & Authorization
Deployment model: SaaS (cloud-native)
Customer rating: Not yet listed

Opal Security- Best for Just-in-Time Access Governance

Opal Security is best for engineering-heavy organizations that want granular, real-time access governance with deep developer tooling integrations and just-in-time access controls.

Description and Features

Opal Security is an authorization reasoning platform with an intelligent data layer that continuously analyzes access behavior across cloud, SaaS, and on-prem environments. Developer-native integrations and a 2025 Risk Layer for AI agent governance round out the platform.

Pros

• Just-in-time access controls convert standing privileges to time-bound grants.
• Developer-native integrations with Terraform, Slack, Jira, PagerDuty, and GitHub make Opal a natural fit for engineering-led security teams.
• AI agent governance is purpose-built.
• In-platform remediation eliminates ticketing loops and manual handoffs.
• Equal support for human and non-human identities.

Cons

• Smaller connector library compared to established enterprise IGA vendors like SailPoint or Saviynt.
• Traditional IGA workflows, including full lifecycle management, ERP SoD enforcement, complex compliance reporting, are less mature than purpose-built governance platforms.
• Not well-suited for organizations with significant on-premises or legacy infrastructure.
• Opal has a smaller partner ecosystem and fewer third-party implementation resources than legacy IGA leaders.

Legacy IGA Platforms

Legacy IGA platforms are traditionally on-premises identity governance tools that rely heavily on manual workflows and static roles. They usually need dedicated teams to deploy and manage them.

5. SailPoint

At a Glance

Founded: 2005
Headquarters: Austin, Texas
Category: Enterprise IGA
Deployment model: SaaS + Hybrid
Customer rating: 4.8/5 on Gartner Peer Insights

SailPoint - Best for Heavy On-prem Enterprises

SailPoint is best for large enterprises in regulated industries that need a battle-tested IGA platform with a mature SI partner ecosystem and the flexibility to run cloud, on-prem, or both.

Description and Features

SailPoint offers AI-powered access reviews, a broad library of connectors, and lifecycle automations. Its strengths are scale and depth, and it can help you govern tens of thousands of identities across a complex hybrid environment.

Pros

• Market leader with 20 years in enterprise IGA and a Gartner Magic Quadrant Leader designation.
• Broad connector library spanning thousands of integrations across SaaS, cloud, and on-prem systems.
• Flexible deployment: SaaS (Identity Security Cloud) and on-prem (IdentityIQ) options supported.
• Large system integrator partner ecosystem for complex global deployments.
• Agent Identity Security product extends governance to AI agents operating in Salesforce, ServiceNow, Snowflake, and more.

Cons

• Implementations are notoriously complex: often 12+ months to reach maturity, with professional services costs that can triple the initial software price.
• Designed for large enterprises with dedicated IAM teams — mid-market organizations often find it oversized and expensive.
• UI is widely considered dated compared to modern cloud-native competitors.
• IdentityIQ and Identity Security Cloud have different feature sets, creating governance gaps for organizations running both simultaneously.

6. Saviynt

At a Glance

Founded: 2005
Headquarters: El Segundo, California
Category: Cloud-first IGA
Deployment model: SaaS
Customer rating: 4.8/5 on Gartner Peer Insights

Saviynt - Best for ERP-heavy Organizations

Saviynt is best for enterprises looking to consolidate IGA, PAM, and Application Access Governance into a single platform, particularly those running complex ERP environments like SAP or Oracle that require strong Separation of Duties enforcement.

Description and Features

Saviynt is a cloud-native IGA platform that provides identity governance and cloud infrastructure entitlement management (CIEM) in a single solution. It has machine learning capabilities, and its built-in IdentityBot RPA engine automates provisioning tasks. It’s a good choice if you want a platform that covers IGA, PAM, and CIEM without having to buy three separate tools. Continue evaluating Saviynt with our article on best Saviynt alternatives.

Pros

• Converges IGA, PAM, and Application Access Governance into a single platform, eliminating the need to buy and integrate separate tools.
• Out-of-the-box SoD rulesets for SAP, Oracle, Workday, Salesforce, and NetSuite, which is a significant advantage for ERP-heavy organizations.
• Five consecutive Gartner Peer Insights Customers' Choice recognitions — the only vendor in this category with that distinction.
• Available on AWS Marketplace for simplified procurement.

Cons

• Steep learning curve and complex initial setup — typically requires a dedicated IAM team.
• Standard contracts are typically structured as three-year commitments.
• Support responsiveness can be inconsistent, particularly during issue resolution.
• Licensing SKU changes have created confusion and unexpected feature gaps for existing customers.

7. Omada

At a Glance

Founded: 2000
Headquarters: Copenhagen, Denmark
Category: IGA
Deployment model: SaaS + On-prem
Customer rating: 4.6/5 on Gartner Peer Insights

Omada - Best for Compliance-heavy Organizations

Omada is best for European enterprises and organizations with strict GDPR, NIS2, or cross-border data residency requirements that need deep hybrid environment support and a strong implementation track record.

Description and Features

Omada Identity Cloud’s best features are code-free configuration, AI-powered analytics, and role-based access control. Omada can be a good choice for mid-to-large companies that need a structured, compliance-focused IGA solution with strong support for hybrid environments.

Pros

• Founded in 2000, meaning Omada has one of the deepest track records in enterprise IGA, with proven deployments in complex hybrid environments.
• Code-free configuration reduces dependency on developers for workflow and policy changes.
• Cloud Accelerator package offers a guaranteed 12-week implementation at a fixed cost, which is rare for IGA vendors.
• Strong European presence with deep expertise in GDPR, NIS2, and cross-border compliance requirements.

Cons

• Smaller community, fewer public knowledge base resources, and fewer third-party integration partners than SailPoint or Okta.
• Feature discovery is not always intuitive — some capabilities are buried under non-obvious menu labels.
• Implementation still requires a meaningful lift; initial performance can lag before the system is fully tuned.
• Troubleshooting import errors and single identity issues can be difficult for administrators.
• Less momentum in North America compared to European markets.

Identity and SaaS Governance Platforms

Identity and SaaS governance platforms prioritize fast deployment and visibility, but they often fall short of full lifecycle management.

8. Okta Identity Governance 

At a Glance

Founded: 2009
Headquarters: San Francisco, California
Category: IGA (add-on module to Okta platform)
Deployment model: SaaS
Customer rating: 4.2/5 on Gartner Peer Insights

Okta Identity Governance - Best for Existing Okta Customers

Okta Identity Governance is best for companies already using Okta that want to extend their IAM platform into lightweight IGA with minimal additional tooling.

Description and Features

Okta Identity Governance (OIG) extends Okta’s core identity platform. It leverages Okta’s existing directory and SSO integrations to add lifecycle management, periodic reviews, and audits to verify who has access to what without requiring a separate IGA deployment.

Pros

• The only vendor on this list with publicly listed pricing (~$4/user/month as a standalone add-on; ~$17/user/month in the full Essentials bundle).
• Lifecycle Management, Workflows, and Access Governance share the same data model and admin experience as core Okta.
• Fast time to value for organizations already running Okta as their IdP.
• Strong pre-built integrations across the modern SaaS stack.

Cons

• Not a viable standalone IGA platform — value is almost entirely dependent on existing Okta adoption.
• Limited advanced SoD controls and granular policy engines compared to dedicated IGA vendors.
• Governance capabilities thin out significantly for non-SaaS, hybrid, or on-prem environments.
• Not well-suited for complex regulatory compliance use cases requiring deep entitlement modeling.

9. CyberArk Identity Security Platform (Zilla)

At a Glance

Founded: 1999 (CyberArk) / 2019 (Zilla)
Headquarters: Petach Tikva, Israel
Category: PAM + IGA
Deployment model: SaaS + Hybrid
Customer rating: 4.8/5 on Gartner Peer Insights

CyberArk Identity Security Platform - Best for PAM-first Orgs Expanding into IGA

CyberArk Identity Security Platform is best for organizations that already rely on CyberArk for privileged access management and want to extend modern IGA capabilities through the same platform rather than buying a standalone tool.

Description and Features 

CyberArk is known for its robust privileged access management (PAM) capabilities and has expanded to offer broader identity security. CyberArk can help you secure your high-risk credentials (enforcing just-in-time access and recording privileged sessions), and it also provides features like adaptive MFA and identity lifecycle management.

Pros

• Modern IGA via the Zilla acquisition.
• 1,000+ integrations spanning cloud, SaaS, and on-prem environments.
• Just-in-time access with zero standing privileges reduces attack surface across both PAM and IGA workflows.
• AI Profiles capability automates role management using machine learning.

Cons

• Acquired by Palo Alto Networks in February 2026, meaning the product roadmap and pricing are subject to change.
• IGA capabilities are newer and less mature than dedicated IGA platforms. In particular, access request workflows have gaps.
• UI is considered dated by many users compared to modern cloud-native alternatives.
• Platform upgrade stability has been flagged as a concern in user reviews.
• Best fit is PAM-first organizations — pure IGA buyers may find the platform oversized and expensive for their needs.

Note: Palo Alto Networks acquired CyberArk in February 2026.

10. Zluri

At a Glance

Founded: 2020
Headquarters: Milpitas, California
Category: SaaS Management + IGA
Deployment model: SaaS (cloud-native)
Customer rating: 4.6/5 on Gartner Peer Insights

Zluri - Best for Mid-Market SaaS Management

Zluri is best for mid-market companies looking for a simple, SaaS-first IGA solution with strong SaaS discovery and application management capabilities, without the overhead of an enterprise-grade IGA deployment.

Description and Features

Zluri is a SaaS management and identity governance platform that uses its discovery engine to surface all applications in your environment, including shadow IT. This comprehensive visibility enables IT and security teams to see exactly which tools are being accessed and by whom, providing a strong foundation for governance and cost optimization.

Pros

• Nine-method discovery engine surfaces all applications in an environment, including shadow IT, which is one of the most comprehensive SaaS visibility approaches in this category.
• IGA and SaaS spend management in one platform. Access governance and license cost optimization are addressed together.
• Sub-hour JML processing means that new hire provisioning and offboarding happen in minutes, not batch cycles.
• Supports access reviews across multiple IdPs (Azure AD, Google Workspace, Okta, JumpCloud) simultaneously.
• Well-suited for mid-market organizations that want SaaS control without enterprise-grade complexity.

Cons

• Policy enforcement and compliance capabilities are less mature than dedicated IGA platforms.
• Feels more like a SaaS management tool with governance features than a governance platform with SaaS management — an important distinction for compliance-driven buyers.
• Not well-suited for organizations with complex regulatory mandates, deep SoD requirements, or significant on-prem infrastructure.
• The feature set is still maturing for enterprise-scale IGA use cases.

Frequently Asked Questions

What is the difference between modern IGA and legacy IGA?

Modern IGA platforms are cloud-native, AI-driven systems that continuously govern identity access in real time, while legacy IGA platforms are on-premises tools built for periodic, manual governance. Legacy platforms rely on scheduled access reviews, manual provisioning, and dedicated engineering teams. Modern IGA replaces that model with continuous monitoring and automated remediation that scales across human, non-human, and AI agent identities, with faster deployment and lower total cost of ownership.

Which IGA platforms support AI agent governance?

Several IGA platforms function as AI agent security tools too, including Linx, Veza, Opal Security, SailPoint, Saviynt, and CyberArk. Linx governs AI agents and offers continuous drift monitoring. Veza (now part of ServiceNow) provides visibility into MCP servers and LLM infrastructure. Opal Security has introduced a Risk Layer specifically for agentic authorization requests and ships a native MCP server for AI-driven access automation. SailPoint has extended governance to AI agents in Salesforce, ServiceNow, and Snowflake. Saviynt and CyberArk have expanded non-human identity coverage to include agent credentials.

What is the difference between SaaS IGA and on-premises IGA?

SaaS IGA is a cloud-hosted service managed by the vendor; on-premises IGA is software installed and maintained on your own infrastructure. Most modern IGA vendors have moved exclusively to SaaS; legacy platforms like SailPoint IdentityIQ remain available on-premises for organizations with strict data sovereignty requirements.

Does my company need IGA if we already use Okta or Microsoft Entra?

Okta and Microsoft Entra are identity providers that handle authentication and basic lifecycle management, but they are not full identity governance platforms. IGA addresses a complementary set of problems: enforcing least privilege, automating access reviews, managing separation of duties, and governing non-human identities. Both Okta and Microsoft offer governance add-ons, but organizations with hybrid infrastructure, complex compliance requirements, or applications outside those ecosystems typically need a purpose-built IGA platform.

Which IGA platforms are best for mid-market companies?

For mid-market organizations, the best-fit platforms prioritize fast deployment and low operational burden: Lumos, Zluri, Linx, and Opal Security are strong options that deliver value without a dedicated IAM team. 

Which IGA platforms are best for large enterprises?

For large enterprises in regulated industries, SailPoint, Saviynt, and Linx offer the compliance automation, ERP integration, and hybrid environment support that complex organizations require. 

Do IGA platforms require professional services to deploy?

It depends on the platform and the complexity of your environment. Legacy platforms like SailPoint IdentityIQ almost always require vendor-led or partner-led professional services, with implementations taking 6 to 12 months and services costs that can match or exceed the software license. Modern cloud-native platforms like Linx, Lumos, and Zluri are designed to reduce or eliminate that dependency. When evaluating vendors, ask whether professional services are required or optional and whether implementation costs are included in the platform fee.

What are the top IGA tools in 2026?

The top IGA tools in 2026 fall into three categories. Modern platforms include Linx Security, Lumos, Veza (now part of ServiceNow), and Opal Security. Established enterprise platforms include SailPoint and Saviynt, which offer deep compliance automation at the cost of implementation complexity. Okta Identity Governance, CyberArk (which acquired Zilla Security in 2025 and was acquired by Palo Alto Networks in 2026), Omada, and Zluri round out the category with strengths in ecosystem integration, privileged access, European compliance, and SaaS management respectively.

What should I look for when evaluating IGA vendors?

The most important factors when evaluating IGA vendors are deployment speed, AI capability, connector coverage, and total cost of ownership. Ask whether the platform requires professional services or can be deployed by your internal team. Distinguish between AI-native platforms and those with AI bolted onto a legacy system. Get the full TCO picture including licensing, implementation, and any features charged separately. Lastly, analyst recognition from Gartner or Forrester provides a useful independent quality signal.

Find the right IGA platform for your enterprise

In 2026, the direction of the IGA market is clear: Speed, AI-native automation and augmentation, in-platform remediation, and out-of-the-box integrations are now non-negotiable. The best modern IGA tools combine these features with full visibility and intuitive identity lifecycle management.

This is where Linx Security leads the pack. Linx provides full identity governance and immediate time-to-value through its zero-configuration connectors across cloud, SaaS, and on-prem environments. It’s purpose-built for ease of use: You don’t need professional services to deploy or operate Linx. 

Better yet, Linx offers round-the-clock, AI-driven coverage so that no identity issues fall through the cracks. Linx Security’s Autopilot continuously analyzes identity risks and auto-remediates policy violations before they become security incidents.

If you are reviewing IGA vendors, read this blog to understand what are the 10 questions you need to ask when evaluating IGA solutions.

At the same time, if you’re looking for an IGA platform that checks all of the boxes, book a demo with Linx Security to experience what an industry-leading IGA can do.

We shipped Autopilot 10 weeks ago. Autopilot is our autonomous AI agent for identity governance, designed to continuously monitor identity environments, evaluate risk in context, and take action without waiting for human review.

Since then, what's surprised me most isn't about the product. It's about what enterprise security leaders actually want from autonomy, and how dramatically that differs from what the identity industry has been selling them for the last decade.

What follows are notes from inside that learning. Real conversations with the security teams running Autopilot today, plus the CISOs, Heads of IAM, and identity architects evaluating it for the next wave. Across retail, financial services, healthcare, hospitality, and Big Tech. The patterns showed up faster than I expected. They were more uniform than I expected. And one of them surprised me.

The pattern across every conversation

Different industries. Different sizes. Different titles. The same line, in slightly different words.

A CISO at a global financial services firm put it most directly: "I don't need another alert and a warning. I need something to take action."

A senior identity architect at a Fortune 500 retailer framed the other side of the same coin: "I need a log of every action the agent takes, with the reasoning. We still work with auditors, and 'the system decided' isn't a good enough answer."

On the surface those two statements look opposite. One asks for autonomy. The other asks for documentation. But they're the same insight, said from two seats: enterprises want autonomous action, and they want a clean audit trail of every action that gets taken. Autonomy without auditability is a non-starter in any regulated environment. Auditability without autonomy is the status quo we've all been stuck with for a decade.

The thing that's been mis-sold for ten years is that autonomy and accountability are opposites. They're not. They're complementary. Customers are not asking us to choose between "fully automated" and "humans review everything." They're asking for a system that does the work and shows its work, at the same time, every time.

Almost nobody in the legacy identity governance market has built that combination. They've built two products: rules engines that fire alerts, and access reviews that get rubber-stamped quarterly. Neither is autonomous. Neither produces the kind of action-level audit trail a regulated environment can defend. Both are exhausting.

We built Autopilot to do both: take the action, and produce a complete, defensible audit log of every step it took and why. That's the unlock.

The crawl-walk-run shape they're choosing themselves

I expected we'd have to convince buyers to start small with autonomy. To meet them where they were, hand-hold them through a phased rollout, and prove value before unlocking more.

Instead, security teams are articulating the pattern back to us before we pitch it.

A Head of Security at a healthcare enterprise said it clearly: "Trust in autonomy builds over time. So maybe it prompts me first, but as we get comfortable with it, this just needs to run. I've got an agent for that. It just happens."

Almost every conversation followed this shape. Phase 1: the agent investigates, surfaces a recommendation, a human clicks. Phase 2: an admin pre-approves classes of action, and the agent executes. Then, eventually, full autonomy on narrow, well-bounded tasks.

This is buyers leading the architecture, not vendors prescribing it. That's a tell. It means the market has matured past the question of whether autonomy belongs in identity governance and moved to the question of how to operationalize it without losing accountability.

The teams we're working with don't need convincing. They need a credible path. We've built that path into Autopilot from day one.

What buyers are rejecting

Every demo we ran ended in a comparison. Security leaders held Autopilot up against their existing IGA stack, and named what was breaking.

The list rhymes across industries.

Quarterly access reviews are theater. A senior security leader at a global financial data firm asked his team, almost rhetorically, "would you rather have compliance or security?" The framing was sharp because it was honest. Quarterly UAR cycles exist for auditors, not for defenders. Everybody in the room knows it. Nobody in legacy IGA has the architecture to fix it, because their architecture is built around the cycle. Ours isn't.

Rules-based systems produce more alerts, not more action. Several CISOs described arriving at security programs that had ten thousand identity rules and one human staring at the dashboard. The rules weren't wrong. They were just disconnected from the question of who actually had the authority to act on them. Autopilot collapses that gap.

Legacy deployments take years and don't reduce manual work. One enterprise security leader described getting more value in three weeks of running Linx than in three years of running two of the largest legacy IGA platforms combined. I'm not going to name the platforms. The point wasn't that those tools are bad. It's that they were built for a different era of identity, one where humans had time to be in the loop on every decision. That era is over.

One enterprise we engaged with was running five identity products simultaneously. Five. They had to deprovision one because it was disrupting the others. This is what the end-state of "buy more tools" looks like. It's not a security program. It's a tax on the security team. We replace that stack with one platform that does what those five together couldn't do.

These aren't edge cases. They're the pattern.

The agents teams want first

When teams pick their first Autopilot deployment, three patterns dominate.

Admin Drift Monitor. Listens for any access change that elevates someone to admin. Runs a peer comparison and a JIT/access-profile check. Only fires if it finds no justification for the elevation. The reason this one wins is concrete: it produces almost zero false positives, because the bar for "should this human be admin" is exceptionally well-defined inside any mature security program. Teams audit the agent's reasoning easily. They trust it within days. Then they extend it.

UAR Reviewer Classifier. Continuously evaluates entitlements during access review campaigns and pre-recommends approve/deny before the human even opens the review. The pattern: stop asking humans to be the first decision-makers. Make them the second. The human's time is worth far more on the close calls than on the obvious ones.

Access Profile Tuner. The next agent we're shipping. It continuously refines access profiles based on real usage patterns, tightening over-provisioned access automatically and surfacing the gap between what someone has and what they actually use day to day. Same architectural pattern as the first two: narrow scope, accountable action, the human as the second decision-maker, not the first.

What links these three agents is what they aren't. They aren't general-purpose AI assistants. They aren't conversational chatbots. They aren't models that "help you think about identity." They're narrow, accountable, single-purpose agents. They do one thing. They do it well. They show their work.

This is the part of the next 12 months in identity that I think the industry is going to get wrong. The future isn't going to be one giant AI that handles all of identity governance. It's going to be a fleet of narrow agents, each one auditable, each one deployed when the team is ready, each one retired or replaced as the threat shape changes.

The phrase I've started using internally is "the control plane is the agent fleet, not the model." That's the architectural bet behind Autopilot. We've built it that way because the security teams running it are operating that way.

We make autonomy boring. Boring in the way that fire suppression in a data center is boring. Specifically engineered, well-instrumented, mostly invisible, deeply trusted. That's the bar we set for Autopilot, and it's the bar we're meeting.

What this means for the next twelve months

A few predictions, from where I sit 10 weeks in.

The identity governance category is going to fragment along the autonomy axis. Vendors who ship generic "AI-powered" features bolted onto rules engines will lose share to vendors who ship narrow, accountable agents that customers can audit, deploy, and extend. The winners will be the ones who make autonomy explicable, not the ones who make it impressive. We've made our bet, and the market is validating it in real time.

The "control plane" framing is the right one, but it goes beyond agents. Microsoft, Okta, and others are now naming their agent control surfaces. That's a market-defining moment. The deeper truth, though, is that the agent control plane only works if the identity control plane underneath it is unified. You can't govern an agent's actions if you don't have a unified record of every human, machine, service account, and agent identity in your environment. Identity becomes the substrate. The agent layer is the workload. Linx is the only platform built for both.

CISOs are going to keep telling us they want autonomy and verification together. I expect this signal to get louder, not quieter. The boards of the companies our customers serve are starting to ask "are we governable?" instead of "are we secure?" That's a more sophisticated question, and it's going to drive procurement priorities for the next two years. The platforms that answer it well will define the next decade of security.

The bar for what counts as "autonomous identity security" is going to rise quickly. Six months from now, the demo bar will be entirely different from where it is today. The bar is being set by the platforms shipping today, with skin in the game. We are one of them.

Closing

We shipped Autopilot 10 weeks ago. The conversations are different from the ones I had a year ago. Different from six months ago. Different from 10 weeks ago.

The market is moving, and it's moving toward something specific: autonomous identity governance that earns trust by showing its work. That's exactly what we built.

If you're a CISO or Head of IAM thinking about how autonomy fits into your identity program, what to deploy first, how to phase trust, where the audit trail needs to live, we'd be glad to compare notes. The companies that figure this out first won't be the ones who buy the most tools. They'll be the ones who deploy autonomy with discipline. We're doing it now. Come see what 10 weeks of shipping autonomous identity governance actually looks like.

10 weeks in, that's what I'm certain of.

Frequently asked questions

What is autonomous identity security?

Autonomous identity security is the use of AI agents to continuously monitor identity environments, evaluate risk in context, and take action in real time without waiting for human review. It replaces the periodic, alert-driven model of legacy identity governance with a continuous, agent-driven model that operates at machine speed and produces a complete audit trail of every action taken.

What is Linx Security's Autopilot?

Autopilot is Linx Security's autonomous AI agent for identity governance. It runs as a fleet of narrow, single-purpose agents, including Admin Drift Monitor, UAR Reviewer Classifier, and Access Profile Tuner, that each perform a specific identity governance task continuously, with full action logging and customer-readable rationale on every decision. Autopilot is shipping today, with deployments and active engagements across retail, financial services, healthcare, hospitality, and Big Tech.

How is autonomous identity security different from legacy IGA?

Legacy identity governance platforms are built around quarterly access review cycles, rule-based alerting, and human-in-the-loop decision making. Autonomous identity security is built around continuous monitoring, AI-driven contextual risk evaluation, and direct action by accountable agents. Linx Security delivers value in weeks rather than the months or years typically required by legacy IGA platforms.

Which Autopilot agents do customers deploy first?

The two most common first deployments are Admin Drift Monitor, which detects unauthorized administrative privilege elevation and only fires when it finds no business justification, and UAR Reviewer Classifier, which pre-classifies entitlements during access review campaigns to reduce human review time. Access Profile Tuner is the next agent shipping, continuously refining access profiles based on actual usage patterns. Teams typically extend to additional agents over the following 30 to 90 days as trust in the platform builds.

How does autonomous identity governance work with auditors?

Autonomous identity security only works in regulated environments if every action the system takes produces a complete, defensible audit trail. Linx Security's Autopilot logs every action with full reasoning, the data inputs the agent used, and the policy or context that triggered the decision. This satisfies SOC 2, ISO 27001, NIST, and most regulatory frameworks while maintaining continuous autonomous operation.

Who should consider autonomous identity security?

Autonomous identity security is most relevant for CISOs, Heads of Identity and Access Management, and security architects at enterprises with more than 1,000 employees or significant non-human identity sprawl across service accounts, machine identities, AI agents, and contractor access. Companies operating in regulated industries (financial services, healthcare, retail, hospitality) and those running multiple legacy identity tools simultaneously typically see the fastest value from migrating to a single autonomous platform.