IVIP: Pearl Jam, Nirvana, or Screaming Trees?

IVIP: should it stay or should it go?

IVIP (Identity Visibility & Intelligence Platform) is the latest buzzword in the IAM industry. The proliferation of buzzwords for new products is a cybersecurity original sin that the IAM world has adopted. Maybe for a reason.

ITDR, ISPM, UEBA (threat detection, posture management, behavior analytics) are just a few of the many terms I've personally seen rise, then quietly disappear without a clear reason.

In a way, it reminds me of the music of the 90s, specifically the Grunge music I grew up with: we all loved tiny, obscure bands that we could relate to.

The smaller, the better. Some made it to a broader audience and still exist (Pearl Jam), some made it big, but only briefly: Nirvana. Some simply went under the radar for the mainstream public, like Mark Lanegan’s Screaming Trees.

So, who will IVIP be like? Pearl Jam, Nirvana, or Screaming Trees?

Why hasn't it been achieved so far?

The promise of complete identity and access visibility has been the Holy Grail of IAM for over two decades.

Every major IAM vendor has claimed to deliver it, yet organizations still struggle with basic questions like "Who has access to what?"; and "Why do they have it?"; across their entire Identity Data source estate.

The reason is brutally simple: traditional IAM tools require explicit integration and manual correlation logic for every data source.

Want to correlate an AD group with a cloud entitlement? Build custom logic. Trying to map business roles to technical permissions across 50+ applications? Build custom logic.

Good luck maintaining those rules.

The complexity isn't just technical: it's semantic. Different systems use different terminologies for the same concepts. Traditional IAM tools require humans to explicitly map these relationships, creating a maintenance nightmare that only keeps growing.

And the complexity is only going to grow. Meanwhile, a storm is already forming: personal digital proxies. Tools like Claude Cowork, which each of us will soon use to delegate tasks inside the company. Compliance will worry. Security will push back. It won't be enough. The productivity gain wins.

And the foundational assumptions that IAM has been built on collapse entirely.

Why do pre-AI IAM software players have a hard time
doing it?

Incumbent IAM vendors are trapped by their own architecture. Their products were built on a fundamentally different paradigm: explicit rules, structured data models, and deterministic logic.
Consider what happens when a traditional IAM platform tries to add IVIP capabilities:

• Architecture mismatch: The core engine is built around predefined schemas and hard-coded integration patterns. Retrofitting semantic understanding and dynamic correlation requires rebuilding the foundation.
• Data model rigidity: These systems expect clean, structured data that fits into their predefined schemas. Real-world identity data is messy and unstructured.
  Traditional systems can't adapt without manual intervention.

The result? They bolt AI features onto architectures that were never designed to support them.

Why are Large Language Models (LLMs) good at it?

They fundamentally change the game because they excel at exactly what traditional IAM tools struggle with: understanding context, correlating data and identifying semantic similarities, without explicit programming.

• Semantic understanding without explicit mapping: LLMs can understand that "Administrator"; "Admin"; and "Power User"; likely represent similar access levels across different applications, without anyone writing correlation rules. They recognize semantic similarity in permission names, group structures, and access contexts.
• Data meshing at scale: Instead of requiring perfectly structured, pre-integrated data, LLMs can work with raw, messy identity data from multiple sources simultaneously. This is impossible with rule-based systems.

Traditional IAM tools speak in rules. LLMs speak in meaning. And in IAM, meaning is everything.

IVIP: it’s a BIG MESH!

Strip away the acronym, and IVIP is really one thing: an LLM-based Cognitive Layer built on top of all your identity silos: IGA, PAM, Access and Threat Data, and yes, even the Documents where your organization has buried years of IAM-related knowledge in natural language.
But here's where it gets genuinely interesting: add time and change events to the equation, and the layer doesn't just tell you what your identity landscape looks like today. It tells you how it got there, when things shifted, and what's about to go wrong.

That's not visibility. That's foresight.

What’s up then, IAMONES?

We started IAMONES because we were tired of IAM that grows through
accumulation: one tool patched onto another.

A Born-on-the-LLM architecture doesn't just add AI on top of existing logic. It replaces the logic itself with something more flexible. Language becomes the interface, the policy engine, and the reasoning layer all at once.

The agility isn't a feature. It's a structural advantage. When your core is a language model, adapting to a new use case is a matter of intent, not engineering.

That's what Born-on-the-LLM means, and why one platform can now do what used to take three or more.

So, Pearl Jam, Nirvana, or Screaming Trees?

Well, I’m a Pearl Jam-mer. IVIP as a concept will survive and thrive, but not under that acronym. Like how we stopped saying "UEBA", IVIP will become baseline functionality that we simply expect from modern identity platforms.

Just like Pearl Jam, who outlasted the grunge hype cycle by focusing on the music rather than the movement. We're building IAMONES to be exactly that.