Non-human identity security principles for controlling AI agent risk

At a glance

What this is: This guide explains the technical principles for securing non-human identities and AI agents, with emphasis on inventory, least privilege, externalized authorization, monitoring, and runtime boundaries.

Why it matters: It matters because IAM teams now have to govern machine access and agent behaviour with controls designed for dynamic identity use, not just human login flows.

By the numbers:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.

👉 Read Cerbos's guide to securing non-human identities and AI agents

Context

Non-human identity security starts with the basic governance problem that most organisations do not know every service account, token, certificate, or AI agent they have, or how those identities are actually used. That gap becomes dangerous when credentials are reused, over-scoped, or left unmanaged after a service changes or is retired.

This guide is about turning NHI and AI agent security into a day-to-day operating model rather than a set of isolated best practices. The article links inventory, rotation, least privilege, policy enforcement, data protection, prompt hygiene, and monitoring into one control system because attackers exploit the seams between those layers.

Key questions

Q: How should security teams implement least privilege for non-human identities?

A: Start with no access, then grant only the permissions required for the specific task, environment, and duration. Use policy-based controls so permissions can change at runtime without code changes. The goal is to avoid standing privilege, reduce blast radius, and keep entitlement review tied to actual machine behaviour, not assumptions made at provisioning time.

Q: Why do service accounts and API keys create so much risk when they are over-scoped?

A: Because a single compromised machine credential can expose many systems if the identity is shared, long-lived, or broadly trusted. Over-scoped access turns one leak into lateral movement, data exposure, or abuse of downstream services. The practical fix is narrow scoping, ownership, rotation, and retirement tied to lifecycle events rather than ad hoc cleanup.

Q: What breaks when authorization is embedded inside application code for AI agents?

A: Application-embedded authorization becomes inconsistent across services, hard to update, and vulnerable to agent behaviour that bypasses intended guardrails. Central policy enforcement keeps access decisions aligned with current context and prevents the agent from altering its own rules. For AI systems, decoupling policy from code is what keeps access governable as behaviour changes.

Q: Who is accountable when an AI agent exposes sensitive data through a prompt injection path?

A: Accountability sits with the team that allowed the agent to access sensitive data without sufficient containment, not with the prompt alone. The key issues are identity scope, retrieval boundaries, and logging. Organisations should map responsibility across IAM, platform, security engineering, and the product owner so incident response and control ownership are clear.

Technical breakdown

NHI inventory and credential lifecycle management

A complete NHI inventory is not a spreadsheet of accounts. It is a living map of identities, the credentials issued to them, where those credentials are used, and when they are rotated or retired. That matters because orphaned identities, duplicated keys, and unmanaged certificates create invisible access paths that standard access reviews often miss. The article’s lifecycle model is joiner, mover, leaver: provision with owner and purpose, rotate and reconcile on change, then revoke and archive on retirement. In practice, this is the foundation for reducing shadow identities and limiting the time a compromised credential can remain useful.

Practical implication: tie every NHI to an owner, purpose, TTL, rotation rule, and offboarding step so identity drift becomes visible.

Least privilege, ABAC, and policy-based authorization for NHIs

Least privilege for NHIs means giving each identity only the permissions it needs, only when it needs them, and only within a narrowly defined context. The article pushes beyond static RBAC toward policy-based authorization and ABAC because machine activity is often runtime-specific and environment-specific. That distinction matters for services, API calls, and AI agents that should not inherit broad standing access. Externalizing authorization into a policy decision point keeps permission logic out of application code and makes access decisions consistent across services. For AI systems, it also prevents the actor from changing its own access rules.

Practical implication: move high-risk access decisions into a central policy layer and use context-aware rules instead of embedding permissions in code.

Prompt validation, data-layer filtering, and output leakage control

AI agent security fails when prompts, retrieval paths, and outputs are treated as trusted by default. The article shows why validation has to happen at multiple layers: filter malicious or out-of-scope input, enforce authorisation before data is retrieved, and sanitise output before it leaves the system. This is especially important for RAG systems and vector stores because a model can only leak what it can access. Pushing policy into the data layer, including metadata filters and row-level security, reduces the chance that a prompt injection can turn broad backend access into data exfiltration.

Practical implication: enforce retrieval checks and output controls at the data layer, not just in the agent interface.

Threat narrative

Attacker objective: The attacker’s objective is to make the agent act with broader access than intended and use that access to expose sensitive data or credentials.

1. Entry occurs when an attacker or malicious prompt reaches an AI-enabled workflow that can query internal data or invoke privileged operations.
2. Credential or access abuse follows when the system relies on over-scoped service roles, broad tokens, or weak tenant isolation rather than scoped identity controls.
3. Impact occurs when the agent retrieves, posts, or exposes data outside its intended boundary, creating credential leakage or cross-tenant disclosure.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

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

