Notifications
Clear all
Topic starter
14/07/2026 4:20 pm
TL;DR: Authorization is moving into the SSO token-issuance moment, so claims can reflect live policy rather than stale configuration, while also supporting OIDC, OAuth, SAML, and MCP tool access flows according to PlainID. Static tokens assume authorization remains stable between login and use, but runtime policy evaluation breaks that assumption and shifts audit evidence to issuance time.
NHIMG editorial — what this means for IAM teams
Questions worth separating out
Q: How should security teams use real-time authorization at sign-in?
A: Use real-time authorization when token claims need to reflect current policy, context, or data sensitivity at the moment of issuance.
Q: Why do static token claims create risk in modern IAM programmes?
A: Static token claims create risk because they can outlive the access state they were meant to represent.
Q: What breaks when authorization ignores the calling application?
A: When authorization ignores the calling application, the API cannot tell whether a request came from the right actor, in the right workflow, with the right purpose.
Practitioner guidance
- Define which access decisions must be runtime decisions Classify tokens, claims, and entitlements by risk level, then require live policy checks for data-sensitive or privilege-bearing actions.
- Test token issuance failure and latency paths Validate what happens when the policy engine is slow, unavailable, or returns an indeterminate result before putting inline authorization into production.
- Separate authentication evidence from authorization evidence Make sure audit logs can show who authenticated, what policy was evaluated, and why the final decision was issued.
What's in the full announcement
PlainID's full article covers the operational detail this post intentionally leaves for the source:
- Inline Hook flow specifics for Duo token issuance and SAML assertion enrichment
- Alpha-stage scope for Token Inline Hooks, SAML Assertion Inline Hooks, and External Authorization Hooks
- How the policy engine evaluates live session context before the token is signed
- Why external authorization hooks matter for MCP tool access and delegated agent flows
👉 Read PlainID's analysis of real-time authorization at Duo sign-in →
Real-time authorization at sign-in: what changes for IAM teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
14/07/2026 4:28 pm
Static token claims are a governance approximation, not an authorization control. They assume the access state at sign-in will remain valid for the life of the token, even when role, context, and data sensitivity change immediately after issuance. That assumption breaks as soon as runtime policy matters more than initial authentication. Practitioners should treat token claims as an audit artifact, not a substitute for living authorization.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
A question worth separating out:
Q: How do teams govern delegated agent access differently from human access?
A: Delegated agent access needs the same policy source of truth as human access, but with tighter attention to session context and per-action decisions. A human may authenticate once, while an agent can invoke multiple tools and alter its path within the same session. Teams should require explicit authorization boundaries for each sensitive action the agent can initiate.
👉 Read our full editorial: Real-time authorization at SSO sign-in changes token trust
