Blog

<h3>On why an agent inventory ALONE cannot tell you what your agents can do.</h3>TL;DRAn agent registry tells you that an agent exists and who owns it, which is not the same as knowing what it can do, because capabilitylives in the consent grant, an object that ties three parties together where every primitive in your IGA ties only two. Since the entitlements those grants resolve to sit in the IGA rather than in the tenant, the question of whether an agent can do more than the person using it can only be answered with both worlds in the same graph._________________________When we extended our identity data model to cover agents, we added two core node types: one for the agent, and one for the consent grant that lets it act.The second does the work, and the reason has little to do with agents being a new kind of principal. It is that a consent grant records a relationship between three parties, while every primitive in an IGA records a relationship between two.The belief worth correcting is that an agent inventory tells you what your agents can do. It doesn’t, and that gap is not a maturity problem a better registry will close.<h3>The agent node is the half you already model</h3>Microsoft hands you agents in two shapes. An agentUser is user-shaped, while an agentIdentity is service-principal-shaped. Strip the branding off both and you have a principal with attributes, a status, and a pointer to a responsible human, which you already model, because a service account is a principal with attributes and an owner, and so is an agent.This is why a registry answers less than it appears to. It establishes that an agent exists and who owns it, which is a census, and a census does not describe capability.<h3>Everything you already govern is a two-party relationship</h3>Take any primitive in your IGA and look at its shape rather than its name. A group membership is account → group. A role assignment is identity → role. Even segregation of duties is a constraint over pairs: A and B must not both be held. Two endpoints and one edge is the vocabulary.That vocabulary is complete for a human being. Marco holds the SAP role, and nothing further needs recording, because the subject of the permission and the actor exercising it are the same person. For an agent they are two different parties, and that separation is what the data model has to absorb.A consent grant has three partiesIn Microsoft Graph a delegated permission is an oauth2PermissionGrant entity. Four fields carry the meaning:<ul style="list-style-type: square;" data-mce-style="list-style-type: square;"><li>clientId : the agent, the thing acting</li><li>resourceId : the API being acted against</li><li>principalId : the human whose authority is being used</li><li>scope : a space-separated string of what was permitted</li><li>A fifth, consentType, is either Principal, meaning one user consented for themselves, or AllPrincipals, meaning an administrator consented for the entire tenant.</li></ul>Read the four back as a sentence and you get: this agent, against this resource, on behalf of this human, for these operations. That is three parties where the governance vocabulary holds two, which is why the record cannot sit as an attribute on any one of them.<h3>Marco has 340 entitlements and his agent has four scopes</h3>Let’s make a quick example. Marco is nine years into a finance role, with two internal moves and an acquisition behind him. His identity carries 340 entitlements and in a given week he uses perhaps thirty. Someone builds him an agent to summarise supplier correspondence; it is registered properly, has an owner, and shows a green tick in the inventory. Its grant reads principalId = Marco, scope = Mail.Read Files.Read.All Sites.Read.All.Four scopes looks modest until you resolve them through the third party. Files.Read.All and Sites.Read.All cover everything Marco can reach, a set nobody has enumerated in months and years, including that old project directory left him access to. The over-provisioning belongs to Marco rather than to the agent; what the agent changes is the utilisation rate, because all 340 entitlements are now reachable at machine speed instead of the thirty a person uses in a week.<h3>The 340 entitlements are not in Entra</h3>Resolving Marco’s four scopes requires something the tenant does not contain. principalId identifies him, and Files.Read.All says the agent reaches what he reaches, but the enumeration of what that actually grants, which applications, which roles, which segregation-of-duties rules he sits inside, lives in the IGA platform. That means SailPoint IdentityIQ, One Identity Manager, Oracle Identity Governance, OpenText, and a decade of home-grown role logic around them, most of it on-premises.In IAMONES both worlds sit in the same graph: the classic IGA estate on one side, the agents registered in Microsoft Agent 365 on the other, and the consent record as the edge between them. That edge is what makes the traversal possible: from an agent, to the human whose authority it borrowed, to the entitlements that authority actually carries.<h3>Is there an agent that can do more than the person using it?</h3>This is the question that reveals the privilege leakage agent usage can introduce, and neither an IGA nor Agent 365 can answer it alone. An agent can itself be assigned to roles or groups, and that access adds to what it borrows from the person using it. When the sum reaches further than that person, the agent has become a path to access they were never granted.The bottomline: Agent 365 knows the roles and groups the agent holds. The IGA knows what the person holds. Answering the question means comparing the two. Humans, non-human identities and now agents, answerable together because they are modelled together sitting in the same graph.