NHI Mgmt Group analysis

Identity inventory is the control plane for NHI security, not an administrative afterthought. If organisations cannot enumerate every service account, token, certificate, and agent, they cannot govern rotation, ownership, or retirement with confidence. That is why shadow identities and orphaned credentials remain a structural weakness rather than a hygiene issue. The practitioner conclusion is simple: the inventory is the control surface.

Least privilege for NHIs only works when entitlement is dynamic, contextual, and centrally enforced. Static permission sets are too coarse for machine workflows that change with environment, deployment stage, or delegation chain. Externalised authorization and ABAC are therefore not optional architecture patterns, but the only practical way to keep machine access narrow without embedding policy drift into code. The practitioner conclusion is to govern access from policy, not from application behaviour.

Data-layer authorisation is where NHI security becomes real. Prompt filters alone do not stop leakage if the retrieval layer can still expose sensitive records. The article’s strongest operational message is that vector stores, embedding stores, and database filters need identity-aware controls before data is returned. The practitioner conclusion is to push enforcement as close to the data as possible.

Runtime boundaries must be defined around what an AI agent can do, not just what a user asked for. Agent behaviour changes the risk model because the system can chain retrieval, action, and disclosure in a single flow. That makes human oversight, kill switches, and immutable logs part of the security architecture rather than optional governance extras. The practitioner conclusion is to treat agent action limits as enforceable security policy.

Ephemeral credential trust debt is the hidden problem underneath modern NHI controls. Short-lived credentials reduce exposure, but only if issuance, scope, rotation, and retirement stay synchronised with how the identity is actually used. The moment those controls drift apart, organisations accumulate trust debt that attackers can convert into lateral movement or disclosure. The practitioner conclusion is to manage the full lifecycle, not just the token lifetime.

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% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• For a broader lifecycle view, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Ephemeral credentials only reduce risk if remediation keeps pace with issuance. The gap is not just secret creation, it is how long compromised access remains useful once exposure is detected. NHIs turn that into an operational race, and the winning side is the team that can rotate, revoke, and re-issue without breaking production workflows.

With 97% of NHIs carrying excessive privileges in our research, the governance pressure is moving from access grant to access containment. That means IAM teams should expect policy enforcement, data-layer filtering, and lifecycle automation to become baseline requirements rather than specialised controls.

The operational signal for 2026 is that agentic systems will force organisations to collapse the distance between identity governance and runtime enforcement. Teams that still treat authorisation, logging, and lifecycle management as separate programmes will keep finding the same failure modes in different places.

For practitioners

• Build a complete NHI inventory Map every service account, API key, token, certificate, and AI agent to an owner, purpose, environment, TTL, and rotation policy. Tie the record to how credentials are issued and retired so orphaned access paths can be removed quickly.
• Move NHI authorisation into a central policy layer Remove permission logic from application code and enforce access through a distributed policy decision point that checks identity, action, and context on each request. Use ABAC or policy-based rules where runtime conditions matter more than static roles.
• Use short-lived credentials by default Issue ephemeral credentials through secure vaults or workload identity patterns so leaked keys have less value. Rotate on mover events, revoke on leaver events, and make the rotation step part of deployment and ownership change workflows.
• Enforce data-layer filtering before retrieval Apply authorisation checks before the model or agent can fetch records, including metadata filters, row-level security, tenant scoping, and read-only credentials for agent access. Block service_role or equivalent broad keys from agent workflows.
• Instrument agents with human-readable audit trails Log authentication, data access, permission changes, and anomalous behaviour in a way security teams can review quickly. Add kill switches for misbehaving agents and test them regularly so containment is possible before a task completes.

Key takeaways

• The article shows that NHI security is a lifecycle problem, not a one-time configuration task.
• The evidence points to a recurring pattern of over-scoped credentials, weak rotation, and incomplete visibility.
• The practical response is to combine inventory, policy enforcement, data-layer controls, and runtime monitoring into one operating model.

Key terms

• Non-Human Identity: A non-human identity is any digital identity used by software, services, workloads, devices, bots, or AI agents rather than a person. In practice, it includes service accounts, API keys, tokens, certificates, and workload identities that need ownership, scope, lifecycle control, and monitoring.
• Policy-Based Authorization: Policy-based authorization is the practice of deciding access through central rules that evaluate identity, action, and context at runtime. It removes permission logic from application code and helps organisations keep machine and agent access consistent, auditable, and easier to change safely.
• Ephemeral Credential: An ephemeral credential is a short-lived secret or token issued for a narrow task and then allowed to expire or be revoked quickly. It reduces exposure if leaked, but it still requires scope control, rotation discipline, and lifecycle handling to remain effective.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or programme maturity, it is worth exploring.

This post draws on content published by Cerbos: principles for securing non-human identities and AI agents. Read the original.