Site icon Spherical Cow Consulting

What the AI Vendor Landscape Reveals About Fragmented Identity Systems

Heather Flanagan

Magnifying Glass Focused on Circuit Board with AI Word, Representing Artificial Intelligence and Technology Innovation.

“It started as a fairly contained, geeky exercise. AI has been this all-consuming thing for the last few years.”
 
Every vendor at every conference had some kind of AI story, real or imagined. Every pitch referenced automation, intelligence, or decision-making. The term was doing a lot of work, and not always in a way that clarified what the technology actually did.
 
So I decided to see what would happen if I took a step back and approached it more methodically, looking not just at the vendor description but also at how the vendor described their solutions and where that problem sits in the broader identity and security stack. I combined information from RSAC and Identiverse 2026.
 
That whole exercise turned out to be more interesting to me than expected. I saw definite layers where vendors tended to cluster around specific problems. I did NOT see much in the way of orchestration between the layers.
But let’s start with how I got there from here.
 
 
A Digital Identity Digest
What the AI Vendor Landscape Reveals About Fragmented Identity Systems

You can Subscribe and Listen to the Podcast on Apple Podcasts, or wherever you listen to Podcasts.

And be sure to leave me a Rating and Review!

 

Starting with the problem, not the label

The first pass was deliberately simple. RSAC even let me set an “AI” tag to narrow the list of vendors to review during the event (though that tag seems to be missing now). For each vendor, I looked for a few basic signals:
This was less about evaluating product quality and more about locating function. Once you strip away the terminology, most systems are easier to place than their positioning suggests.
 
Some vendors were clearly focused on establishing or managing identity—human or non-human. Others were ingesting large volumes of behavioral or environmental data and turning that into risk or context signals. A third group was concerned with policy: defining what should or shouldn’t be allowed under certain conditions. And then there were systems responsible for enforcement or execution—actually carrying out decisions, whether that meant granting access, triggering a workflow, or blocking an action.
 
None of this is new on its own. These categories have existed in one form or another for years.
What was different was how consistently vendors aligned to one of these roles, even when they described themselves in much broader terms.
 

Patterns emerge at the boundaries

As more vendors were mapped this way, I saw a pattern. The ecosystem wasn’t organizing itself around products or even technologies, which makes sense. It is organized around functions within a larger system.
You could describe that system in a few different ways, but one framing held up across most cases:
Individually, each category made sense. Most practitioners would recognize them, even if they use slightly different terminology in their own environments.
 
What was less clear, at least to me and what I was reading, was how these pieces were expected to work together.
Vendors tended to describe their ‘solutions’ in isolation, occasionally referencing integrations or partner ecosystems, but rarely articulating how decisions flowed across the entire system.
 
There was no shared model for how identity-informed signals, how signals influenced policy, or how policy translated into consistent enforcement and execution. I’ll get to the question of using standards in a separate post (tl;dr: it’s not pretty).
 
And yet, in practice, according to conversations at The Identity Salon, that is exactly what organizations are relying on.

 

The implicit system behind the architecture

At this point, the exercise stopped being about vendor positioning and became more about the implications of the system. If each of these components is operating independently—often from different vendors, sometimes from different generations of infrastructure—how are decisions actually being made in deployed environments?
 
An access decision, for example, might depend on an identity provider, a device posture check, a behavioral risk score, and policies defined in a separate system. The enforcement point may sit somewhere else entirely. Each of these components contributes something necessary, but none, on its own, represents the decision.
 
The decision is assembled, and that assembly process is rarely described as a first-class concern. It’s treated as an implementation detail, even though it is where inconsistencies, gaps, and unintended behaviors tend to surface.
 
Looking back at the vendor landscape, then, the earlier pattern becomes more significant. What initially appeared to be a loose clustering of capabilities starts to look more like a fragmented implementation of a single, distributed function.

 

A shift in how to think about identity systems

If identity, signals, policy, and enforcement are all contributing to a common outcome, then the system they form is not just an identity system, or a policy system, or a detection system. It is a decision system—one that happens to be distributed across multiple components, teams, and often vendors.
 
That may sound like an unimportant distinction, but I think it changes where you look for problems.
 
Instead of focusing only on whether each component is functioning correctly—which, don’t get me wrong, is both difficult and important—you start to ask whether the system produces decisions that are consistent, explainable, and aligned with intent. You look more closely at how data moves between components, how assumptions are translated (or lost) across boundaries, and how conflicting inputs are resolved.
 
Those questions don’t have simple answers, and they’re not ones most vendors are incentivized to address directly.

 