Every scope you take, I’ll be watching you

Textbook and pencil on sunlit desk with shifting shadows and floating light particles.

Let me start with a confession: I am bored of reading about AI Agent Control planes. When a market makes this much noise, buyers stop listening.And, at least in Europe, I think I know what could happen next.#1 In all that noise, Europe will simply pick the defaultPut yourself in the shoes of a European CISO. Thirty vendors, thirty of everything. At some point you stop evaluating and you say: “Fine. I go with Microsoft. My users are already in Entra, they use Microsoft productivity tools, Copilot is not great but that’s the approved AI… let us control the agents there too.”C’mon, nobody gets fired for buying Microsoft.#2 The risk is not who the agent is. It is what it does with a human’s permissions.An agent is not dangerous because of its own permissions. It is dangerous because it borrows a human’s. OAuth consent is the source of many evils.An agent acting on behalf of Marco inherits Marco’s entitlements. Marco uses ten percent of them. The agent will use all of them.So the question that matters is “what damage can this agent do when used by Marco? Who is accountable for it?”#3 And in Europe, the answer to that question lives in the IGA basementTo answer it you need job titles, entitlements, roles and &nbsp;applications. And, in the large European regulated enterprises we work with, that information lives in highly configured - mostly on-premises - IGA platforms: SailPoint IIQ, One Identity Manager, Oracle Identity Governance, OpenText and their peers, surrounded by ten years of home-grown extensions.#4 So the real question is deeply unglamorous and, yes, boring“How do I make the old talk to the new? How do I make sense of my current IGA with the new world of AI Agents?”It is the question our clients ask us, once the slides are closed.#5 The industry answer: “we can give you everything - but first, migrate”Every established IAM vendor now has an Agent something in the portfolio.The pattern is always identical: the agentic capability lives in their SaaS, and it only becomes useful once your Human IAM data lives in their SaaS too.Which quietly turns “how do I govern my agents?” into “start a three-year, multi-million migration programme”.In our sovereign-obsessed Europe, data residency, hosting model and exit strategy are no longer procurement footnotes. The migration is not going to happen. And in the meantime, the agents keep multiplying.#6 Our boring strategy: correlate, do not replaceWe are building our IAMONES agentic control capability as an extension of the IAM estate our clients already own. Four boring principles:<ul style="list-style-type: square;" data-mce-style="list-style-type: square;"><li>Agents stay where you registered them. We bet on Microsoft Agent 365, also for non-Microsoft agents. We are not competing for the registry. We have built a very deep integration with EntraID and Microsoft Agent 365.</li><li>We read the Human Identity truth where it already is. SailPoint IIQ, One Identity Manager, Oracle Identity Governance, OpenText. Last but not least, the many home-grown IAM applications. &nbsp;In place, no migration.</li><li>Every agent is tied back to the humans it borrows from. What the agent can reach, which entitlements it inherited from which identity. </li><li>The reasoning happens in Natural Language, because that is the language agents are written in. This is precisely what Born-on-the-LLM means for IAMONES.</li><li><blockquote>IAMONES: What is our agentic strategy? The old IGA world and the new AGENTIC one must talk to each other. That is where we have decided to stand.&nbsp;</blockquote></li></ul>

Our Boring Agentic Strategy

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?

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.

Satoshi

Zodiak

Roboto