The disappearing backbone of IAM
For years, identity governance has had a reliable center of gravity: entitlements. Durable, reviewable permission assignments like group membership or app roles. They’re the things we can point to, certify, and explain to an auditor.
Most governance programs quietly assume entitlements exist and that they accurately represent who can do what. That assumption is starting to break as authorization moves out of applications and into policy engines and token services.
I still remember the moment when entitlement-based governance failed me, not in theory, but in practice.
We had just wrapped up a quarterly access certification. Everything looked tidy: the right groups, the right owners, the right approvals. I felt the quiet satisfaction that comes from believing the process works.
Then came the question from the auditor. The problem wasn’t a user. It was a service identity, a workload quietly exchanging tokens and minting claims that granted broad access across production APIs. No group membership, no app role, nothing that ever appeared in our certification. The policy that enabled those claims had been updated months earlier, buried in a code review. It passed every technical check but never crossed the threshold of an access review.
As I sat in that meeting, I realized how little our governance had touched the reality of access. I found myself asking: how many other decisions are happening outside the boundaries of our governance? How many times have we certified what’s easy to count, while missing what actually authorizes actions?
That moment changed how I think about identity governance. It’s not just about frameworks or controls. It’s about seeing the gaps and having the humility to admit when the old models no longer fit.
The shift: from static permissions to dynamic proof
Traditional IAM followed a predictable chain. Roles mapped to entitlements, entitlements mapped to application permissions, and governance reviewed those assignments on a schedule. It was clean, auditable, and — when apps enforced those permissions — mostly correct.
Modern systems increasingly externalize authorization. Instead of storing durable permissions inside each application, they defer decisions to policy and prove eligibility at runtime using short-lived tokens and context signals. In practice, that usually means some combination of:
- A policy engine evaluating action + resource + context
- Token/claims issuance based on identity, posture, and environment
- Attribute-driven rules that can change without touching the application
- Ephemeral privilege measured in minutes, not quarters
Example: a workload identity calls a protected API. A token service authenticates the workload and issues a short-lived token containing claims (workload identity, environment, request context). A policy engine evaluates the request and returns allow/deny. The API enforces the result. The application never stores a durable permission to certify. Authorization lives in the policy and the token issuance rules.
"Tokens don’t live long enough to certify. The policies and issuance rules do."
Non-human identities and agentic agents
The biggest disruptor isn’t a new protocol. It’s that the fastest-growing population in your tenant isn’t human.
Non-human identities aren’t service accounts anymore. Workloads call APIs, assume roles, exchange tokens, and hop across services. They appear and disappear with deployments. They operate at machine speed, and increasingly they make access decisions indirectly by satisfying (or failing) policy conditions. The access path you need to govern is no longer a stable set of app-local permissions.
Agentic AI agents push this further. They don’t just use access. They request it, chain it, and orchestrate it across tools and services. Even when a human sets the goal, the agent may choose the path, generate the justification, and execute the action. I’ve watched agentic agents assemble privilege in ways no human reviewer could predict.
That creates the mismatch. Governance that was built for humans — periodic reviews of durable entitlements — is being asked to govern actors whose access is assembled dynamically at runtime.
If you can’t point to the policy that allowed the action, or the system that issued the claims that made it possible, an entitlement review won’t save you.
Why traditional certification fails in this new world
Access certification works when access is stable and legible. It assumes there’s a user, a role, and a durable permission inside an application model that doesn’t change too often.
In the new world, permissions are ephemeral, policies are code, and access is determined at runtime, often by systems acting on behalf of software identities. Your quarterly review can be perfectly executed and still miss the things that mattered.
That’s the gap. We’re still governing what’s easy to count, not what actually authorizes actions.
Zero Standing Privilege: when access is issued, not assigned
Zero Trust taught us “never trust, always verify.” But many Zero Trust programs still rely on standing access sitting in groups and app roles.
Zero Standing Privilege (ZSP) is the operating model that fits the token-and-policy world. Don’t pre-assign broad privilege and hope it’s reviewed later. Issue narrowly scoped access just-in-time, based on policy and current context.
What you govern under ZSP:
- The policies that define eligibility (action, resource, constraints)
- The token and claims issuance rules (what can be minted, by whom, when)
- The signals those decisions depend on (posture, environment, risk)
- The enforcement points (APIs, gateways, services) that apply the decision
ZSP isn’t a buzzword. It’s how you keep privilege proportional when the number of software identities and automated non-human actors explodes.
Policy attestation: governing the rules, not the tokens
If tokens and claims are the runtime artifacts, they’re the wrong object to govern directly — they’re gone in minutes. The durable objects are the policies and issuance rules that decide which identities can receive which claims under which conditions. That’s what needs review, ownership, and evidence.
In practice, policy attestation asks:
- What actions can this identity (human or NHI) ever be authorized to perform?
- What claims can be issued, and what must be true for issuance?
- Who owns the policy and the issuance rules, and how are changes approved?
- What telemetry proves the policy is being enforced as intended?
For identity teams, this starts to look less like a quarterly campaign and more like a product lifecycle. Versioned policies, change control, peer review, testing, continuous evidence. Governance becomes something you can ship safely.
We’ve seen this before: the SSO transition pattern
The last time IAM’s center of gravity shifted, it was SSO. Apps stopped owning passwords and sessions, and centralized identity providers took over. That broke a lot of existing controls, not because security teams stopped caring, but because the control plane moved.
We’re in a similar transition now. Applications are losing control over authorization as policy engines and token services take over. If governance keeps focusing on what’s easiest to list (entitlements) instead of what actually decides access (policies, claims, issuance, enforcement), it will fall behind the architecture. The organizations that navigated the SSO shift quickly will recognize the pattern — and hopefully move sooner this time.
The new governance stack
Put together, this implies a different governance stack. Not a replacement for entitlement governance everywhere — many systems still have entitlements — but an expansion into the layers where authorization is increasingly decided:
- Policy lifecycle management (ownership, versioning, approval)
- Token and claims issuance governance (what can be minted, under what conditions)
- NHI inventory and classification (what exists, what it does, where it runs)
- Continuous evidence (telemetry that proves enforcement and detects drift)
- Agent guardrails (allowed actions, blast radius, monitoring)
"If you can't name the policy owner and the approval path for changes, you don't have governance. You have hope."
What identity leaders should consider doing in the next 12 months
Don’t try to boil the ocean. Start small but start now. Pick one or two critical APIs or platforms and build the muscle where the architecture is already heading.
- Get visibility first. Build (or confirm) an inventory of NHIs, agentic agents, and token services for your critical path. What they are, where they run, and what they call.
- Trace authorization end-to-end. For one API, document where policy is evaluated, where tokens are minted, what claims matter, and what signals influence the decision.
- Stand up policy ownership. Treat the highest-risk policies and issuance rules as governed assets. Named owners, versioning, approval paths, testing before rollout.
- Start attesting the rules. Run a lightweight policy attestation review on that pilot. What can be authorized, under what conditions, and what evidence you expect to see.
- Instrument for drift. Make sure you can detect when policy, claims, or enforcement behavior changes in production. That’s the equivalent of an entitlement silently expanding.
The future of governance is dynamic
Entitlements aren’t disappearing everywhere. But they’re no longer the stable backbone governance teams grew up with.
As authorization shifts into policy engines and token services, “who has access” becomes a runtime question shaped by context, claims, and autonomous non-human actors.
The identity leaders who win in the next decade will govern the durable control points. Policy. Claim issuance. Enforcement evidence.
Conclusion
Pick one critical application or API and trace how authorization really happens end-to-end. Where policy is evaluated, where claims are minted, what runtime signals influence the decision. If you can’t name the policy owner and the approval path for changes, you don’t have governance. You have hope.
Then ask yourself: what would it take in your organization to move from entitlement reviews to policy attestation?