Token Intelligence: Why IAM Needs a New Mental Model
Judith Kahrer
· 3 min readKey Takeaways
Traditional IAM asks "is this user allowed?" — but users never make requests directly; applications always act on their behalf, so user-only permissions miss critical context.
An application-centric model decouples app permissions from user permissions, allowing different applications to act on behalf of the same user in different, purpose-specific ways.
This shift matters most for AI and automation use cases, where actions are delegated and context changes continuously — a scenario traditional user-centric IAM wasn't designed for.
APIs need context (claims) — not just user identity — to decide whether a request is safe to allow given current conditions.
Curity's Token Intelligence turns access tokens into carriers of context, giving APIs the real-world information needed to enforce dynamic, least-privilege authorization.
This approach supports just-in-time, least-privilege access for AI use cases specifically, representing a mental model shift from how most other IAM vendors approach authorization.
On this page
Identity and Access Management (IAM) is undergoing a significant transformation. Modern use cases demand more - more identities, more complexity, more speed, and far more dynamic behavior than traditional IAM was designed for. Meeting those demands requires a mindshift in IAM from static rules based on user permissions to dynamic rules with a holistic view that includes both human and non-human identities.
To meet these demands, IAM needs a new mental model—one that moves beyond static, user-centric permissions toward context-aware, dynamic authorization.
Why User-Centric IAM Falls Short in Modern API Architectures
Most IAM systems are built around a simple question: “Is this user allowed to perform this action?”.
This model works well in controlled environments where the main challenge is human user login.In modern architectures, authorizing solely on user permissions neglects an important detail, though: users never perform requests on their own.
Technically, it's always an application that makes requests on behalf of a user. In fact, some applications do not even operate in an end-user context. So when authorization decisions are based only on user permissions, an important part of the picture is missing. The system has no way of understanding how a request is made or whether it is expected in that context.
Users never perform requests on their own - they always depend on applications to perform requests, present data, and interact with data.
Application-Centric IAM: A Better Model for APIs and AI
A more accurate way to think about IAM is to start with the application.
Applications exist to fulfill a purpose. They interact with APIs—some act on behalf of users, others operate independently. Treating all requests as if they come directly from a user flattens this difference.
The application-centric approach decouples the permissions applications have from the permissions a user has. It lets you define rules where one application may act on behalf of a user in one way and another application in another way. Many companies realize just now that this mindset is extremely useful for emerging use cases such as AI and automation where actions are delegated and context changes continuously.
What APIs Need: Context for Authorization
Ultimately, applications access data from backend systems (APIs). The important questions to answer are:
whether the application is allowed (expected) to send certain requests (access certain data), and
whether the API should allow the request (release data) given the current circumstances.
To be able to enforce authorization rules, the backend systems (APIs) need information, some context - called claims. APIs may need a user identity to authorize a request. They may also need an application identity or other data. Ultimately, what information they need depends on the rules.
To securely grant access to the assets, APIs need data - data that gives them the power to evaluate whether, according to their rules, it is safe to allow a request in the current context.
The Curity Token Intelligence: Turning Context into Authorization Decisions
This is where Curity’s Token Intelligence comes in. Instead of being simple credentials, they become carriers of context providing APIs with the information needed to make access decisions based on real-world conditions. This enables a more dynamic and precise form of authorizations, supporting least privilege access and easily adapting to changing scenarios.
The Curity Identity Server enables you to define permissions for applications (based on their expected behavior) and to provide data (claims) that help the backend system to perform authorization. This approach makes it, for example, comparably easy to support AI use cases with the Curity Identity Server. AI use cases require just-in-time, least-privilege access, which you can convey via access tokens. As mentioned before, this approach also implies a mental model that is fundamentally different from the mental model of other vendors.
The Curity Identity Server utilizes a mental model that enables the enforcement of challenging authorization rules, including AI use cases, with the help of specialized access tokens.
Curity acknowledges that authentication and authorization are very specific to a context. Consequently, the Curity Identity Server is highly customizable both in terms of user authentication and the authorization details that it can provide to the backend system via access tokens. The latter is what we refer to as "Token Intelligence", a part of Access Intelligence.
Related resources
Frequently Asked Questions
What's the practical difference between user-centric and application-centric authorization in a real request flow?
User-centric authorization asks only "is this user allowed to do this?", while application-centric authorization also considers which specific application is making the request on the user's behalf — so the same user action could be treated differently depending on whether it came from a trusted internal app or a third-party integration.
Does application-centric IAM mean user identity becomes less important?
No — it adds a layer rather than replacing user identity. User identity still matters for many authorization decisions, but it's combined with application identity and context rather than being the sole factor considered.
How does this model handle applications that act completely independently, without any user involved?
In these cases, the application's own identity and permissions become the primary basis for authorization decisions, since there's no user context to factor in — this is common for batch jobs, automated workflows, or backend service-to-service calls.
What kinds of "claims" would an API typically need beyond basic user identity?
Depending on the use case, this could include the calling application's identity, the authentication method used, risk signals, time of request, or delegation context — essentially any data point the API's authorization rules are designed to evaluate.