Notifications
Clear all
Topic starter
07/06/2026 8:56 pm
TL;DR: As applications add AI agents, authorization becomes harder to reason about because policy checks must stay tightly scoped, auditable, and predictable across multi-tenant and multi-step workflows, according to WorkOS. The real issue is not policy syntax but the identity foundation underneath it: if identity data is weak, downstream authorization cannot be trusted.
NHIMG editorial — based on content published by WorkOS: Oso for AI Agent Security: Features, Pricing, and Alternatives
By the numbers:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.
- 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage.
Questions worth separating out
Q: How should security teams govern AI agent access to application data?
A: Security teams should treat AI agent access as delegated authority with explicit task scope, tenant scope, and data scope.
Q: Why do centralized authorization engines still depend on strong identity foundations?
A: Because authorization only works when the system knows exactly who or what is asking for access, which tenant they belong to, and which claims are current.
Q: What breaks when tenant context is not propagated correctly in multi-tenant systems?
A: Access decisions become ambiguous, and policy engines may allow or deny actions based on incomplete context.
Practitioner guidance
- Separate identity trust from policy logic Map which team owns authentication, which owns authorization rules, and which owns the identity attributes feeding those rules.
- Add pre-retrieval checks for AI agent workflows Authorize document and data access before content enters the model context window.
- Validate tenant context at every service hop Test whether tenant identifiers, user claims, and resource ownership survive API calls, worker queues, and delegated execution paths without drift or truncation.
What's in the full article
WorkOS's full article covers the architectural detail this post intentionally leaves for the source:
- Polar policy examples for role, relationship, and attribute-based access models.
- Language-by-language SDK usage for evaluating permissions in application code.
- How WorkOS positions authentication, MFA, directory sync, and SCIM as the upstream identity layer.
- Practical examples of how centralized authorization is evaluated inside multi-tenant application flows.
👉 Read WorkOS's analysis of Oso for AI agent security and authorization →
AI agent authorization and identity foundations: what teams must align?
Explore further
08/06/2026 8:40 am
Authorization is not the primary control problem here. Identity trust is. The article correctly separates authentication from policy evaluation, and that is the right boundary for modern IAM architecture. A policy engine can only answer questions about access if the upstream identity claims, tenant context, and lifecycle state are already reliable. Practitioners should read this as a reminder that authorization debt often starts as identity debt.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to Ultimate Guide to NHIs.
- Our research also shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, underscoring how often delegated access becomes the entry point.
A question worth separating out:
Q: How do AI agents change the way IAM teams think about authorization?
A: AI agents turn authorization into a runtime delegation problem. Instead of checking a single user request, teams must govern multi-step behaviour, pre-retrieval data access, and decisions made on behalf of a human. That means access scope must be bounded more tightly, and identity governance must account for the actor that executes the work, not just the person who started it.
👉 Read our full editorial: AI agent authorization depends on stronger identity foundations
