Notifications
Clear all
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.
NHIMG editorial — based on content published by WorkOS: The Feature You'll Rebuild Three Times, Authorization at Scale
Questions worth separating out
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 AI agents need separate authorization boundaries from the users they represent?
A: AI agents can execute actions faster than humans can review them, so inheriting a user’s full permission graph creates unnecessary blast radius.
Q: What breaks when policy-based access controls are layered on top of static roles?
A: What breaks first is consistency.
Practitioner guidance
- Inventory authorization by boundary, not by feature Map where your application shifts from flat role checks to organization, group, workspace, and resource-scoped access.
- Separate human and agent access paths Give agents their own scoped entitlements and block any path that lets them mint tokens, change credentials, or elevate roles.
- Test policy drift across nested resources Build tests that simulate role inheritance, explicit overrides, and policy conditions across child and parent resources.
What's in the full article
WorkOS's full recap covers the implementation detail this post intentionally leaves for the source:
- The step-by-step evolution from basic role checks to resource-scoped RBAC and ReBAC across enterprise customers.
- The specific 2x2 identity provider automation matrix and why implementations diverge across SSO and directory sync patterns.
- The practical implications of AI agent access, including scoped privileges and the prohibition on self-escalation.
- The local RAG authorization pattern for filtering inaccessible documents before LLM processing.
👉 Read WorkOS's ERC 2025 recap on authorization at scale →
Authorization graphs at enterprise scale: are your controls keeping up?
Explore further
08/06/2026 8:45 am
Authorization is no longer a feature layer, it is a governance surface. Once access rules are embedded across organizations, nested resources, policy engines, and delegated agents, authorization shapes the product itself. That means identity governance cannot stop at login or directory sync. Practitioners need to treat application authorization as part of the broader identity control plane, not a separate developer convenience.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How do teams know if their authorization model is too brittle for enterprise customers?
A: A brittle model shows up when every new org structure, subsidiary, or resource type requires a rewrite or a long exception list. If product teams keep adding one-off logic to satisfy enterprise deals, the authorization layer is no longer scaling with the business. The signal is repeated rework, not just more permissions.
👉 Read our full editorial: Authorization at scale: why enterprise apps rebuild it repeatedly