Why start here

My initial goal was to make sense of a noisy vendor landscape. What I got instead was a different way of looking at the systems many organizations already have in place. The components are familiar. The interactions between them are not always well understood.
 
That gap is where the more interesting questions sit, which makes me all sorts of excited to dig in.
 
In the next several posts, I’ll build on this by looking more closely at how decisions are actually constructed across these systems, where the seams tend to break down, and what that means for both standards development and real-world deployments.
 
📩 If you’d rather receive an email than hope you catch the social media announcement when a new post is live, I have an option for you! Subscribe to get a notification when new blog posts go live. No spam, just announcements of new posts. [Subscribe here] 

Transcript

Introduction

Welcome to another edition of the Digital Identity Digest, the audio companion to the blog at Spherical Cow Consulting. In this episode, we explore a surprisingly revealing journey into the AI vendor landscape—and what it uncovers about modern identity systems.

At first glance, this topic may seem like yet another take on AI hype. However, as you’ll see, the real story runs deeper. It’s not just about artificial intelligence—it’s about how decisions are made across fragmented systems.

A Different Way to Look at the AI Market

Over the past few years, AI has become impossible to ignore. It shows up everywhere:

Tools that were once labeled as:

Sometimes, these changes reflect real innovation. Other times, they are simply marketing.

So instead of asking “Is this really AI?”, a more useful question emerged:

This shift in perspective turns out to be far more insightful.

Breaking Down Vendor Functionality

To better understand the landscape, each product was evaluated using three simple questions:

Once you strip away the buzzwords, patterns begin to emerge.

Most systems rely on inputs such as:

And they typically produce outputs like:

From there, you can determine where each tool fits within a broader ecosystem.

The Hidden Structure of Identity Systems

As vendors were mapped based on behavior, a clear layered structure appeared. Most tools fall into one of the following roles:

Identity Layer

Focuses on defining who or what is involved:

Signal Layer

Answers the question: What is happening right now?

Policy Layer

Determines: What should happen next?

Enforcement Layer

Executes decisions:

Execution Layer

Handles outcomes:

At first glance, this looks like standard architecture. However, the reality is far more complex.

Why Fragmentation Matters

Although these layers appear neatly organized, they are deeply interconnected:

In other words, these tools don’t operate independently—they form a distributed decision system.

This distinction is critical.

Because when decisions are distributed:

And that’s where things start to break down.

The Illusion of Order

A typical enterprise access flow might look clean and logical:

Historically, these systems were deterministic, meaning:

Even risk-based systems followed controlled logic.

However, behind the scenes:

As a result, decisions are often assembled through:

It works—but it’s fragile.

Enter AI: A New Layer of Complexity

Now, AI enters the picture.

Modern environments may include:

These capabilities can deliver real value. However, they also introduce a fundamental shift.

Instead of deterministic outputs, we now see probabilistic results, such as:

This creates a mismatch.

Because most organizations still rely on:

The result? Increased uncertainty.

The Risk of “Magical Thinking”

It’s important to be clear—this is not an anti-AI argument.

AI can:

However, it is not a magic solution.

If anything, AI can:

In poorly structured environments, AI doesn’t create clarity—it accelerates confusion.

Rethinking Identity as a Decision System

This research leads to a critical realization:

Organizations are not just running identity systems or security tools.

They are operating a decision system that determines:

This was always true.

What’s changed is that now:

That shift demands new thinking.

Better Questions to Ask

Instead of asking whether a product “has AI,” focus on deeper questions:

These are not easy questions—but they are essential.

The Reality Behind Vendor Claims

Most vendor messaging avoids these complexities.

Instead, it emphasizes:

In reality:

Because:

Fragmentation doesn’t disappear—it evolves.

Why This Matters Now

AI doesn’t create the fragmentation problem.

It exposes it.

And in many cases, it makes it harder to manage.

This creates an important opportunity:

Because ultimately:

If you cannot explain how decisions are made today, adding AI tomorrow won’t fix that.

Final Thoughts

As you evaluate AI in identity or security, start with one simple question:

What decision is this system actually helping you make?

If that answer isn’t clear, pause.

Because the real risk isn’t adopting AI—it’s adopting it without understanding the system it operates within.

Looking Ahead

This topic goes far beyond a single discussion. Future explorations will dive into:

Because in the end:

The system that wins a conflict defines your true architecture—not the diagram.

Conclusion

If this helped clarify the landscape—or at least made it more interesting—consider sharing it with a colleague.

Stay curious, stay engaged, and keep asking better questions about how decisions are really made.

Exit mobile version