Most enterprises have invested heavily in identity — who you are. Almost none have solved authorization — what you're allowed to do. The gap between them is where breaches live.
Most enterprises have spent the last decade investing in identity infrastructure. They know who their users are. They can authenticate them with MFA, SSO, and FIDO2. The modern identity stack is genuinely good.
What they haven’t solved — and what almost no vendor has seriously addressed — is authorization. Not authentication. Authorization. The enforcement of what an authenticated identity is actually allowed to do, to which resource, under what conditions.
Why the gap exists
Authorization is hard in ways that identity is not. Identity is fundamentally a binary: you are who you say you are, or you’re not. Authorization is a policy problem — contextual, temporal, scope-dependent, and subject to business rules that change faster than infrastructure.
The classic answer to this problem is RBAC — role-based access control. Assign roles to users, assign permissions to roles, enforce at the application level. It works, at small scale, with stable organizations, and when the number of distinct access patterns stays manageable.
None of those conditions hold in modern enterprises.
The AI identity problem
The introduction of AI agents into enterprise workflows has made this worse by an order of magnitude. A human user has a job title, a manager, a department, and a set of responsibilities that change slowly. An AI agent has none of these. It has a task, a set of tools, and access credentials provisioned by whoever deployed it.
“The question isn’t whether AI agents will have access to sensitive data. They already do. The question is whether anyone is enforcing what they’re allowed to do with it.”
When an AI agent is provisioned access to a data warehouse to answer business intelligence questions, that same agent — by default — can also write to that warehouse, delete records, or exfiltrate data to an external endpoint. The access controls that were sufficient for human users, who understand context and consequence, are not sufficient for non-human identities that execute instructions literally.
What a real solution looks like
The companies solving this correctly are not building better identity systems. They are building authorization layers — infrastructure that sits between an identity (human or non-human) and a resource, and enforces policy continuously, not just at login time.
The right architecture:
- Decoupled from the application — authorization logic should not live in application code
- Continuous, not session-based — access decisions should be re-evaluated at every request
- Policy-as-data — authorization rules should be auditable, versionable, and reviewable
- Non-human identity aware — the data model must support AI agents, service accounts, and automation as first-class principals
This is a hard infrastructure problem. It requires buy-in from engineering teams, careful integration with existing IAM stacks, and a policy language expressive enough to capture real business rules without becoming unmaintainable.
The investment thesis
We believe the authorization layer is one of the most important unsolved problems in enterprise security. Not because the technology is impossible — it isn’t — but because the organizational and integration challenges have historically made it easier to accept the status quo than to fix it.
AI is changing the cost-benefit calculation. The consequence of getting authorization wrong is no longer “a user can see data they shouldn’t.” It’s “an AI agent can take actions at machine speed, at machine scale, with no human in the loop.” That raises the stakes enough that enterprises will invest.
The founders who win this category will be those who understand the full stack — identity, policy, enforcement, and audit — and who can sell to security teams and platform engineering teams simultaneously. That’s a narrow profile. When we find it, we invest.