Access control for AI agents and NHIs is becoming a governance problem

At a glance

What this is: This is a Curity analysis of access control as an identity governance problem spanning human users, NHIs, and AI agents, with context-aware authorization emerging as the critical control plane.

Why it matters: It matters because IAM and PAM teams increasingly need one access model that can handle machine identities, delegated runtime decisions, and human access without relying on separate, brittle patterns for each.

Context

Access control is the decision layer that answers whether a requesting party can perform an action or reach a resource. In practice, that decision now spans human users, service accounts, APIs, applications, and AI agents, which makes it an identity governance problem rather than a simple authentication pattern.

The article's central issue is that traditional IAM assumptions break down when non-human identities are part of the access path and runtime context becomes part of the decision. That shifts the question from who signed in to what the identity is allowed to do, under which conditions, and with which downstream privileges.

Curity frames authentication and authorization as foundational, but the broader implication is that modern access control must handle heterogeneous identities without overexposing data or turning policy evaluation into an afterthought.

Key questions

Q: How should teams design an authorization model for applications that mix human users, APIs, and AI agents?

A: Start by mapping what is protected, who can act, and which conditions change access. A practical model usually blends RBAC for stable duties, ABAC for context, and ReBAC for relationships or ownership. For AI agents and services, add explicit machine identity controls, scoped actions, and approval gates for sensitive operations. The goal is to match real workflows without hardcoding every rule into application logic.

Q: Why do NHIs make access control harder to govern than human users?

A: NHIs are numerous, highly dynamic, and often tied to automation, which means access changes faster than manual review cycles. They also reuse tokens, keys, and certificates across systems, making ownership and offboarding harder. The result is more privilege drift and more blind spots unless access is designed around lifecycle events.

Q: What are the signs that role-based access control is becoming too hard to manage?

A: Common signs include role sprawl, frequent role edits, overallocated permissions, and growing visibility gaps across the identity environment. If teams keep creating new roles just to satisfy narrow access needs, RBAC is starting to strain. It also becomes harder to maintain when personnel move often, because each change can trigger broad access review and cleanup work.

Q: What should security teams do when a token is valid but the request still feels unsafe?

A: Reject the idea that token validity alone is sufficient. Recheck scopes, claims, issuer, expiration, and the current context at the enforcement point, then decide whether the request still fits the intended policy boundary. A valid token should not override a failed authorisation decision.

Technical breakdown

Authentication and authorization as separate control layers

Authentication answers who or what is making the request, while authorization answers what that identity may do. The article correctly separates those layers because access control failures often come from treating them as one problem. In modern environments, a token can prove identity but still carry scopes, claims, or session context that are too broad for the action being attempted. That distinction matters for APIs, applications, and machine identities alike, because verification alone does not establish safe authority. Practical implication: design authentication and authorization as distinct control points and review each independently.

Practical implication: Design authentication and authorization as distinct control points and review each independently.

RBAC, ABAC, and policy-based access control in runtime decisions

RBAC assigns access by job function, ABAC uses attributes about the user, resource, or environment, and policy-based access control evaluates contextual rules such as location, time, or device state. The article's point is that these models can be layered, but they solve different parts of the decision problem. RBAC is stable but coarse. ABAC and PBAC are more dynamic because they can react to runtime context, which is increasingly necessary when machine identities, APIs, and AI agents operate outside fixed human workflows. Practical implication: use the simplest model that can express the decision safely, then add policy context only where the risk warrants it.

Practical implication: Use the simplest model that can express the decision safely, then add policy context only where the risk warrants it.

OAuth 2.0, OpenID Connect, and JWTs as access control plumbing

The article describes a common token-based architecture in which OAuth 2.0 provides delegated access, OpenID Connect adds the identity layer, and JWTs carry scopes and claims to downstream systems. That stack is powerful, but it pushes trust decisions into token validation and policy enforcement at runtime. If signature, issuer, expiration, scope, or claim checks are weak, the system can accept privileges that no longer reflect the current risk or context. For NHIs and AI agents, that means the token is not just an authentication artefact but the operational carrier of access authority. Practical implication: validate token integrity and entitlement boundaries at every enforcement point, not only at issuance.

Practical implication: Validate token integrity and entitlement boundaries at every enforcement point, not only at issuance.

Breaches seen in the wild

• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Access control is becoming an identity governance problem, not just an authentication problem. The article shows that modern systems now have to arbitrate access for users, APIs, applications, and AI agents within one decision model. That broadening matters because the risk is no longer limited to login abuse. It is the mismatch between static entitlement models and runtime decision-making across heterogeneous identities. Practitioners should treat access control as governance over requesting parties, not as a point solution for sign-in.

Context-aware authorization is the real shift, because runtime conditions increasingly determine whether access is safe. RBAC still has value, but it cannot express enough of the decision surface when device state, location, and request context influence access. ABAC and policy engines therefore become more important, not because they are fashionable, but because they encode the operational reality of cloud, API, and machine-driven access. The implication is that teams must reassess where coarse roles are still sufficient and where policy evaluation is now mandatory.

Non-human access exposes a governance gap that older IAM models were not built to absorb. Service accounts, bots, and AI agents do not fit neatly into human-centric assumptions about login frequency, review cycles, and privilege persistence. Runtime authorization boundary: the decisive control point is moving from identity proof to request-time authorisation, because access for non-human actors is increasingly expressed through tokens, scopes, and policies rather than durable human sessions. Practitioners should treat this as a structural change in how access is governed.

Least privilege now depends on the ability to constrain downstream action paths, not only assign fewer roles. The article's emphasis on layered controls suggests that entitlement size alone is an incomplete measure of safety. What matters is whether the system can prevent a verified identity from using a valid token in an unsafe context, especially across APIs and service-to-service flows. The implication is that identity teams need tighter alignment between policy design, token scope design, and enforcement architecture.

Human IAM, NHI governance, and agentic access are converging on the same control plane. The article is strongest when read as a signal that access models can no longer be partitioned by actor type alone. The governance challenge is now cross-domain: the same organisation may need to manage human sign-in friction, machine credential authority, and AI agent request scope in one framework. Practitioners should evaluate whether their current IAM architecture can govern all three without creating blind spots.

From our research library:

• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to the State of Secrets in AppSec.
• Read next: Authorisation Models Guide

What this signals

Runtime authorization boundary: organisations should assume that the control point is shifting from who authenticated to what the identity can do in the current context. That is especially important for service accounts and AI agents, where the same token may be valid while the request itself is no longer safe. According to the State of Secrets in AppSec, 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, which reinforces why request-time governance matters.

Identity teams should expect more pressure to unify human IAM, NHI governance, and agent access policy in one operating model. When access decisions depend on attributes, context, and downstream scope, governance can no longer be split cleanly between sign-in, API security, and machine identity reviews.

The practical next step is to treat token validation, policy evaluation, and lifecycle ownership as one control chain. If any link is missing, access control becomes a collection of exceptions rather than a governed decision process.

For practitioners

• Map every requesting party to an identity type Classify users, service accounts, APIs, applications, and AI agents separately so access policy design reflects how each actor actually requests and uses authority.
• Separate authentication from authorization reviews Check that proof of identity, token issuance, and permission enforcement are independently tested, because a valid token does not guarantee safe access.
• Move high-risk decisions into policy evaluation Use attribute and context signals such as device state, location, and request path for access decisions where RBAC alone cannot express the risk.
• Validate token claims at every enforcement point Verify signature, issuer, expiration, scopes, and claims downstream, especially where OAuth 2.0 and OpenID Connect tokens cross service boundaries.
• Review non-human access through lifecycle governance Treat service accounts and AI agent permissions as governed identities with ownership, scope, and revocation expectations, not as technical leftovers.

Key takeaways

• Access control is shifting from a login problem to a governance problem that has to cover humans, NHIs, APIs, applications, and AI agents together.
• Static role assignment is no longer sufficient where request context, token scope, and downstream action path determine whether access is safe.
• Teams that align authentication, authorization, and lifecycle ownership can govern heterogeneous identities without multiplying exceptions across systems.

Key terms

• Access Controls: Access controls are the rules that limit who can see or use data and systems. They may use roles, attributes, authentication strength, and policy checks to reduce exposure. In DLP programmes, access controls help ensure sensitive content is only available to approved users and processes.
• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Attribute-Based Access Control: Attribute-Based Access Control is a policy model that grants or denies access using attributes such as user role, device state, location, and application context. It replaces purely static role assignment with a decision process that can adapt to current conditions, provided the underlying attributes are trustworthy and well-governed.
• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.