Why doesn’t an identity provider control what users can do inside applications?

An identity provider doesn’t control what users can do inside applications because it stops at authentication and token issuance. It says who the user is and carries their roles and groups, but whether that user can approve a payment or open a record is decided afterwards, usually in each application’s code. That second decision is authorization, and it needs its own policy downstream of the identity provider.

How does an identity team get visibility into access rules inside applications?

An identity team gets visibility into access rules inside applications by moving those rules out of application code and into a central authorization policy that every application calls. The identity team can then read and review the rules in one place, and every decision is recorded in an audit log showing which policy applied.

What happens to application permissions when an employee changes roles?

When an employee changes roles, application permissions often stay as they were, because the checks live in each application’s code and only change when someone updates them. Central authorization policy handles a role change by evaluating the user’s current attributes on every request instead of relying on permissions set when access was first granted. When the directory updates a role or department, the next decision uses the new value, and the fine-grained permissions follow without each application being updated by hand.

How can an identity team check where application access rules live?

An identity team can check where application access rules live by taking one person who changed teams recently and one application from their old role, then asking the owning team what that person can still do and where the answer comes from. If finding the answer takes a code search, the rule sits outside identity governance and is a candidate for central authorization policy.

Cerbos Included in The Forrester Tech Tide™: Identity And Access Management, Q1 2026

Cerbos is included in The Forrester Tech Tide™: Identity And Access Management, Q1 2026. The report is available to Forrester subscribers or for purchase from Forrester.

If you run identity for your organization, this post covers why we think the access rules inside your applications belong under your governance, and a quick way to check where your own rules stand.

Your identity provider knows who the user is, the application decides what they can do

Your identity provider authenticates the user, issues the token and carries their roles and groups. What it does not decide is whether this user can approve this payment, open this patient record or export this report at this moment. That decision depends on the resource and the context of the request as much as on who is asking, and in most organizations it is made inside each application.

That second decision is authorization, and it sits downstream of your identity provider. The identity provider says who the caller is, and an authorization policy says what that caller can do, evaluated against the user’s attributes, the resource’s attributes and the context of the request, such as the time, the tenant or the state of a record.

Access rules in application code sit outside identity governance

The rules about what a user can do once they are inside an application are usually written into that application’s code, by the team that owns it. Your joiner mover leaver process updates roles in the directory, but the checks that read those roles, and the exceptions layered on top, live in dozens of codebases the identity team never sees. When someone moves teams, the role changes in one place and the fine-grained permissions change wherever someone remembered to update them.

Moving those rules into externalized authorization puts them back within your governance reach. Applications ask a central decision point instead of deciding for themselves, and the policy becomes something the identity and security teams can read, review and change. Who should hold that policy is its own question, covered in who owns authorization in a large organization. Centralized governance also changes how fast you can respond when access needs to be narrowed, because one policy change applies everywhere the rule is used.

One authorization policy gives identity teams a single place to govern access and a record of every decision

With the Cerbos authorization management platform, policies are managed centrally in Cerbos Hub and distributed to every decision point, so a change reaches every application without touching application code. Every decision writes an audit log entry with the inputs, the policies evaluated and the result. That is the record an auditor asks for when they want to see who could do what, and under which rule, on a given day. At Utility Warehouse, authorization for an estate of around 4,500 internal services is managed and deployed through one decoupled policy decision point, instead of logic scattered across each service.

Identity data can also be fetched at decision time instead of being packed into every token. Cerbos Synapse pulls attributes from identity providers such as Microsoft Entra ID and Okta when a request comes in, so a policy works from the user’s current profile rather than whatever was true when the token was issued. Applications and gateways can ask for decisions through AuthZEN, the OpenID Foundation standard for authorization, so the way they ask for a decision does not depend on one vendor’s API.

The same model covers identities that are not people. Service accounts, workloads and AI agents call tools and APIs on someone’s behalf, and each call needs a decision based on what the agent is doing and who it is acting for. A role assigned once at setup does not answer that.

Check one recent mover against one application to see where your rules live

Pick someone who changed teams in the last quarter and one application they used in their old role. Ask the owning team what that person can still do in it today, and where that answer comes from. If the answer takes a code search, the rule is outside your governance reach, and you have a concrete example to bring to the application owners when you talk about moving it into central policy.

Try Cerbos to control access decisions for your applications in one place, or book a call to talk through how authorization fits with your identity stack.