Blog

When Alessandro Piscopo and I started IAMONES, we wanted to disrupt and simplify traditional IAM.From a product standpoint - using LLMs in lieu of code - but also from a pricing one.Incumbents price based on named identities: if you have 1 million identities in your identity store, you pay 1 million times their fee.In the AI era, you pay for what you ask. So, we told ourselves: let's make a "price-per-ask" model. However, we soon realized that large Enterprise customers hate unpredictability. At the same time, they recognize that different user personas have different usage patterns.So, we came up with a pricing model that sounds like a jungle:🦍 HUUs (High Utilization Users): Power users who need an "all-you-can-ask" type of plan with no query limits. Typically, up to 5% of the total user population. 🐮 MUUs (Medium Utilization Users): Line managers handling requests, approvals, and reviews, or employees changing departments when birthright policies fall short. These users get a high monthly query limit. 🦥 LUUs (Low Utilization Users): Sporadic users who access the system only occasionally, such as external contractors.And finally: Say you buy 200 HUUs, 2,000 MUUs, and 5,000 LUUs, but your company has 100,000 users. No problem: HUUs, MUUs, and LUUs are not assigned to specific individuals. They act as shared pool credits across your organization.Welcome to the outcome-based IAM pricing model. You can start small with our IAMONES Conversational Identity platform, while maintaining millions of identities.

HUU MUU LUU: A pricing model that sounds like a jungle

<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

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.

Inter

Roboto