Blog

Wall covered with vintage concert and movie posters

<h3>IVIP: should it stay or should it go?</h3>IVIP (Identity Visibility &amp; 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?<h3>Why hasn't it been achieved so far?</h3>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.<h3>Why do pre-AI IAM software players have a hard time doing it?</h3>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: <ul><li>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.</li><li>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.</li></ul>The result? They bolt AI features onto architectures that were never designed to support them.<h3>Why are Large Language Models (LLMs) good at it?</h3>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. <ul><li>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.</li><li>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.</li></ul>Traditional IAM tools speak in rules. LLMs speak in meaning. And in IAM, meaning is everything.<h3>IVIP: it’s a BIG MESH!</h3>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.<figure id="figure-upe3ag3ltkmo1b8aim"><img id="upe3ag3ltkmo1b8aim" src="https://cdn.durable.co/blocks/21J3w7iI1ZjNAZjTHdgWVkequ4JnC10F12ZPnp3n28xO3TZImZKVMdvxehrn3OL0.png" alt="Diagram of an advanced IAM architecture based on a Temporal Identity Graph, designed to unify and correlate identity data over time. It integrates multiple sources, including IGA (Identity Governance and Administration), PAM (Privileged Access Management), access management systems, threat detection tools, and documents. The model illustrates how identity data is centralized into a single temporal graph, enabling historical analysis, identity governance, security insights, and compliance in a more efficient and scalable way." title="Diagram of an advanced IAM architecture based on a Temporal Identity Graph, designed to unify and correlate identity data over time. It integrates multiple sources, including IGA (Identity Governance and Administration), PAM (Privileged Access Management), access management systems, threat detection tools, and documents. The model illustrates how identity data is centralized into a single temporal graph, enabling historical analysis, identity governance, security insights, and compliance in a more efficient and scalable way." class="object-cover bg-gray-100 rounded-sm md:rounded-md lg:rounded-lg" style="aspect-ratio: 16/9; object-position: undefined undefined;" data-corners="default" data-aspect="16:9" data-caption="" data-positionx="undefined" data-positiony="undefined" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/21J3w7iI1ZjNAZjTHdgWVkequ4JnC10F12ZPnp3n28xO3TZImZKVMdvxehrn3OL0.png" data-mce-style="aspect-ratio: 16/9; object-position: undefined undefined;"></figure>&nbsp;<h3>What’s up then, IAMONES?</h3>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.<figure id="figure-eg8400hl3rmo1bd6lz"><img id="eg8400hl3rmo1bd6lz" src="https://cdn.durable.co/blocks/267RQHtRabRNzqDk1SvDcRYnwnhaVzQNO7jEcy9249390xnRUEFteHjBP3iuzp8b.png" alt="Illustration highlighting the four core pillars of a modern AI-driven IAM platform: Born-on-LLM, Conversational UX, Legacy Integration, and Full Data Sovereignty. The diagram shows how artificial intelligence acts as the system’s decision core, enabling a natural language interface for business, audit, and security users. It also emphasizes seamless integration with existing IAM systems and full flexibility in data deployment, including SaaS, private tenant, and on-premise options." title="Illustration highlighting the four core pillars of a modern AI-driven IAM platform: Born-on-LLM, Conversational UX, Legacy Integration, and Full Data Sovereignty. The diagram shows how artificial intelligence acts as the system’s decision core, enabling a natural language interface for business, audit, and security users. It also emphasizes seamless integration with existing IAM systems and full flexibility in data deployment, including SaaS, private tenant, and on-premise options." class="object-cover bg-gray-100 " style="aspect-ratio: 16/9; object-position: 40% 45%;" data-corners="no-rounded" data-aspect="16:9" data-caption="" data-positionx="40%" data-positiony="45%" data-fullwidth="false" data-mce-src="https://cdn.durable.co/blocks/267RQHtRabRNzqDk1SvDcRYnwnhaVzQNO7jEcy9249390xnRUEFteHjBP3iuzp8b.png" data-mce-style="aspect-ratio: 16/9; object-position: 40% 45%;"></figure><h3>So, Pearl Jam, Nirvana, or Screaming Trees?</h3>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.

IVIP: Pearl Jam, Nirvana, or Screaming Trees?

Let's talk about a number that should worry every IAM team: 100:1. That's the current ratio of machine identities to human identities in most enterprises, according to ManageEngine's 2026 Identity Security Outlook. Some sectors are already hitting 500:1. And the fastest-growing contributor to that ratio? AI agents. Not chatbots. Autonomous systems that execute commands, query databases, modify configurations, and trigger workflows across your environment without a human pressing a button. If you work in IAM, your entire governance lifecycle is built around a simple assumption: identities belong to people. People have managers, respond to access review campaigns, and eventually leave. AI agents break every part of that assumption.<h3>How AI agents create identities</h3>When a team deploys an AI agent, it needs credentials. An API key for the CRM, a token for the ticketing system, OAuth access to the email platform, a service account for the database. A single agent might require 15 to 20 distinct credentials across integrated systems. None of these go through your IAM onboarding process. A developer creates them during a sprint, scopes them broadly, and ships them to production. CyberArk found 82 machine identities for every human across organizations, with 42% holding privileged or sensitive access. And 68% of organizations lack identity security controls specifically for AI.<h3>Why agents aren't just another service account</h3>A traditional service account is static. Same API, same parameters, every time. Predictable and auditable. An AI agent reasons about what to do based on context, dynamically decides which tools to call, and chains actions across systems. That context can be manipulated. A maliciously crafted support ticket could trick an agent into querying data outside its intended scope. The agent doesn't malfunction. It follows its instructions perfectly, it just received them from the wrong source. When that agent runs on a shared credential with broad access and no monitoring, the blast radius scales with the permissions it holds.<h3>The identity gap</h3>The tools to fix this already exist. Short-lived tokens, workload identity federation, scoped permissions, automated lifecycle management. None of this is new. We apply these principles to cloud infrastructure and CI/CD pipelines every day. We just haven't extended them to AI agents, and that's the problem. OWASP ranks improper offboarding as the #1 non-human identity risk. Only 12% of organizations have automated lifecycle management for their machine identities. Meanwhile agents keep shipping, credentials keep accumulating, and nobody goes back to clean up. The gap between how fast these identities are being created and how well they're being governed is the defining IAM challenge of 2026. Your next 100 identities won't be human. Your IAM program needs to be ready.Sources: ManageEngine, "Identity Security Outlook 2026"; CyberArk, "2025 Identity Security Landscape"; OWASP Non-Human Identities Top 10

Your Next 100 Identities Won't Be Human

Composite photo collage of excited girl speech text lines communication wonder concept phrase isolated on painted background

Descartes taught us the concept of methodological doubt. He believed that the way to reach certainty is by systematically, though tentatively, doubting everything. It is good practice to apply this principle to statements generated by AI. AI Agents often outsmart us, but we can still review their output. The reason is that it is easier to recognize something than to recall it. Generating output is hard, but when it is in front of us, we can test it, compare it, and question it. Reviews are not optional. We know agents tend to misbehave through hallucination, overconfidence, or gaps in knowledge. If errors are predictable, review is not optional. Ignoring that step would mean outsourcing judgment entirely. Reviews remain necessary even with perfect agents. The flaw may not be in the system, but in the input we provide. The meaning of our prompt might be ambiguous; our assumptions may be incomplete, and our goals poorly framed. By reviewing the output, we often discover weaknesses in the input. Reviews remain necessary, but repetition is not. When agents perform tasks under sufficiently similar conditions, a single review might be enough. What counts as “sufficiently similar” is debatable, since context is never identical. However, the goal is not perfection, but convergence toward something good enough. Depending on the specific tasks, reviews do not always need to happen upfront. They can also be conducted after tasks have been executed. This applies when the potential harm an AI agent can cause is limited in time and scope. It especially applies to tasks that are reversible. Trial and error is not a flaw in the process; it is the process. Recognizing the need for review reflects responsible use. When applied proportionately to the stakes, this loop steadily improves both the output and our own judgment, guiding us toward results that are reliably good enough.

Why human review still matters, even with AI

In 1944, the Allies did not defeat German defenses on D-day by force alone. They defeated them by feeding them information. During Operation Fortitude, the Allies injected carefully crafted signals into German intelligence systems: phantom armies, fake radio traffic, forged documents, and staged logistics movements. German command processed these inputs exactly as intended, reallocating troops away from Normandy and executing the wrong plan with absolute confidence. This was not a failure of intelligence or reasoning. It was a failure of trust boundaries. Modern AI systems face the same risk if these fail to distinguish between data it should analyze and instructions it should execute. Then, external inputs can directly alter its behavior. The danger is not that the system misunderstands instructions, but that it follows them without knowing who created them. Prompt injection mirrors Operation Fortitude in this way. Once an AI system begins acting on what it reads, the central question is no longer whether it can be deceived, but who is allowed to influence its decisions. Instructions embedded in otherwise legitimate data can cause the agent to act in the interests of a malicious actor. From the system's perspective, nothing is wrong: it is still following instructions. Like a human double agent, it appears loyal while quietly advancing someone else’s objectives. Is all lost? Not at all. These risks are manageable. Practical safeguards include ensuring strong control over the data sources fed to agents, carefully governing LLM invocations, using human-in-the-loop approval for sensitive actions, and applying deterministic policy-based checks that allow or deny agent behavior based on risk.Limiting how context is shared between agents further reduces the chance of unintended influence. As in 1944, a system can follow a coherent plan built on carefully planted signals, confidently and incorrectly. Avoiding this requires treating trust, authority, and control as core architectural concerns. Only when appropriate constraints are in place can AI be trusted at scale and only then can its enormous promise be fully realized.

When an AI Agent becomes a Double agent

Flipping of 2025 to 2026 on wooden block cube for preparation new year change and start new business target strategy concept.

2025 didn’t “break” IAM. It simply exposed its limits.For years, we’ve treated Identity and Access Management as a technical plumbing problem. But as we look toward 2026, the data is clear: the traditional, manual-heavy approach has hit a wall. Enterprises are no longer struggling with technology; they are struggling with complexity at scale.Here are the 5 hard lessons 2025 left behind and why they make LLM-native identity the only path forward.<h3>Lesson #1: IAM projects are still too slow for business reality</h3>We’ve often discussed <a data-mce-href="https://iamones.ai/blog/real-talk--why-your-iam-project-takes-12-months--and-how-to-cut-it-to-3" href="https://iamones.ai/blog/real-talk--why-your-iam-project-takes-12-months--and-how-to-cut-it-to-3">why IAM projects take 12 months</a>, but 2025 proved that the world no longer waits. While business units spin up new AI-driven workflows in days, IAM teams are still stuck in manual onboarding and rigid policy engineering.<ul><li>The Insight: Speed is no longer a "nice to have", it’s a governance requirement. If it takes months to secure a new process, the business will bypass the process entirely, creating massive shadow IT risks.</li></ul><h3>Lesson #2: Automation is not Intelligence</h3>This year, many learned that automating a bad process just makes things fail faster. Traditional workflows are "dumb", they follow triggers but don't understand context. The shift toward <a data-mce-href="https://iamones.ai/blog/reason--plan--act--putting-ai-agents-to-work-in-iam" href="https://iamones.ai/blog/reason--plan--act--putting-ai-agents-to-work-in-iam">Agentic IAM</a> showed us that we need systems that can Reason, Plan, and Act.<ul><li>The Point: If policies can’t reason, they can’t adapt. Static rules fail the moment a user’s behavior or an organization’s structure shifts slightly outside the "if/then" logic.</li></ul><h3>Lesson #3: Compliance is becoming linguistic, not just technical</h3>With the EU AI Act and tighter audit trails, the "how" of access is no longer enough; auditors want the "why." We’ve seen a rise in natural language exploits where the vulnerability isn't a bug in the code, but a flaw in the linguistic logic of a policy.<ul><li>The Insight: The new attack surface is language, and so is the new control layer. To be compliant in 2026, your IAM must be able to explain itself in plain English (or Italian), not just in log files. </li></ul><h3>Lesson #4: IAM teams are drowning in questions, not tickets</h3>The most successful IAM leads in 2025 stopped acting like librarians and started acting like analysts. The bottleneck isn't "resetting passwords" anymore; it's answering complex questions:<ul><li>"What changed after the reorg?"</li><li>"Who has access to our sensitive financial LLM, and why?"</li><li>"Which identities are currently exhibiting risky patterns?"</li><li>The Conclusion: In 2026, IAM will be judged on answers, not workflows. Efficiency is now measured by the time it takes to get a reliable insight. </li></ul><h3>Lesson #5: The market validated the shift</h3>2025 was the year LLM-native IAM moved from "interesting" to "credible." Through strategic partnerships and "Rising Star" recognitions, we’ve seen real-world pilots replace thousands of manual hours with AI-native reasoning. The skeptics have been quieted by the ROI of early adopters.<h3>2026: The Year of Language-First Identity</h3>2026 won’t be about "adding AI" to your existing IAM. It will be about re-thinking IAM as a language-first system. The legacy approach of building rigid silos is ending. We are moving toward a future where identity is fluid, conversational, and deeply intelligent.At IAMONES, we didn't just add a chatbot to a legacy platform; we built the system for this exact shift. We believe the future of security isn't just about locking doors, but about understanding who is walking through them and why.Ready to see how LLM-native identity can solve your 2025 "audit pain"? <a data-mce-href="https://iamones.ai/contact" href="https://iamones.ai/contact" data-mce-selected="inline-boundary">Let’s talk about your use case</a>.

What 2025 Taught Us About IAM and Why 2026 Will Be the Year of LLM-Native Identity

Can We Talk as difficult conversation concept

For decades, we’ve been told a lie about Identity and Access Management: that it has to be complex. That it requires armies of consultants, endless lines of code, and rigid interfaces that feel like they were designed in another century.We’ve been forced to accept that translating simple business needs into system policies should be a slow, painful, and expensive process.Well, the era of accepting that is over.IAM is standing at a crossroads, and the old road is a dead end. While legacy vendors, even those in the cloud, continue to pile new features on top of outdated, "pre-LLM" architectures, a tectonic shift has happened.We call it being ‘Born-on-the-LLM.’It’s a new paradigm where the user interface isn't a complex web of menus and buttons, but the most natural one in the world: your own language. At IAMONES, we’re not just bolting a chatbot onto an old engine. We’ve built a platform from the ground up where you can “Ask anything, Configure everything, using only your Mother Tongue.”What does this actually mean in practice?<ul><li>Instead of coding a workflow, you state your intent: "If a non-manager requests a new permission, the request must first be approved by their manager. If risk is high, route to Andrea Rossi for final approval.”</li><li>Instead of wrestling with rule engines, you define a policy: "If a user has both AP Accounting and Invoice Approval roles in SAP, classify it as a High-Risk SoD violation.”</li><li>Instead of manually building campaigns, you give an instruction: "Create an access review for all Finance managers. They must review their team's SAP permissions within 15 days. Escalate any non-completed reviews."</li></ul>This isn't an incremental improvement. It's a complete transformation from a technical exercise into a conversational dialogue.But how do you get there without ripping and replacing the systems you already have? And how do you separate the real, LLM-native platforms from the marketing hype?In our new white paper, "Talk, don't Code", we break down this new reality. We detail the pragmatic journey to Conversational IAM, starting with augmenting your current IGA platform to eliminate the friction, then moving to a smarter, more agile future.Ready to stop wrestling with outdated systems?[<a data-mce-href="https://iamones.ai/white-paper" href="https://iamones.ai/white-paper" target="_blank" rel="noopener">Download the full white paper: "Talk, don't Code" now</a>]

Talk, Don’t Code: Why Your IAM Strategy Is About to Change Forever

iamones

identity & access management

Poppins

Roboto

This website uses cookies. Please refer to the Privacy &amp; Cookie policy for more details.

Blog

IVIP: Pearl Jam, Nirvana, or Screaming Trees?

Your Next 100 Identities Won't Be Human

Why human review still matters, even with AI

When an AI Agent becomes a Double agent

What 2025 Taught Us About IAM and Why 2026 Will Be the Ye...

Talk, Don’t Code: Why Your IAM Strategy Is About to Chang...