A recap of my Identiverse session, for everyone who missed it and everyone who showed up at 7 am with caffeine, courage, and questionable judgment.
Let’s start with the obvious.
A 7am conference session is not for the faint of heart.
It is either dedication, poor calendar hygiene, or the purest form of Type 2 fun.
You know the kind. The one where you question your life choices on the way in, then leave thinking, “Okay, that was actually worth it.”
That was this session.
And that room made the session better than my slides did.
I asked three live questions during the talk. The answers were honest, sharp, occasionally chaotic, and very useful. So I’m sharing the results here, along with the core message from the session.
Because the takeaway is simple:
Most identity programs govern what should happen.
Very few can prove what actually happened.
That is the identity observability gap.
The question nobody has a good answer to
I opened with this:
Can you tell me right now which identities are currently active in your three most critical applications?
- Not who has access.
- Not what the policy says.
- Not what the last access review certified.
What identities are actually doing, inside the application, right now?
That distinction matters because identity does not stop at provisioning. It does not stop at login. It does not stop at the access review.
Identity risk lives in execution.
And most programs are still trying to govern execution with tools built to document intent.
Poll #1: How confident are we, really?
The first Slido question was:
How confident are you that your IAM policies reflect what is actually happening in your apps?
The word cloud did not disappoint.
The biggest answers were:
And my personal favorite:
“How are IAM policies defined?”
Funny? Yes.
Also painfully accurate.
The room understood the gap before I even finished explaining it.
Most IAM programs are built on a very reasonable assumption:
We govern access, so we govern identity.
Sounds logical.
You set the policy. You require MFA. You certify access. You remove orphaned accounts. You pass the audit.
But here is the problem:
Access governance tells you what should be true.
It does not prove what is actually happening.
Controversial Take #1: Your access review is a work of fiction
I said this in the session, and I stand by it:
Your access review is a work of fiction.
Not as an insult.
As a structural observation.
An access review asks: does this person need this access?
Someone answers yes.
Certified. Signed off. Done.
But it usually does not ask what the user actually did inside the app.
It does not always tell you whether MFA was actually enforced.
It may not know that a local admin is still active.
It may miss that a dormant account is still credentialed.
It may not see that an app bypasses MFA entirely.
It may not catch that a “removed” user still has a persistent token.
And it definitely may not know that a service account quietly became the most powerful identity in the room.
Attested.
Certified.
Signed off.
Still wrong.
That is not a process failure. It is a visibility failure.
More specifically, it is an observability failure.
Identity Dark Matter is the baseline
In the session, I talked about Identity Dark Matter: the identities that exist, authenticate, and execute, but never enter the governance workflow.
- Service accounts from finished migrations.
- Credentials that predate the IAM platform.
- Local accounts.
- Tokens.
- Application-specific users.
- Non-human identities with no clear owner.
Before agentic AI, this was already a problem.
Before the agent workforce, this was already the baseline.
AI agents do not create this mess.
They inherit it.
Happily.
Poll #2: Who is accountable when an agent acts?
The second Slido question was:
When an AI agent takes an action using your employee’s credentials, who is accountable?
The answers were all over the place:
One answer captured the whole problem:
“Employee, assuming the enterprise has defined some guardrails.”
That word is doing a lot of work.
Assuming.
When a room cannot converge on who is accountable, that is not a knowledge gap. That is the current state of agentic identity governance.
- Distributed.
- Assumed.
- Undefined.
And that is before we even get to the execution trail.
If an agent takes an action and you cannot trace the agent, the owner, the tool used, the action performed, and the target touched, you do not have accountability.
You have vibes.
And vibes are not a control.
Agents inherit your mess
One of the quotes I shared in the session came from a Fortune 500 security leader:
“The agent executes faster than we can validate. We don’t know what access it used, or what it actually did.”
That is the issue.
Agents do not wait for quarterly access reviews.
They do not pause to check whether permissions are stale.
They do not ask whether access still matches business intent.
They execute.
Every over-permissioned account, forgotten token, unmanaged service account, and identity blind spot becomes part of the agent’s inheritance.
Human mistake becomes permission sprawl.
Permission sprawl becomes Identity Dark Matter.
Identity Dark Matter becomes an agent’s starting inventory.
AI does not create identity problems.
It compounds them.
Efficiently. Rudely. At machine speed.
Controversial Take #2: IAM does not govern identity
IAM governs the pre-defined intention of identity.
That is valuable. Very valuable.
But intent is still a model.
And every model has gaps between what it says should happen and what is actually happening.
The gap between your IAM model and what is executing inside your applications is the execution surface.
That is where the risk lives.
Agents do not operate against your governance model.
They operate against what is available, reachable, and executable.
If the model and reality do not match, and they almost never fully match, that mismatch becomes the problem.
In the agentic era, that distinction will cost you.
Poll #3: Can you actually answer the question?
The final Slido question brought us back to where we started:
Can you tell me right now what identities are actively executing inside your three most critical apps?
The room answered:
That means the overwhelming majority of the room could not confidently answer the question.
Not because they are bad at identity.
Not because they lack tools.
Because the industry has spent years building systems that define and review access, while the real action is happening deeper inside the application.
The honest answer from the room was the best data point of the session.
It showed the gap.
Observability is the bridge
So what closes the gap?
Not another policy.
Not another quarterly review.
Not another dashboard pretending to be a strategy.
A different discipline.
Identity observability.
Visibility tells you the door exists.
Observability tells you who opened it, what they did on the other side, and whether they should have been there at all.
IAM defines intent.
Observability validates execution.
Governance enforces outcome.
That middle layer is where most identity programs are thin.
And that is the layer that matters most as identities become more automated, more distributed, and less human.
What identity observability actually looks like
Identity observability is not just “more visibility.”
It means being able to answer four specific questions:
Who acted?
Not who has access. Who actually took action. Human, non-human identity, or agent. Attributed and traceable.
What did they do?
Not a login event. The actual action at the application layer.
Should they have done it?
Live policy compared against live behavior, continuously. Not once a quarter. Not after the fact.
What happens next?
Orchestrated response at the speed the risk is moving. Not a ticket that shows up three days later and quietly dies in someone’s queue.
For agents, the minimum chain of custody is even more direct:
Agent.
Tool.
Action.
Target.
Every agent needs an owner.
Every action needs a trace.
Without that, accountability is theater.
Controversial Take #3: Compliance passed. You are still exposed.
I know this one is uncomfortable.
I am not saying compliance is worthless.
I am saying compliance measures something different from what many people assume.
Identity observability tells you whether your security posture actually matches it.
Both matter.
But confusing one for the other is where organizations get exposed.
The framework: Observe, Understand, Govern
Closing the gap operationally comes down to three things.
In this order.
Always.
- Observe.
Discover every application and every identity executing inside it. Human, non-human, and agent. See what they are actually doing, not just what they are provisioned to do. - Understand.
Analyze behavior against intent continuously. Raw telemetry is noise. The question is not “does this access look reasonable on paper?” The question is “is this behavior aligned with what this identity is supposed to do right now?” - Govern.
Turn observation into control. Orchestrate response. Enforce least privilege at execution time. Attribute every action with a full chain of custody.
This is how we move from Identity Dark Matter to measurable, governed execution.
And critically, this is not a rip-and-replace motion.
It extends IAM, IGA, and PAM into the layer they were never designed to fully see.
The application execution layer.
Where I left the room
Visibility got us here.
It was the right first battle.
But seeing is not knowing.
And in the agentic era, where identities are increasingly non-human, moving faster than review cycles, and acting inside critical applications, seeing is no longer enough.
Visibility shows the door.
Observability shows what walked through it.
Execution context closes the gap.
That is the frontier.
For everyone who joined me at 7am, thank you.
You are officially my kind of people.
Questionable judgment. Excellent taste.
The full deck is below
If your team is wrestling with the gap between what your IAM says is true and what is actually executing, I would love to hear how you are thinking about it.
Tal Herman
