Context-aware authorization is replacing static IAM for APIs and AI

At a glance

What this is: This is an analysis of why static, user-centric IAM no longer fits API-driven and AI-enabled environments, and why context-aware authorization becomes the better model.

Why it matters: IAM and NHI teams need to decide what identity context APIs should trust when applications, service accounts, and AI agents act on behalf of users or independently.

👉 Read Curity's analysis of context-aware authorization for APIs and AI

Context

Modern IAM often assumes a human user is the direct actor, but API architectures do not work that way. Requests are made by applications, services, and increasingly AI agents, which means authorization has to account for the application identity, the user context, and the circumstances of the request. That is the core NHI governance problem here: deciding what the system should trust when the real actor is not human.

Curity argues for a more application-centric model in which access tokens carry context as claims and backend APIs use that context to make authorization decisions. For practitioners, the shift matters because static role assignment does not capture whether a request is expected, delegated, or task-scoped. That starting position is typical for teams modernising IAM around APIs, but it becomes more urgent as AI use cases expand.

Key questions

Q: How should security teams authorize API requests made by applications on behalf of users?

A: Security teams should authorize API requests using both user context and application context. The API needs to know who initiated the action, which application is calling, and whether the request is expected in that runtime situation. If policy only checks the user, delegated access and automated workflows can overreach their intended scope.

Q: Why do AI agents complicate traditional IAM and authorization models?

A: AI agents complicate traditional IAM because they can act autonomously, use tools, and make requests without a human directly present at each step. That breaks the simple user-session assumption behind many IAM designs. Security teams need context-aware authorization so the system can judge whether the agent is expected to act, and under what conditions.

Q: What breaks when authorization ignores the calling application?

A: When authorization ignores the calling application, the API cannot tell whether a request came from the right actor, in the right workflow, with the right purpose. That leads to over-permissioned integrations, unsafe delegated access, and policy decisions that look correct on paper but fail at runtime. Application identity must be part of the trust decision.

Q: How can security teams make just-in-time access work for automated workflows?

A: Security teams should make just-in-time access work by issuing short-lived permissions tied to a specific task, request context, and expiration window. The access token or policy should encode what the workflow is allowed to do, and backend systems should reject anything outside that boundary. That keeps automation useful without creating standing privilege.

Technical breakdown

Why user-centric IAM fails in API architectures

User-centric IAM assumes the person logging in is the same entity making the request, but that assumption breaks in distributed systems. In practice, the application sends the API call, not the human, and the application may be acting for the user or acting independently. If authorization only checks user permissions, the API cannot tell whether the request path, calling application, or operating context is expected. That creates a blind spot for delegated access, service-to-service calls, and automated workflows. The result is not just weaker policy enforcement, but a mismatch between identity data and actual runtime behaviour.

Practical implication: Map authorization decisions to the calling application and request context, not only to the end user.

What context-aware authorization adds to access tokens

Context-aware authorization uses claims to carry information that backend systems can evaluate at runtime. Claims may include user identity, application identity, environment, or other attributes that help an API decide whether a request is valid in the current situation. This matters because authorization is no longer a binary allow-or-deny question tied to a static role. Instead, the API evaluates whether the caller is expected, whether the action is appropriate, and whether the request fits the current policy. For NHI governance, that means tokens become part of the control plane for machine and delegated identities, not just session artefacts.

Practical implication: Design token content around the decisions your APIs actually need to make.

Why just-in-time least privilege needs dynamic rules

Just-in-time access works only when the privilege granted is narrowly scoped to the task and expires when the task ends. In API and AI workflows, that requires dynamic authorization rules because the context can change between requests. Static permissions are too blunt for this model, especially when a single application may act differently across workflows or users. A dynamic authorization layer can support least privilege by varying access based on request purpose, client identity, and current conditions. That is especially relevant for AI agents, which may need temporary access to perform bounded actions without inheriting standing privilege.

Practical implication: Use short-lived, context-bound authorization instead of persistent broad entitlements for automated workflows.

Threat narrative

Attacker objective: The attacker objective is to turn legitimate-looking delegated access into unauthorized API actions or data exposure.

