Policy-driven token issuance is reshaping authorization governance

At a glance

What this is: This is an analysis of policy-driven token issuance and token-facilitated authorization, with the key finding that authorization governance fails when static token contents are treated as an IdP-only concern.

Why it matters: It matters because IAM teams must govern not just authentication but the policy decisions baked into tokens for humans, workloads, and AI agents, or they leave stale privilege and weak auditability in place.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.

👉 Read Cerbos's analysis of policy-driven token issuance and authorization governance

Context

Policy-driven token issuance is a governance answer to a simple problem: a token often contains the actual authorization decision, but most organisations still treat that decision as a side effect of authentication. In practice, the IdP asserts identity, while claims, scopes, groups, and roles determine access until the token expires.

That gap matters for identity programmes because the same pattern now applies across human users, service accounts, and AI agents. The question is no longer whether the token is signed correctly, but whether the contents reflect current policy, current context, and current entitlement state at the moment of issuance.

Key questions

Q: How should security teams govern claims and scopes inside access tokens?

A: Security teams should treat claims and scopes as governed authorization outputs, not as simple IdP mappings. Put one policy owner in charge of how token contents are derived, feed current entitlement and risk context into issuance, and log the decision so audits can explain why access was granted.

Q: Why do static tokens create authorization risk for both users and NHIs?

A: Static tokens create risk because they remain trusted after the context that justified them has changed. For users, that means stale roles or exceptions can persist. For NHIs, the problem is worse because service accounts and workloads can exercise over-broad claims continuously until the token expires.

Q: How can organisations tell whether token-based authorization is actually working?

A: Look for a clear decision log, a named owner for authorization policy, and evidence that token contents change when entitlement or risk state changes. If teams still need custom reports to explain why a claim was issued, governance is still fragmented.

Q: What should IAM teams do when token issuance must support humans, service accounts, and AI agents?

A: Use one authorization policy model across all three actor types, but vary the inputs by actor and context. That keeps lifecycle events, delegation chains, and runtime conditions in the same governance path while avoiding separate rule sets that drift over time.

Technical breakdown

Static tokens and snapshot governance

A static access token is a signed assertion that remains trusted for its full lifetime, even if the underlying context changes after issuance. The token can carry claims, scopes, groups, and roles that look authoritative, but those values are only as current as the policy and mappings at the time they were stamped. This creates snapshot governance: the system is making a decision once, then reusing it everywhere downstream. That model works only when risk, tenancy, device posture, and entitlement state are stable enough to ignore. In modern identity estates, they are not.

Practical implication: Treat token contents as governed decisions, not passive directory output.

Token-facilitated authorization versus externalized authorization

Token-facilitated authorization pushes the policy decision into issuance, so the token itself carries the current answer. Externalized authorization keeps the decision at runtime, where the application or proxy asks a policy engine whether a specific action is allowed on a specific resource. The two models solve different problems. The first reduces changes to downstream systems, while the second preserves fine-grained control when a token cannot express enough context. Both depend on the same separation of duties: authentication stays in the IdP, authorization stays in policy.

Practical implication: Match the decision model to the granularity of control the application actually needs.

Subject-as-vector in modern authorization protocols

The article points to a structural shift in wire formats: the request subject is increasingly a vector, not a single principal. Actor chains, entity profiles, and client-instance assertions let the policy distinguish who is acting, on whose behalf, and from which runtime. That matters because a user, service, workload, and AI agent can all appear in one delegation chain, yet each contributes different risk and authority. Once the subject becomes a vector, authorization logic must evaluate relationships, not just identities. That is a protocol change with governance consequences.

Practical implication: Design policy to evaluate delegated actors and runtime context, not only the end user.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authorization governance breaks when the token becomes the control plane. The article shows that many teams have solved authentication while leaving authorization scattered across IdP mappings, IGA workflows, and application code. That fragmentation means no single owner can explain why a claim was issued, why it stayed valid, or who approved it. The implication is straightforward: identity programmes still lack a governed decision point for what gets trusted downstream.

