AI Agents are Non-Human Identities. Treat Them Like One.
TL;DR:
- Non-Human Identities (NHI) (service accounts, AI agents, machine credentials) now outnumber human users by a wide margin, and KPMG’s 2026 report makes governing them a top CISO priority
- Agents are the new insider threat: an overprivileged agent can exfiltrate data at machine speed without ever compromising a human credential
- Agents need secrets and credentials to do anything useful. At the same time, credentials accessible at runtime are a breach waiting to happen
- Treating an agent like the NHI it is means binding its identity, injecting (but never embedding) its credentials, ensuring it can access the minimum things it needs to access with minimum permissions in order to execute its task, and auditing every action (including the ones that are failed and denied)
- Lens Agents solves these issues by ensuring that your agents can access only the domains you allow them to access, credentials injection happens at the relay so secrets never live in the agent runtime, every agent has its own identity, every action is audited, there are different spending limits per agent/team/organization, and more.
What to see Lens Agents in Action?
Check out our latest 20-minute webinar in which you’ll see the problems with agentic workflows, what Lens Agents is, and how it can help, and a demo of the platform:
What Non-Human Identity Actually Means?
A Non-Human Identity, or NHI, is an identity that isn’t a person. There are many NHIs, and they have existed for a long time:
- API keys and tokens: credentials that grant programmatic access to an application or system
- OAuth tokens: Access grants that let one service act on behalf of another
- Machine certificates: Cryptographic identities for workloads and devices
- Service accounts: Identities applications use to communicate with other applications
Most of these NHI were predictable in the past. For example, a deployment pipeline that touches a registry or a logging service that retrieves logs from a logging endpoint. AI agents, however, are the newest members of this category, and they are the ones that are actually breaking the existing model.
An AI agent is different from a traditional NHI because it reasons, chains actions together, decides at runtime which tools to call, and most of the time, right now, it carries elevated privileges because no one is implementing least privilege properly. This autonomy, plus its broad access, is exactly what makes an AI agent valuable, but at the same time, it is exactly what makes it very dangerous.
Why Non-Human Identity is the New Security Perimeter?
Right now, it’s clear that you are no longer primarily defending human logins. You are in the non-human identity perimeter, and the agents inside it operate with administrative-level reach.
Enterprises spend decades hardening the human identity perimeter, but that investment addresses only half of the platform. This is also shown in this whitepaper.
The number behind this trend is real, even if the exact ratio depends on who you ask. CyberArk’s 80-to-1 NHI-to-HI ratio is the most-cited number. The Cloud Security Alliance reports an average of 45-to-1, which rises in cloud-native environments to 144-to-1, while other vendors put it at over 100-to-1. Even though the ratio varies by source, one thing is clear: NHIs are outscaling human identities by one to two orders of magnitude, and the gap widens whenever a platform team automates another workflow.
Why AI Agents Break Traditional Identity Governance?
The governance tools the industry built in the last few years were built for humans. You onboard a person, review their access quarterly, and offboard them when they leave. Every one of these steps assumes a relatively small number of people (of course, in big enterprises, there might be hundreds or thousands a month), who change slowly and act at human speed.
Agentic AI is shifting all of these assumptions:
- You can spin up thousands of agentic identities in the time it takes to onboard a single employee
- An AI agent is able to act in milliseconds, so a quarterly review is meaningless for catching a bad decision
- Agents can accumulate broad access because least privilege can be annoying to implement, and easy to skip
- It’s almost impossible to see what an agent did and why, and this means that you’re not actually in control of the data it can touch.
An overprivileged agent can be compromised through supply chain issues, prompt injection, or a poisoned tool, to name just a few. An attacker uses their existing, legitimate access to exfiltrate data at machine speed. They don’t even need to phish any human credentials, since the breach can occur directly on an NHI that no one is watching.
Why AI Agent Credentials Should Never Live in the Agent?
An agent is useless without credentials because to do real work, it needs to authenticate with your cloud provider, Kubernetes clusters, databases, or internal APIs.
So, where do most enterprises store these secrets? Well, the lazy answer is to put them in the agent runtime (environment variables, a config file, a token pasted in the orchestration layer). The moment you actually do that, the agent becomes a walking secret store that can be easily exploited.
Every one of these locations is a place where a secret can actually leak:
- A compromised dependency reads the config file
- The model itself ends up reflecting credentials back in an output
- Prompt injection convinces the agent to print its own environment
- A debugging log captures the token in plaintext
The entire industry is currently shifting away from putting static secrets in the agent’s runtime. Injecting credentials at call time, at the layer the agent can’t see, is the only way to ensure your credentials aren’t leaked.
How to Secure AI Agents as Non-Human Identities?
An agent is an NHI, and it should be treated as such. You should apply the same disciplines you’d apply to any high-profile machine identity that’s adapted for autonomy:
- Inject, don’t embed: Credentials should always be supplied to the agent’s requests at a controlled layer, and never stored in the agent’s runtime or memory
- Scope by least privileged: Even though this process might seem complicated in the beginning, it’s well worth the trouble. Define what the agent is allowed to reach (which domains, which methods) and deny everything else by default
- Bind the identity: Your agents’ identities should map clearly to a real federated identity via your existing SSO, so every action can be traced back to a known principal. Your agents shouldn’t be anonymous.
- Audit everything: You should have a full trail of what the agents did, tried to do, and where they’ve done it
- Cap the blast radius: Implementing spending limits and rate control means that a compromised agent can’t run up unbounded cost or damage
- Define autonomy explicitly: Not all your agents should be allowed to act on their own. Match the level of human oversight with the level of risk
How Lens Agents Secures Non-Human Identities
It’s easy to say “treat agents like NHI”, but building the layer that actually enforces it is the hard part. This is where Lens Agents comes in.
Lens Agents is a governed platform for running AI agents against real enterprise systems, and its design maps directly to all the problems and solutions we’ve described above:
- Credential injection happens at the relay: Secrets are injected into the agent’s requests at the relay, not in the agent runtime. In this way, the agent never holds the credentials, so there is nothing available to be compromised by prompt injection or by a leaked log
- Kernel-level sandbox enforcement: Managed agents in the platform run inside a sandbox (light VMs that run a user-provided image with its own policy data)
- Full audit trails: Every request is logged, including ones that are blocked. You don’t just see what happened; you also see what the agents attempted and where the guardrails held.
- Identity bounding: Every single agent is bound to a real identity. There are no anonymous agents and no orphaned tokens. Every action an agent takes is attributable to a known principal.
- Policy Engine: Domain-level and HTTP method/path controls that define what each agent can reach. The policy engine also defines what kind of credentials they will get from the relay, and what integrations they can use
- Spending limits: There are spending limits available per organization, per token, per user, and per sandbox. A misbehaving agent can’t generate unbounded cost.
- Integrations: Built-in Integrations with Kubernetes and AWS, others to come
- Framework-agnostic governance: The controls reside at the platform layer, regardless of the agent framework you use. You can govern agents consistently without mattering how they were built
Key Points
AI Agents are non-human identities with autonomy and reach, and the governance built for human identities doesn’t work at their scale or their speed.
The fix is to treat the agents like the NHIs they are with bound identity, injected credentials, scoped permissions, and a full audit trail. Lens Agents gives you exactly that: identity bounding, credential injection happening at the relay, policy engine, spending limits, full audit trail, sandbox environments, and more.
If you want to see how Lens Agents helps you govern your agentic workflow on a real enterprise system, book a demo with one of our engineers.
FAQ
What is a non-human identity (NHI)?
A non-human identity is any identity that isn’t a person. It can be a service account, an API key, an OAuth token, or even an AI agent. These NHI authenticate to systems and act on their own, and in most enterprises, they outnumber human users by a wide margin.
Why are AI agents a security risk?
If an agent is compromised through prompt injection, bad dependencies, poisoned tools or others, an attacker can use its legitimate access to exfiltrate data at machine speed. An overprivileged agent is a new kind of insider threat.
How do you secure AI agent credentials?
Keep credentials out of the agent. Don’t store them at runtime, inject them through a controlled layer the agent never sees, and scope every identity to least privilege. Lens Agents does that with credential injection at the relay, so secrets never live in the agent runtime.