1. Entry occurs when applications or automated agents inherit broad user permissions and make API requests that appear legitimate at the identity layer but are not evaluated in context.
2. Escalation happens when authorization logic cannot distinguish the calling application, delegated purpose, or runtime conditions, allowing the actor to overreach its intended scope.
3. Impact is unauthorized data release or unintended action execution through APIs that trust the wrong identity signal.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Static user-centric IAM is no longer a reliable control model for API-first systems. The decisive weakness is not password strength or login assurance, but the assumption that the human user is the direct requester. Modern applications, services, and AI agents mediate most actions, so identity controls that ignore request context will keep missing the real trust boundary. Practitioners should treat application identity as a first-class governance object.

Context becomes the new trust currency for machine and delegated access. If an API cannot evaluate who is calling, why the request is expected, and under what conditions it is allowed, then policy is too coarse for modern workloads. Claims-based authorization is useful only when the claims reflect real operational context, not just token decoration. Teams should align claim design with decision points, not with authentication convenience.

Token Intelligence is a useful named concept for the field: access tokens must carry decision-grade context. That concept sharpens an important shift in NHI governance. Tokens are no longer just proof of authentication, they are carriers of the data APIs need to authorise behaviour safely. Security architects should model tokens as part of runtime authorization architecture, not as passive bearer artefacts.

AI use cases expose the gap between standing privilege and task-scoped authority. Autonomous or semi-autonomous actions often need short-lived access that matches a specific task, then disappears. Static RBAC cannot express that well, and broad delegated access only increases the blast radius when an application misbehaves. Practitioners should move toward dynamic, context-aware policies that bound what automated actors can do.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot confidently answer where machine access is actually flowing.
• For a deeper control baseline, see OWASP Non-Human Identity Top 10, which maps the most common NHI failure modes to governance priorities.

What this signals

Token Intelligence: the next governance question is whether access tokens carry enough context for APIs to make safe decisions. That moves the programme from static entitlement review to runtime authorisation design, which is a much harder control problem for machine identities and AI agents.

The structural issue is visibility. With 5.7% of organisations having full visibility into their service accounts, policy design often happens without a complete identity inventory, which means trust assumptions outpace control maturity. Practitioners should treat application-context mapping as a prerequisite for any serious API governance programme.

For teams aligning this work to broader control frameworks, NIST Cybersecurity Framework 2.0 remains useful for structuring govern, identify, protect, and detect responsibilities around machine actors. The practical shift is to define who can act, under what context, and how exceptions are observed before access becomes operationally invisible.

For practitioners

• Inventory application identities separately from human users Build a control inventory that distinguishes end users, applications, service accounts, and automated agents. Track where each identity can call APIs, what context it carries, and whether the API can tell the difference at decision time.
• Define claims that reflect decision-grade context Add only the claims your APIs actually need, such as calling application, expected purpose, tenant, environment, or task scope. Avoid oversized tokens that expose unnecessary data or make authorization brittle.
• Replace broad delegated permissions with task-scoped rules Use short-lived entitlements for workflows that can be bounded in time and purpose. Where AI or automation is involved, tie access to a specific action window and revoke it when the task ends.
• Test API policies against abnormal request paths Simulate requests that come from the right user but the wrong application, the right application but the wrong context, and expired task windows. The goal is to prove the API can reject requests that are technically authenticated but operationally unsafe.

Key takeaways

• Static, user-centric IAM does not model how applications and AI agents actually interact with APIs.
• Context-aware authorization makes tokens and claims part of the runtime control plane for delegated and automated access.
• Teams that want least privilege for modern workloads need request-level context, not just stronger login controls.

Key terms

• Application-Centric IAM: An identity model that treats the application, not only the human user, as the primary actor for authorization decisions. It recognises that most modern requests are mediated by software and that access policy must account for the calling application, request path, and operational context.
• Context-Aware Authorization: An authorization approach that uses request context, claims, and runtime conditions to decide whether access should be granted. It goes beyond static roles by evaluating who is calling, what they are trying to do, and whether that behaviour is expected in the current environment.
• Token Intelligence: A design pattern in which access tokens carry decision-grade context rather than acting only as bearer credentials. The token becomes a transport for claims that backend systems use to authorise behaviour safely, especially for delegated workflows and automated actors.
• Task-Scoped Access: A short-lived access model that grants only the permissions needed to complete a specific action or workflow. It reduces standing privilege by tying authority to purpose, duration, and context, which is especially important for AI agents and automation.

Deepen your knowledge

Context-aware authorization and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are adapting IAM for APIs, services, and AI agents, it is worth exploring.

This post draws on content published by Curity: Identity and Access Management for AI and APIs. Read the original.