Static token issuance creates an identity blast radius that outlives the triggering context. A token is treated as authoritative for an hour or more even when tenant scope, device posture, exception status, or risk changes mid-session. That is not a token bug, it is a governance boundary problem. Practitioners should read this as evidence that runtime context must influence issuance if authorization is to remain defensible.

Token contents now govern non-human identities as much as humans. The article is strongest when it applies the same policy model to service accounts, workloads, and AI agents. That matters because over-broad claims on non-human identities are exercised continuously, not intermittently, so stale scope becomes a persistent control failure. The conclusion for IAM leaders is that NHI and human authorization can no longer be managed as separate governance stories.

Subject-as-vector is the named concept this shift exposes. The request subject is no longer a single principal whose rights can be inferred from one token line. It is a chain of issuers, actors, and runtime instances that policy must evaluate together. That assumption breaks older IAM models that equate signature verification with authorization certainty, and practitioners need to rethink how delegation is represented before they can govern it well.

Policy ownership is the missing governance primitive in token-based authorization. The article makes clear that teams often know where authentication lives, but not where the authorization decision is owned, logged, or reviewed. Without that ownership, lifecycle events, risk exceptions, and entitlement changes never become a durable authorization record. The field needs a decision authority, not more scattered mapping logic.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• The same lifecycle problem appears in governance: Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why issuance, rotation, and offboarding must be tied to policy, not memory.

What this signals

Policy-driven token issuance is becoming the control point that decides whether identity governance keeps pace with runtime reality. The practical shift is away from static role mapping and toward centrally owned policy that can see entitlement, risk, and actor context at issuance time. For teams already struggling with service-account visibility, the gap is unlikely to close through directory hygiene alone.

Claim drift is the hidden cost of treating authorization as configuration. Once claims are baked into tokens without a governing decision trail, the organisation loses the ability to prove why access existed, not just that authentication succeeded. That is where human IAM, NHI governance, and agentic delegation now converge, and why policy design needs to sit above the IdP layer.

For practitioners

• Define a single authorization policy owner Assign one governance owner for claims, scopes, group membership, and role-to-token mapping so the decision can be reviewed, audited, and changed centrally. This removes the hidden ownership gap that leaves stale access in place.
• Move context checks into issuance policy Feed current entitlement state, tenant scope, device signals, and risk exceptions into the policy that builds the token so the issued claims reflect the moment of access.
• Separate authentication from authorization in architecture Keep identity proofing and session validation in the IdP, but place access decisions in policy so downstream systems trust governed output rather than static directory mappings.
• Extend the same decision model to NHIs and agents Apply the same issuance logic to service accounts, workloads, and AI agents so machine identities do not inherit broader or longer-lived claims than the request requires.

Key takeaways

• Authorization fails when tokens are treated as static snapshots instead of governed decisions.
• The scale problem is already visible in NHI programmes, where service-account visibility remains poor and over-privilege is common.
• IAM teams need a single policy owner and a central decision layer if token issuance is going to support humans, workloads, and agents.

Key terms

• Policy-driven token issuance: A method of building access tokens from a governed policy decision rather than a static identity mapping. The policy engine can use current entitlements, risk signals, and context so the signed token reflects the moment of access and not just the directory state at login.
• Token-facilitated authorization: An authorization pattern where the token itself carries the decision about what the caller may do. It is useful when downstream systems can trust coarse claims at runtime, but it still depends on accurate policy inputs and disciplined ownership at issuance time.
• Externalized authorization: An approach where the application asks a policy engine whether a specific action is allowed on a specific resource at the moment of request. It keeps fine-grained decisions out of application code and helps prevent policy drift across systems.
• Subject-as-vector: A model in which the identity making a request is treated as a chain of actors and runtime instances rather than one principal. It matters when users, service accounts, devices, and agents all contribute to the decision and must be evaluated together.

Deepen your knowledge

Policy-driven token issuance and authorization governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance model that has to cover humans, service accounts, and AI agents, it is worth exploring.

This post draws on content published by Cerbos: policy-driven token issuance and authorization governance. Read the original.