Ask a simple question in any security review: "Who can access this database?"
Watch what happens. Someone opens the directory and lists a group. Someone else points out that the group contains three nested groups, one of which syncs from HR. A third person remembers the SaaS admin console grants access directly, outside the directory. Nobody mentions the service account with a connection string, because nobody remembers it exists.
The question sounds trivial. It is one of the hardest questions in enterprise IT.
Why "who can access what" is so hard
Access in a real organization is not a table — it is a graph, and an unruly one:
- Nested groups mean membership is transitive: you are in group A, A is in B, B grants the permission. Three hops later, nobody can trace the chain by hand.
- Roles and entitlements add indirection: the role bundles permissions, the permission maps to resources, and role definitions drift over the years.
- SaaS entitlements live outside your directory entirely. Every application has its own admin model, its own sharing settings, its own idea of "admin."
- Service accounts and non-human identities — including a fast-growing population of AI agents — hold standing access that rarely appears in any review.
Each system can answer for itself. Nobody can answer across them. And attackers exploit precisely the paths that span systems: the dormant account in a forgotten group that reaches, four hops later, a production credential.
Gartner gives the problem a name
In 2025, Gartner defined a category for tools built to close this gap: Identity Visibility and Intelligence Platforms (IVIP) — flagged as an early-adoption category that consolidates identity data from across the environment and turns it into answers. The category is young, but the capabilities it names have quickly become the shopping list for identity visibility work.
The core capabilities
A unified identity graph. The foundation is correlation: ingesting identities, accounts, groups, roles, and entitlements from directories, IdPs, HR systems, cloud platforms, and SaaS apps — then resolving that the "j.smith" in AD, the "[email protected]" in the IdP, and the "John S." in the CRM are the same human. Without correlation, every count of "how many identities do we have" is fiction.
Effective access, with the exact path. The headline query: not what someone was assigned, but what they can effectively reach — with the full chain shown. John can modify the finance database because he is in Group A, which is nested in Group B, which holds the db-writers role. The path matters as much as the answer, because the path is what you fix.
Blast-radius analysis. The same graph, traversed in reverse: start from a resource — or a compromised account — and ask what it reaches. When an account is breached at 2 a.m., "what could this identity touch?" is the first question the incident team asks, and the only good answer comes from a graph that already exists.
Posture findings. Continuously scanning the graph for risky patterns: orphaned accounts whose owners have left, dormant-but-entitled identities that have not logged in for months yet still hold privileged access, separation-of-duties (SoD) conflicts where one person can both create and approve, and ownerless agents — non-human identities nobody is accountable for. This is the analytical core of identity security posture management, running on the graph instead of on per-system checklists.
The differentiator: can it fix what it finds?
Here is the fault line inside the category. Most visibility tools are read-only overlays: they connect to your systems with read scopes, build the graph, and produce findings. Then the finding becomes a ticket, the ticket goes to another team, that team makes the change in yet another tool — and weeks later someone re-checks whether the graph agrees.
A platform that owns the control plane — the IdP and IGA layer where access is actually granted — can close the loop directly. The finding and the fix live in the same system: remove the dormant account's entitlement, disable the orphan, break the SoD conflict — ideally with a dry-run that previews exactly what will change, and an undo if the change breaks something. Visibility that ends in a ticket queue is a report; visibility that ends in a remediated finding is a control.
Ask in plain language
One more trend worth noting: the interface is shifting to natural language. Instead of composing graph queries, you ask — "Who can access the finance database, and through which paths?", "Which admin accounts haven't logged in for 90 days?" — and the platform translates the question into a graph traversal. This matters more than it sounds, because it moves these answers out of the specialist's toolkit and into the hands of auditors, managers, and incident responders.
Where Monosign fits
Monosign's Identity Intelligence is IVIP built into the control plane rather than bolted on beside it: the unified graph, effective-access paths, blast-radius analysis, and posture findings run inside the same platform that manages the identities — so remediation is a click with a dry-run, not a ticket. For a compact definition of the category itself, see the glossary entry on IVIP.
"Who can access what?" should be a query, not a research project. IVIP is the category for making it one.
