Blog

Close-up of precision chronograph watch with glowing hands and detailed metal bezel, set against soft-blurred global map.

We started IAMONES a little over two years ago, in April 2024.It was based on a simple observation of the IAM market: instead of getting simpler, Identity vendors kept piling complexity on top of complexity. In plain terms, an IAM mainframe. And I have been part of that complexity journey myself. I loved making things very configurable, hence complex.The arrival of Large Language Models (LLMs) then triggered a simple idea: isn’t IAM, at its core, a massive translation problem between two languages, technical entitlements and business language?So, what if we could bridge that gap with the ability of LLMs to understand natural language, and drastically improve both the user experience and the configuration experience of IAM processes?Come on, we all know the current UX is terrible, regardless of the product. And the configuration experience? It takes ages and expensive product specialists.So IAMONES was born. With a few other serial entrepreneurs, we went all in on this crazy journey: building an AI-native Identity player that could make the most of natural language and LLMs. On the Mediterranean. Not the usual Mediterranean suspect though: Italy.Fast forward to August 2026, and I am a little shocked. Positively, but shocked.We had our first bookings already in 2024, we grew 100% in 2025, and we expect to grow another 150+% in 2026.Initially, I would never have thought that today we would be serving several very large, regulated organizations for their IAM modernization needs. Yes, Clients with big, big names you are all familiar with. We now need two hands to count them.So, I ask myself: why did they pick IAMONES? The industry has well-established players. Maybe not AI-native, but massive and established. So why pick us, a new and risky vendor, for something as critical as IAM modernization?<h3>Three main reasons.</h3><h3>#1 They all have a massive tech debt they must live with</h3>Highly configured on-premises IAM products (mainly SailPoint IIQ and One Identity Manager), combined with home-grown developments built to patch what the selected vendor could not provide: a better access request front-end, some role modelling tooling, some data lakes aggregating employee and privileged identities.Ripping all of that out is a multi-year, multi-million programme, and nobody is in a hurry to sign up for it.<h3>#2 A “Cloud yes… but” approach</h3>Clients love the flexibility of the Cloud… but they want to keep control over their data. Data residency, hosting model and exit strategy now come up in the first meeting.We designed for that from the start: Your Data – your IAM Data, your questions, your answers, your configuration prompts, etc. – stay where you want them to be. On premises? Fine. In your trusted hyperscaler? Fine. Your data stays inside the perimeter you – the client – are comfortable with.<h3>#3 An “AI yes… but” skepticism</h3>This is the big one. I would say that half of the reason clients choose us is that we took AI security seriously from day one. The questions we get are always the same. “Where do the prompts go?” “Can the model be tricked into showing me access I should not see?” “What happens to our data?”Our answers are boring, and boring is exactly what a CISO wants to hear:<ul><li>Divide et impera: no single model ever sees the whole question. We never simply “send a question to an LLM”. The Identity Brain breaks every question into discrete sub-tasks and hands each one to a different specialised agent, on a different provider. A useful side effect: our Identity Brain is LLM-provider agnostic.</li><li>PII never reaches the model. Personally identifiable information is stripped programmatically before any reasoning step and re-attached only afterwards. </li><li>Data Visibility is enforced by the database, not by the model. Who can see what is written in natural language, then compiled into Row-Level Security policies that PostgreSQL applies at query time, row by row. Permissions are enforced before the LLM, not after it.</li><li>Everything backstage is recorded, so you can always ask “why”. Not just the question and the answer: which agents were triggered, which instructions were in force, which rule fired, which data was returned.</li><li>And we back all of this with an ISO 27001 certification. Obtained in June 2026 – unusual for a company this young. But it matters to our clients, so we did it.</li></ul><h3>IAMONES, who are you?</h3>We are the IAM modernization choice for the sovereign-obsessed enterprises. The ones who want the simplicity of natural language and AI, but not at the price of losing control over their data.

IAMONES - Two years in retrospect

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

iamones

IAMONES is an AI-native, conversational Identity & Access Management (IAM) platform. Our business is to remove the complexity that makes enterprise identity governance slow, expensive and inaccessible to the people who actually use it.

Our product is a software platform, delivered as a cloud service, that sits on top of the IAM and Identity Governance & Administration (IGA) systems an organization already owns — no rip-and-replace, no migration risk. It consolidates identities, entitlements and access data from across source systems into a single data model with a full historical timeline, and exposes it through a natural-language interface available in the customer's channel of choice (enterprise chatbot, Microsoft Teams, or an embedded web portal).

Key capabilities include:

Conversational access requests — business users describe what they need in everyday language; semantic search finds the right entitlements and indicates the likelihood of approval.
AI-assisted access reviews and certification campaigns — campaign managers configure and scope campaigns by asking; reviewers get context and recommendations to make better decisions.
Natural-language configuration and reporting — policies, workflows and reports are defined and modified conversationally, in any language, and remain directly readable by auditors.
Governance of AI agents — non-human identities and AI agents are modelled and governed alongside human users, where permission overlap creates hidden risk.

We serve mid-size and large enterprises in regulated and security-sensitive sectors, and work through a global partner ecosystem of IAM consulting and managed-service providers. Licensing is usage-based rather than per-seat, so cost scales with actual value delivered. IAMONES was recognized as a Rising Star in KuppingerCole Analysts' Identity Governance & Administration report.

Hanken Grotesk

Bricolage Grotesque

Roboto