Years of Building IGA. Here's What's Still Broken.
I need to say something uncomfortable: I helped build the thing that's broken.
Twenty-six years. IBM, then Oracle. I worked on identity governance platforms that are still running in production at some of the largest enterprises in the world. Certification campaigns, role modeling, access request workflows, segregation-of-duty policies — I helped design and ship those capabilities. Some of them genuinely made organizations safer.
But I also watched the industry calcify around architectural decisions we made in 2005. Decisions that made sense when every identity was a human with a badge, when "the cloud" was a whiteboard sketch, when the idea of an AI agent autonomously requesting database access would have sounded like science fiction.
Those decisions are now load-bearing walls. And the problems they create cannot be fixed in a point release.
What we got right
Credit where it's due. The first generation of IGA solved real problems.
Before certification campaigns, nobody systematically reviewed who had access to what. Managers inherited teams with years of accumulated entitlements and no way to audit them. We built the tooling that made periodic review possible. That mattered.
Role-based access models gave organizations a way to think about access in terms of job functions instead of individual system permissions. Access request workflows replaced email chains and help-desk tickets with auditable, policy-driven processes. These were genuine advances.
I am proud of that work. It moved the industry forward.
But "forward" in 2005 is not the same as "adequate" in 2026.
Six things that are still broken
These are not edge cases. These are structural failures in how the entire industry approaches identity governance. I know, because I was in the room when some of these architectural trade-offs were made.
1. "Revocation complete" is a lie
Every IGA platform I have worked on — and I have worked on several — handles revocation the same way. Send a request to the target system. Log the request. Mark the ticket closed.
Nobody goes back to check whether the access was actually removed. The HTTP 200 from the API call becomes the proof of revocation. But an HTTP 200 means "I received your request." It does not mean "the access is gone." The PAT is still valid. The IAM role is still attached. The service account password still works. Your audit trail says "revoked." Reality says otherwise.
2. Audit trails live in databases that admins can edit
Here is something auditors rarely ask: where is the audit log stored? In most IGA platforms, audit records sit in the same relational database as everything else. The same database that your platform admins — and your DBAs — have write access to.
I have seen it happen. Not maliciously, usually. A support engineer "fixes" an audit record to resolve a discrepancy. A migration script overwrites timestamps. A bulk cleanup job deletes "orphaned" records that turned out to be evidence. The audit trail is only as trustworthy as the access controls on the database. And those access controls are managed by the same people the audit trail is supposed to hold accountable.
That is not evidence. That is a document that someone promises they didn't edit.
3. Safety rules are configuration toggles
Segregation-of-duty rules, approval workflows, risk thresholds — these are the safety mechanisms that prevent dangerous access combinations. In every platform I have built or evaluated, they are stored as configuration. An admin with the right role can disable them. Sometimes with a checkbox. Sometimes with a bulk import. Usually with no countersignature, no cooling-off period, and a log entry that is trivially lost in the noise of routine configuration changes.
One admin, one click, and your most critical safety invariant is gone.
4. Non-human identities are afterthoughts
The IGA platforms I helped build were designed for humans. The data model assumes a person: a name, a manager, a department, a job title. Non-human identities — service accounts, API keys, machine credentials — were bolted on later, shoehorned into a human-shaped data model that doesn't fit.
Service accounts don't have managers. API keys don't go through onboarding. Machine credentials don't attend certification campaigns. Yet the industry governs them — when it governs them at all — with tools designed for people who show up to an office and have a photo on their badge.
5. AI agents are completely ungoverned
This is the one that made me leave.
AI agents are the fastest-growing identity type in the enterprise. They request access, delegate to sub-agents, make decisions with real consequences, and operate at machine speed. They are not humans. They are not service accounts. They are a new category entirely — autonomous, adaptive, capable of acquiring and exercising permissions in ways no static policy can anticipate.
No production IGA platform has purpose-built governance for AI agents. Not SailPoint. Not Saviynt. Not the platforms I helped build. The industry is governing the most consequential new identity type with tools designed for a world that no longer exists.
6. Compliance is reconstructed after the fact
This one is endemic and invisible. When an auditor asks "prove that this access change was authorized, executed, and verified," every IGA platform I know does the same thing: it queries the database, assembles records from multiple tables, and presents a reconstructed narrative.
That narrative is only as reliable as the database it was assembled from (see item 2). It is not proof. It is a story, told after the fact, by the system being audited. The system is grading its own homework.
Why I left
The current generation of IGA platforms were not wrong about the problems. They were right about the problems, and the products they built addressed those problems well.
I left because the problems changed and the architecture can't.
You cannot retrofit cryptographic evidence into a system designed around database audit tables. You cannot make safety invariants immutable in a platform where everything is configuration. You cannot bolt AI agent governance onto a data model designed for humans with badges. These are not feature gaps. They are architectural constraints. They are in the foundation, and you cannot fix the foundation of a building while people are living in it.
Some problems require a clean sheet.
What SidantiX is
SidantiX is my answer to the six problems above. Not all of identity governance — the specific failures I just described.
Every access decision produces an ECDSA-signed receipt, hash-chained into a tamper-evident evidence pack. That is not an audit log in a database. It is cryptographic proof you can verify offline with standard tools. That addresses items 2 and 6.
Safety invariants — SoD rules, approval requirements, risk thresholds — are enforced as immutable code, not configuration toggles. No single admin can disable them. No override without cryptographic countersignature. That addresses item 3.
Revocation runs five steps: Signal, Evaluate, Revoke, Verify, Seal. The platform polls the target system to confirm access is actually removed, and produces a signed receipt proving it. Not "we asked." "It's gone." That addresses item 1.
Non-human identities and AI agents are first-class citizens in the data model. Not bolted on. Architected from day one with their own lifecycle, their own governance primitives, their own kill switches. AI agents get purpose-built controls: scoped delegation, runtime behavioral bounds, one-second emergency revocation. That addresses items 4 and 5.
The honest caveat
SidantiX is early.
We do not have the connector breadth of SailPoint. We do not have the enterprise install base of Saviynt. We do not have twenty years of partner ecosystem or thousands of production deployments.
What we have is the right architecture for where the industry is going. An architecture that treats cryptographic proof, immutable safety, and AI agent governance as foundational — not features to be added in a future release that never ships.
I spent years building the current generation. I know what it does well. I also know what it cannot do, no matter how many point releases you ship. SidantiX is the next generation — built by someone who understands exactly why the last one isn't enough.
About the author: SidantiX is founded by an identity governance veteran with over two decades of experience building IGA and access management platforms at major enterprise software companies. SidantiX is an AI-native IGA platform delivering autonomous governance for humans, non-human identities, and AI agents — with cryptographic proof on every access decision.