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

At a glance

What this is: This is an overview of access control methods and the claim that modern IAM must extend beyond human users to govern non-human identities, APIs, and AI agents.

Why it matters: It matters because NHIs now sit inside the access-control plane, where weak authentication, broad authorization, and poor policy enforcement create outsized governance risk.

By the numbers:

• NHIs outnumber human identities by 25x to 50x in modern enterprises.
• Only 5.7% of organisations have full visibility into their service accounts.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Curity's overview of access control methods for users, APIs, and AI agents

Context

Access control is the set of decisions that determines what a requesting party can do after it presents a credential or assertion. In NHI governance, the problem is no longer just who a person is, but whether a service account, API client, workload, or AI agent should be trusted to act on a resource at a given moment.

Curity's article frames the classic building blocks clearly, but the bigger issue for practitioners is scale and runtime context. The same authentication and authorization patterns that work for human sessions often fail when credentials are embedded in code, reused across services, or exercised by autonomous software that does not fit a fixed user role model.

Key questions

Q: How should organisations govern access for AI agents and other non-human identities?

A: Treat AI agents and other non-human identities as first-class principals with their own ownership, scopes, and expiry rules. Do not map them loosely to human roles. Use task-scoped policy, short-lived credentials, continuous validation, and explicit revocation so that access remains tied to a current business purpose rather than a persistent entitlement.

Q: What is the difference between RBAC and policy-based access control for NHIs?

A: RBAC grants access through predefined roles, which is simple but often too coarse for machine workflows. Policy-based access control evaluates context such as time, resource type, workload, or device state, which is better for NHIs that need temporary and conditional access. For autonomous systems, policy-based control usually matches real operational needs more closely.

Q: Why do non-human identities create more access-control risk than human users?

A: NHIs often operate at higher volume, with broader machine-to-machine reach and weaker lifecycle oversight than human accounts. Their credentials are frequently embedded in code, reused across services, or left valid too long. That combination increases the chance of over-privilege, stale access, and silent misuse that standard user-centric IAM reviews miss.

Q: Should security teams use short-lived tokens for workload and agent access?

A: Yes, when the use case allows it. Short-lived tokens reduce exposure if credentials are stolen and make access easier to revoke, but only if scopes are narrow and validation is strict. Tokens alone do not solve governance. Teams still need ownership, monitoring, and explicit offboarding for the identity behind the token.

Technical breakdown

Authentication and authorization for non-human identities

Authentication verifies that a requesting party is entitled to present a credential. Authorization decides what that party can do after identity is established. In NHI environments, the entity may be a service account, API key, token, certificate, or AI agent, so the control point shifts from login events to machine-to-machine trust. That creates pressure to bind credentials to workload identity, token issuer, expiration, audience, and context instead of assuming a stable human session. OAuth 2.0 and OpenID Connect help with federated flows, but they do not solve privilege design by themselves.

Practical implication: Tie every machine credential to a clear identity, short lifetime, and policy boundary.

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

RBAC assigns permission through roles, which is simple but often too coarse for dynamic service and agent behaviour. ABAC evaluates attributes such as device state, environment, or resource sensitivity, giving more precision. PBAC adds policy engines that can combine conditions in code-like rules, which is why it is often better suited to ephemeral or context-driven access. For NHI governance, the difference matters because a workload or agent may need a narrow action scope for one task, then a different scope minutes later. Static entitlements create unnecessary standing privilege.

Practical implication: Use policy evaluation for runtime decisions where fixed roles cannot express task-scoped access.

Token validation, scopes, and runtime trust boundaries

Token-based architectures depend on accurate validation of signature, issuer, audience, scope, and expiration. If those checks are weak, a stolen or over-broad token can move laterally across services without a visible login event. JWTs are useful because downstream systems can validate claims locally, but that also means each service becomes part of the trust boundary. For NHI programs, the main architectural risk is not just token theft. It is token overreach, stale privileges, and the assumption that a validated token is automatically an appropriately authorized one.

Practical implication: Audit token scopes and validation logic as part of access-control design, not as a separate security task.

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

Access control is becoming an NHI governance discipline, not just an IAM feature. The article treats authentication and authorization as foundational building blocks, but that framing becomes incomplete once machine identities dominate more requests than humans. NHI programs now have to decide whether a service account, token, or AI agent should be treated as a durable identity, a task-scoped identity, or a delegated control surface. The practical conclusion is that access control policy must be designed for autonomous actors, not retrofitted from human user management.

