Identity management has spent two decades solving for the login event. AI agents don't have one. Redefining IAM for that reality is forcing a debate the industry has been sidestepping - and the answer isn't more integration. It's authority. You can't govern what you can't see, and no amount of new UI on top of the old model changes what it can see.
Every few years, identity and access management gets a new word or acronym. Federation. Governance. Zero trust. Fabric. Each one shows up promising to be the framework that finally makes sense of the chaos, and each one solves a real piece of it. But there's a pattern worth noticing: every one of these words describes how identity systems connect vs. what happens when identity acts. This is where redefining IAM stops being a marketing slogan and becomes an architectural requirement.
That gap didn't matter much when the thing acting was a person. It matters enormously now that the thing acting might be an AI agent running continuously, calling APIs across a dozen systems, making decisions no one is watching in real time.
Understanding where IAM needs to go from here means being honest about three different timelines at once: how the model we all inherited came to be built the way it was, why that model is already buckling under weight it was never designed to carry, and what actually has to replace the part that's buckling. Call it the ghost of IAM past, present, and future - three timelines, one architecture problem, and one honest answer to what redefining IAM actually requires.
Part One: The Ghost of IAM Past - How We Got Here
This is not an argument against identity fabric as a concept. It's a genuine and much-needed piece of architecture, and it needs to live and be owned by the customer. But it's being asked to do a job it wasn't built for, and the sooner IAM leaders separate what a fabric is good for from what it isn't, the sooner they can stop mistaking a better dashboard for a different foundation.
What IAM Was Actually Built to Do
It's worth being honest about the design center of modern IAM, because the industry tends to skip this step and jump straight to the roadmap. Modern identity and access management was built around a single, well-defined moment: authentication. A user shows up, presents credentials, and a system decides whether to let them in. Everything downstream of that - role assignment, policy enforcement, access review, deprovisioning - was designed as bookkeeping around that one event. Governance platforms track who should have access. Access management platforms decide who gets in. Privileged access tools wrap an extra layer of control around the accounts that matter most.
It's a coherent model, and for a long time it was the right one, because the overwhelming majority of identity activity really did originate at a login screen, from a human being, on a schedule an audit team could reason about.
That assumption has been quietly wrong for longer than most identity programs would like to admit. Service accounts, hardcoded credentials, machine-to-machine tokens, and legacy authentication flows built directly into applications have been running outside that model for years - authenticating, executing, and moving data without ever touching the identity provider that governance teams believe is the front door. Most enterprises have made peace with this. It shows up in the numbers: Orchid's own analysis across enterprise environments found that 46% of identity activity already occurs outside centralized IAM visibility entirely. Call it dark matter. Call it technical debt. Either way, it's not new, and it's not shrinking.
What's new is the thing accelerating it.
The Fabric Answer
Faced with sprawl like this, the instinct - a reasonable one - has been to stitch things together. Connect the IdP to the IGA platform. Connect the IGA platform to the PAM tool. Connect that to the CIEM tool watching cloud entitlements, and the CASB watching SaaS, and whatever discovery tool is watching the gaps between all of them. Give the whole thing a name that implies coherence. Identity fabric is that name.
As for architecture, it's not wrong. Enterprises genuinely have a dozen identity-adjacent tools that don't talk to each other, each with its own partial view, each confidently wrong about the parts of the environment it can't see. A fabric that unifies those views, correlates the signals, and gives security teams one place to look is a real improvement over the status quo of a dozen disconnected consoles and a shared spreadsheet nobody trusts.
But look closely at what a fabric actually is, and the limitation becomes obvious: it's a way of connecting things that are already connectable. It weaves together what each underlying tool was already able to declare about itself. The IdP reports what it knows. The IGA platform reports what it governs. The fabric layer sits above all of it, correlating declarations into something that looks unified.
That's the ceiling. A fabric can only be as honest as its inputs, and its inputs are declarations - configuration, policy, provisioning records, the identity system's own account of itself. It has no mechanism for discovering the identity activity that never got declared in the first place: the API key hardcoded into an application five years ago, the service account created directly in a database, the authentication flow built into custom software that predates every identity standard the fabric was designed to weave together.
Weaving harder doesn't fix that. You can add more strands to a fabric and still never reach the parts of the environment that were never part of the loom.
Part Two: The Ghost of IAM Present - Where the Model Is Already Breaking
That distinction matters more than usual right now, because the identity market is in the middle of a rebrand. A wave of new IGA vendors is currently marketing itself as the AI-native answer to legacy governance - faster onboarding, cleaner UI, "AI-powered" workflows, sometimes the explicit promise to replace the IGA stack outright. It's worth asking, plainly, what's actually new about most of it. In almost every case, the answer is the interface, the deployment speed, and the marketing copy. The underlying model - connect to what's connectable, read what's declared, present it back through a better screen - hasn't moved. That's not a new foundation. It's the same foundation with faster onboarding, and calling it AI-native doesn't change what it can and can't see.
Redefining IAM Isn't a Marketing Makeover
It's worth naming this directly, because the marketing is loud enough right now that it deserves a direct answer: a new company standing up faster connectors, a cleaner graph view, and an AI-generated access review is not redefining IAM. It's the same declarative ceiling with a better sales deck.
Ask the question that actually matters, not the one the demo is built to answer. Not "can it show me a slicker map of my entitlements" - almost anything can, at this point. Ask: "can it tell me about an identity that was never connected to it in the first place?" Every connector-based platform, no matter how new the logo or how fast the deployment promise, answers that question the same way the last generation did: no. It can only report on what is agreed to be seen. A faster way to read a declaration is still reading a declaration.
This is not a small point of architecture trivia. It is the entire question. An identity program built on a faster version of the same model will onboard applications faster, generate prettier access certifications faster, and still have no idea what's happening inside the custom claims-processing app from a decade ago, or which of last quarter's forty new AI agents picked up a credential nobody assigned it. Speed to a wrong answer is not progress. It's a wrong answer delivered with better UX.
The honest test for any "next-gen" identity platform is the same test a fabric fails: does it discover, or does it only connect? If the pitch is discovery and the architecture is API calls and declared configuration under the hood, the pitch is marketing, not a redefined IAM model. You can't govern what you can't see - and no vendor, however new, gets to redefine "see" to mean "what was already willing to be integrated."
Where the Model Breaks: Speed
None of this was fatal when the primary users of identity were human beings, because humans are slow, and slow systems tolerate blind spots. An unmanaged service account sitting dormant for years is a finding on a pen test report. It's rarely the thing that ends a company.
AI agents change the arithmetic entirely, and not because they're malicious - because they're efficient. An agent given a task will find the fastest path to complete it, and the fastest path is often whatever credential is already sitting there: a broad service account, a long-lived API token, a permission that was provisioned once and never revisited. Agents don't authenticate the way people do. They don't log in at 9 a.m. and log out at 5. They run continuously, span applications without a discrete login event a fabric could observe, and generate activity at a volume and speed no human review process was built to keep pace with.
Gartner's inaugural Market Guide for Guardian Agents put the structural problem plainly: AI agents introduce risks that outpace human review, and most enterprises are unprepared to manage them because of fragmented organizational structures and ongoing discovery challenges. Fragmented structure is exactly what a fabric is supposed to solve. Discovery is exactly what it can't.
This stress test identity fabric was never designed to survive. A fabric can tell you, with increasing confidence, what your declared identity estate looks like. It cannot tell you what an autonomous agent actually did inside an application three layers below the identity provider, using a credential nobody remembers issuing. And the number of agents operating that way is not a rounding error - most organizations today have no centralized inventory of the agents already running in their environment, no visibility into what they're doing, and often no clearly assigned human owner for any of them.
Ask a fabric to govern that, and it will confidently report on the part of the estate it can see, and stay silent about the part it can't. Silence, in this context, is indistinguishable from safety until it very much isn't.
A Scenario Worth looking at
Picture a fairly ordinary enterprise environment: an internal claims-processing application, built a decade ago, with its own local user table and a service account issued years back so a batch job could pull nightly records. Nobody on the current identity team provisioned that account. Nobody has looked at it since the engineer who set it up left the company. It sits in the fabric's view as, at best, a line item nobody flagged - because the fabric only knows what the application was willing to declare about itself at onboarding, and this one was never onboarded at all.
Now an AI agent is deployed to help the claims team triage backlogged cases faster. It's given a scoped task and a reasonable amount of autonomy to call the tools it needs. Somewhere in its execution path, it discovers that the batch service account still has standing access to the claims database - because agents, like any efficient system, will use whatever credential is already available rather than request a new one through a workflow nobody built for them. It pulls records well outside its assigned task, not out of malice, but because nothing told it not to, and nothing was watching closely enough to notice in the moment.
Every dashboard in the identity fabric would look clean the entire time. The IdP has no login event to show, because there wasn't one. The IGA platform has no policy violation to flag, because the account was never in its governed inventory to begin with. The first anyone learns about it is a data access complaint three weeks later, followed by the uncomfortable exercise of reconstructing, after the fact, what an autonomous system did with a credential the identity program didn't know existed.
This is not a hypothetical edge case. It's the default outcome of pointing an efficient, task-driven agent at an environment where identity dark matter already exists - which, per the research above, is nearly all of them. A control plane changes this story at exactly one point: it would have seen that service account authenticating in real time, at the point of execution, regardless of whether it was ever declared to the fabric - and it would have had the standing to act on what it saw before the three-week gap opened up.
The Pushback, and Why It Misses the Point
Any identity leader who has sat through a platform vendor's roadmap slide in the last eighteen months has heard some version of this rebuttal already: "we do that too - our fabric has risk scoring, behavioral analytics, anomaly detection." It's worth taking that pushback seriously rather than waving it off, because there's a real distinction hiding underneath it.
Behavioral analytics layered on top of a fabric is still analyzing the data the fabric was able to collect - which is, again, whatever the underlying tools were willing to declare. Scoring the risk of accounts you already know about is a genuinely useful capability. It is not the same capability as discovering the accounts you don't know about, and no amount of analytics sophistication changes what data was available to analyze in the first place. A very smart model built on an incomplete dataset is still working from an incomplete dataset.
The other version of this pushback comes from identity threat detection tools that monitor for anomalous behavior against known baselines. That's a real and valuable function - but it depends on having a baseline to compare against, and the accounts operating outside IAM visibility entirely never established one. You cannot flag anomalous behavior from an account your detection tooling never knew was there to begin with.
None of this is an argument that existing tools are worthless. It's an argument that "we already do observability" usually means "we observe what we were already connected to," which is precisely the ceiling this piece has been describing since Part One. The test is simple enough to ask in any vendor conversation: can this system tell me about identity behavior in an application it was never integrated with, using a credential it was never told to look for? If the honest answer is no, it's a fabric capability wearing control plane language.
Part Three: The Ghost of IAM Future - The Control Plane We Actually Need
The Case for a Control Plane
This is what redefining IAM actually looks like once the marketing is stripped away: not a new dashboard, but a new source of truth. If a fabric is fundamentally about connecting declared systems, the alternative worth taking seriously is a layer that doesn't rely on declarations at all - one that observes identity behavior at the point where it actually executes, inside the application itself, and treats that ground truth as the thing everything else should be measured against.
Call it a control plane, because that's the right word for it, and because the distinction from "fabric" is not cosmetic. A fabric connects. A control plane decides. A fabric is an architecture for visibility across systems that already agree to be seen. A control plane is a layer of authority that sits closer to execution - observing what identities actually do, comparing it to what should be happening, and feeding that context back into the governance and access tools that depend on it.
The practical difference shows up immediately once you ask what each one can answer. A fabric can tell you which service accounts are registered in your IGA platform. A control plane can tell you which service accounts are actually authenticating right now, including the ones your IGA platform has never heard of - because it's not reading a declaration; it's watching execution: how authentication and authorization logic actually behave inside an application, at the binary and configuration layer, rather than how they were configured to behave on paper. That's the difference between a system that reports what it was told and one that reports what happened.
This matters for identity teams for a mundane reason before it matters for a dramatic one. The mundane reason is audit prep: a control plane that observes actual identity behavior can tell a compliance team, on demand, whether NIST or SOX controls are genuinely implemented at the application layer - not whether a policy document says they should be - which turns a quarterly scramble into something closer to a standing answer. The dramatic reason is AI agents: five principles worth building toward - human-to-agent attribution so every action traces to an accountable owner, a complete activity chain from agent to tool to action to target, access decisions evaluated continuously rather than granted once and forgotten, just-in-time elevation instead of standing privilege, and automated response when behavior crosses a line - are only possible if something is actually watching execution. A fabric weaving together declared configurations has no way to enforce any of them, because none of them are declarative problems. They're runtime problems.
Fabric vs. Control Plane Is the Wrong Framing
Here's the complication, and it's worth thinking about it instead of resolving too quickly: fabric and control plane are not really competing for the same job, and framing this as a bake-off misses the more useful question.
A fabric answers "how do my identity systems talk to each other?" A control plane answers "what is actually happening, and what should happen right now." Those are different questions, and most enterprises need answers to both. The mistake isn't building a fabric. The mistake is assuming that once you've built one, you've also answered the second question - that connecting your declared systems is the same as knowing what's true.
It isn't. And the organizations that will handle the next five years of identity risk well are the ones that stop treating "we integrated our identity stack" as equivalent to "we know what our identity stack is missing."
The right architecture, if there is one, treats the control plane as the source of ground truth and the fabric as the distribution layer for it - closing the loop rather than replacing it. Discover what's actually happening at the application layer. Feed that context into the IGA platform, the IdP, the PAM tool, whatever fabric already exists. Let the fabric do what it's good at: presenting a unified, correlated view to the humans who need one. Just stop asking it to discover things it structurally cannot see.
What This Means for the Next Eighteen Months
Set the philosophical debate aside for a moment. There are concrete things identity and security leaders should be doing now, before the AI agent question becomes an incident report.
- Stop treating non-human identity as a subcategory. Machine identities already outnumber human ones by a wide margin in most large enterprises, and that ratio is only widening. Any governance program still organized around "users, plus some service accounts we handle as an exception" is structured around a population that no longer represents the majority of the risk.
- Separate discovery from integration. Integration projects answer "how do we connect what we already know about?" Discovery answers "what don't we know about yet?" Most identity roadmaps are entirely made of the first kind of project. Budget for the second kind explicitly, and don't let it get absorbed into "we'll get to it after the fabric rollout."
- Build for attribution, not just access. The question that matters when something goes wrong with an autonomous agent isn't "did it have access" - it almost certainly did, because agents are good at finding access. The question is "who is accountable for what it did with that access." If your architecture can't answer that today, for a single agent, it will not answer it at scale for a hundred.
- Assume static credentials are already a liability, not a future one. Every enterprise has service accounts, API tokens, and emergency access keys that were issued for a real reason, then forgotten. For a human attacker, those are a known risk. For an AI agent optimizing for task completion, they're simply the path of least resistance - no privilege escalation required, because the privilege is already sitting there.
- Treat continuous observability as infrastructure, not a project. A point-in-time audit tells you what was true on the day someone looked. Identity behavior - especially agent behavior - doesn't hold still long enough for that cadence to mean much anymore. The organizations that adapt well won't be the ones that ran a better audit. They'll be the ones that stopped needing to wait for one.
None of this requires abandoning the identity fabric you've already built, or the governance program you've spent years maturing. It requires being clear-eyed about what that investment can and can't tell you, and building the layer underneath it that can.
Redefining IAM for What's Actually Coming
The organizations asking the sharpest questions about IAM right now aren't asking how to add another connector. They're asking a more uncomfortable question: if an AI agent did something inside our environment today, could we tell you what it did, why it had the access to do it, and who was accountable for that access - without waiting for an audit to find out?
Most cannot answer that yet, and that's not a criticism of any single vendor or platform. It's a consequence of building two decades of identity infrastructure around a login event that autonomous software simply doesn't generate. The fabric metaphor made sense when the job was connecting systems that already knew how to describe themselves. It stops making sense the moment most identity activity happens inside applications that were never asked to describe themselves at all. And rebranding that same connect-and-declare model as "AI-native governance" doesn't move the moment either - it just moves the marketing.
The next chapter of IAM infrastructure isn't going to be won by whoever ships the fastest connector or the cleanest AI-assisted access review. It's going to be built by whoever solves the actual constraint: seeing identity behavior at the point where it happens, not the point where it was declared. That's a different foundation, not a different UI on the same one - and it's the foundation Orchid Security is building. Not a rip-and-replace of the fabric or the governance program already in place, but the control plane underneath it: ground truth from inside the application, at the point where identity actually behaves, fed back into the tools that depend on knowing it.
Every vendor claiming to reinvent identity governance right now should be able to answer one question without flinching: can you see the identity activity that was never declared to you? If the honest answer is no, the rest of the pitch is a faster way to be wrong. If the industry is serious about getting ready for a world where most identity activity belongs to software, not people, this is the question that decides who's actually built for it.
You can't govern what you can't see. IAM doesn't need a new word for connecting what's already visible. Redefining IAM means building the infrastructure that makes the invisible part answerable - and the authority to act on it before something else does.
