Blog

Panoramic view of large-scale multi-building renovation project with extensive scaffolding systems installed across multiple facades during golden hour lighting.

Employees and business leaders know what they want. They write it down in clear, beautiful business specifications. Yet, months later, the IAM system delivered looks nothing like what they asked for.The question is how much time and budget you will waste before realizing the traditional delivery model is fundamentally broken.The industry loves to blame "lack of governance" or "poor stakeholder alignment." But those are just comfortable excuses. The real culprit is the translation gap.<h3>The Translation Gap: Where Business Specs Go to Die </h3>In a typical IAM project, the Business spends weeks defining access policies, lifecycles, and security rules. They hand these documents over to "Product Specialists": technical gatekeepers who are supposed to configure the platform.Nevertheless, Product Specialists often don’t understand the business context. Instead of implementing the business logic, they drag the project into endless loops of technical jargon, custom coding, and configuration workarounds.The result? The business specification is watered down, the timeline doubles, and you end up with a rigid system that fails to meet your actual security or compliance needs.Historically, this was the only way. You needed a translator because machines didn’t understand human intent.But today, language is the new code.With the rise of Large Language Models (LLMs), the middleman is no longer necessary. We now have the technology to let the business specification be the code. By translating business-friendly, natural language directly into execution, we eliminate the translation gap, bypass the product specialist bottleneck, and deploy what the business actually asked for, instantly.<h3>The Five Strategic Pitfalls of Traditional IAM </h3>While the technology to close this gap exists, many organizations remain trapped in legacy thinking. They treat IAM as a software configuration task rather than a strategic business initiative.According to our experience with large enterprise clients, these are the five strategic pitfalls that still bring IAM projects to failure:<ul><li>Thinking IAM is just about SSO: Single Sign-On is just the front door. The real risk lies in lifecycle management, deep entitlement structures, and non-human identities.</li><li>Deploying without proper governance: Automating a broken process just creates automated chaos at scale.</li><li>Underestimating privileged accounts: Leaving administrative credentials outside the core IAM governance framework leaves the keys to the kingdom exposed.</li><li>Treating IAM as an IT project: If business departments aren't driving the identity requirements, the system will inevitably become a roadblock to productivity.</li><li>The "One-and-Done" fallacy: Validating access rights once during a project’s go-live phase and never continuous-monitoring them as the enterprise evolves.</li></ul><h3> How IAMONES is Changing the Game </h3>Traditional IAM implementations are static, slow, and reliant on expensive army-of-consultants models.At IAMONES, we approach Identity Security with a broader, modern vision. We believe that securing identities shouldn't require a constant battle of technical translations.By leveraging LLM-driven automation and our deep enterprise experience, we help organizations bypass the "Product Specialist trap" entirely. We align your identity infrastructure directly with your business logic, ensuring your security policies are defined in plain language, executed automatically, and adapted dynamically.The era of long IAM deployments is over. The organizations that succeed won't be the ones hiring more configuration specialists, but the ones letting business intent drive identity security directly.

Why IAM Projects Keep Failing: The Death of the Product Specialist

Intricate geometric shadow patterns from ornate window lattice moving slowly across neutral wall.

Employees are already using AI tools you don’t know about. The question isn’t whether it’s happening, it’s how much damage it’s causing, silently, right now.That’s Shadow AI, the use of AI tools, models, and services by employees without the knowledge or oversight of the IT or security team.It's not a future risk, according to IBM's 2025 Cost of Data Breach Report, one in five organizations has already experienced a breach linked to unsanctioned AI, yet only 37% of organizations have any governance policy in place to detect it. The other 63% are totally blind.<h3>Why is Shadow AI an Identity Problem?</h3>Shadow IT has always existed, someone buys a Dropbox subscription on a company card, a team starts using Notion without approval. Security teams learned to contain it.Shadow AI is different. It's not just an unapproved application, it's a reasoning engine your employees are actively feeding with proprietary data. The moment a developer pastes internal source code into ChatGPT, or an analyst uploads a confidential spreadsheet to a consumer AI tool, that data has left the building. No firewall rule brings it back.More than 80% of workers already use unapproved AI tools, nearly half through personal accounts that bypass enterprise controls entirely. For identity professionals, this means unmanaged Non-Human Identities with no lifecycle or owner, accounts that sit completely outside your IGA system, and compliance exposure you can't explain. GDPR, NIS2, DORA all assume you know where your data is, IBM puts the average remediation cost above € 600,000.<h3>Solutions? </h3>Well, the two instinctive responses to Shadow AI are either blocking everything, or ignoring it.Blocking is ineffective. Employees route around it through personal devices and browser-based tools. Research shows nearly half would continue using personal AI accounts even after a formal ban.Ignoring it is worse. Gartner predicts more than 40% of enterprises will experience a security or compliance incident linked to unauthorized Shadow AI by 2030.The real answer is visibility-first governance:<ul><li>Discover what's already there: identify which AI tools are in use and which identities are connected to external models, at the identity layer, not just the network layer.</li><li>Treat AI agents as first-class identities: register, scope, and govern every agent or automation that touches enterprise systems, with least-privilege access and a defined lifecycle.</li><li>Offer a sanctioned alternative: employees use Shadow AI because it solves real problems. If there's no approved alternative, circumvention will continue regardless of policy.</li></ul><h3> Conclusion</h3> Traditional IGA wasn’t built for this. Static roles and quarterly certification campaigns don't catch an autonomous agent quietly connected to a shared service account last Tuesday.Effective Shadow AI governance requires continuous, contextual visibility into the temporal dimension of identity: who had access, when, under what conditions, and whether it's still appropriate today. That's exactly what the IAMONES Temporal Identity Graph is designed to answer, making it possible to ask questions that traditional IGA cannot: Who connected that agent to our directory? When was this agent used ? Has this NHI ever been reviewed?Shadow AI isn't going away. The organizations that get ahead of it won't be the ones that blocked ChatGPT at the firewall. They'll be the ones that built identity governance capable of keeping pace.

Shadow AI: An Identity Risk perspective

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

iamones

identity & access management

Poppins

Roboto