Policy-based control is the named concept this category needs more than role-based control. Static RBAC cannot express time, location, device posture, or workload context with enough precision for most NHI use cases. PBAC and ABAC can, but only if organisations define clean attributes, keep policy logic auditable, and resist policy sprawl. That matters because the more autonomous the actor, the more the policy engine becomes the real control plane. Practitioners should treat policy design as an operational dependency, not an implementation detail.

Runtime trust breaks down when validation is confused with authorisation. Many environments validate a token and then assume the request is safe, even when the token carries broader scopes than the task requires. This creates a latent access problem that is invisible in traditional login reviews. Once an NHI credential is embedded in automation or an agent workflow, the control question shifts to whether every downstream action is still aligned to the original business purpose. Practitioners should review scopes, claims, and audience restrictions together.

Access control for agents will push enterprises toward shorter-lived, more contextual privileges. The article's future-facing point about non-human actors is the real signal. AI agents and automation layers do not fit neat user-centric authentication models, so the market is moving toward ephemeral access, policy evaluation, and tighter runtime checks. That does not eliminate IAM complexity, it relocates it into entitlement design, token governance, and continuous verification. The practitioner takeaway is that standing access will look increasingly indefensible for machine identities.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For lifecycle controls, the Ultimate Guide to NHIs shows why rotation, revocation, and visibility must be treated as one operating model.

What this signals

The governance signal is straightforward: access control is no longer just an enforcement layer, it is the operating model for machine identity. Identity blast radius: when one credential can drive multiple APIs, services, or agent actions, the real control objective becomes containing how far a single compromise can travel. Practitioners should map that blast radius before expanding automation.

With only 5.7% of organisations having full visibility into their service accounts, the access-control problem is already structural rather than theoretical. That makes NHI discovery, entitlement review, and revocation workflow design prerequisites for any serious zero-trust programme, not supporting tasks.

The next phase of control design will blend policy evaluation with tighter runtime checks and external standards such as NIST SP 800-207 Zero Trust Architecture and OWASP Non-Human Identity Top 10. Teams should expect more pressure to prove that machine access is contextual, short-lived, and continuously verified.

For practitioners

• Define machine identities separately from human users Inventory service accounts, API keys, tokens, certificates, bots, and AI agents as distinct identity classes with their own ownership and review cadence.
• Replace broad roles with task-scoped policy rules Use attributes such as workload, environment, time window, and resource sensitivity to drive access decisions for automation and agents.
• Shorten token lifetimes and narrow scopes Limit JWT and OAuth scopes to the smallest viable action set, then enforce expiration and audience checks consistently across services.
• Review authorization at the service boundary Validate that each downstream API and microservice re-checks claims, issuer, and audience before accepting a machine request.
• Build an offboarding path for non-human identities Require a revocation workflow for API keys, service credentials, and agent tokens when workloads are retired or reconfigured.

Key takeaways

• Access control for NHIs is a governance problem because machine identities now act at scale, outside the assumptions of human-centric IAM.
• Static roles and long-lived credentials create the most dangerous gaps when services, APIs, and agents need context-aware access.
• Security teams should move toward short-lived, policy-driven, and fully revocable machine access if they want meaningful control.

Key terms

• Non-Human Identity: A non-human identity is any credentialed actor that is not a person, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities often outnumber human users and can carry powerful permissions, which makes lifecycle control and ownership essential.
• Policy-Based Access Control: Policy-based access control decides access using conditional rules rather than fixed roles alone. It evaluates context such as time, location, device, workload, or data sensitivity, which makes it better suited to dynamic machine-to-machine access than static role assignment.
• Token Validation: Token validation is the process of checking that a credential was issued by the right authority, has not expired, and is meant for the current request. For NHIs, validation must include issuer, audience, signature, scope, and context, otherwise a valid token can still be over-privileged.
• Identity Blast Radius: Identity blast radius is the amount of damage one compromised identity can cause across systems, services, and data. It is a practical way to think about NHI risk because a single token or service account may unlock many downstream actions if scopes and boundaries are too broad.

Deepen your knowledge

Access control for AI agents and non-human identities is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a governance model from a human-centric IAM starting point, it is worth exploring.

This post draws on content published by Curity: Access control methods and future directions. Read the original.