Topic starter
07/06/2026 9:00 pm
TL;DR: Authorization is the feature B2B SaaS teams rebuild repeatedly as customers move from simple permission checks to nested resources, custom roles, policy engines, and agent access, according to WorkOS's ERC 2025 recap. The governance problem is no longer just access design but keeping authorization aligned with enterprise hierarchy, identity provider automation, and AI-driven requests without breaking least privilege.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “The Feature You'll Rebuild Three Times: Authorization at Scale: Pavan Kulkarni at ERC”.
Key questions
Q: How should security teams govern authorization when applications add nested resources?
A: Security teams should model authorization around resource boundaries, inheritance rules, and override paths instead of assuming flat RBAC will hold.
Q: Why do custom roles often create more access risk over time?
A: Custom roles solve immediate business fit, but they also create inheritance chains that must stay aligned as features evolve.
Q: How do access reviews change when AI agents use enterprise-managed authorization?
A: Access reviews must cover the agent, the policy that issued the token, and the downstream systems the token can reach.
Practitioner guidance
- Define authorization as a product architecture concern Map every user-visible action to the underlying resource, role, and relationship model before adding enterprise customers or nested objects.
- Model nested resources explicitly Document organisation, workspace, project, and object-level scopes as separate authorization boundaries, with inheritance rules and override behavior written down.
- Separate delegated agent access from human access Scope any agent or automation token to the minimum task-specific permissions and prevent the agent from minting tokens, changing credentials, or expanding roles during execution.
Bottom line: Authorization complexity grows because enterprise applications must represent hierarchy, inheritance, and context, not just simple permissions.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 4 days ago by NHI Mgmt Group
08/06/2026 8:45 am
Authorization drift is the hidden scaling tax in enterprise software: once access rules move from a single permission check to hierarchy-aware graphs, every new product feature changes the governance model. That makes authorization one of the few product controls that must evolve with the customer's organisation, not after it. The practical conclusion is that identity teams should treat authorization architecture as a lifecycle problem, not a one-time implementation.
A question worth separating out:
Q: What should teams do when identity-provider automation and app authorization do not line up?
A: Check where the application assumes a fixed role structure while the identity provider is using groups, attributes, or sync rules to drive access. Misalignment creates manual work, lockout risk, and inconsistent entitlements across customers. The practical response is to make the application accept the enterprise's identity model rather than forcing every customer into one path.
👉 Read our full editorial: Authorization at scale: why enterprise apps rebuild it repeatedly
This post was modified 4 days ago by NHI Mgmt Group