AI Agents Are Identities Too: Securing Non-Person Entities in a Zero Trust Architecture

AI agents have moved from experimentation to real operational use. They are retrieving information, interacting with applications, calling APIs, generating and modifying files, and increasingly take actions on behalf of users and organizations. With a larger presence within an organization, security professionals have to be asking the important question:

When an AI agent attempts to access a system, how does that system know who, or what, it is?

Zero Trust has always been built around the principle that access should not be granted simply because an entity is inside a network or has previously been trusted. Identity must be established, access must be explicitly authorized, and trust must be continually evaluated.

For human users, organizations have spent years building the infrastructure to make that possible through identity providers, multifactor authentication, certificates, conditional access, privileged access management, and other identity controls.

AI agents bring renewed attention to the other side of the identity equation: Non-Person Entities, or NPEs.

And although AI agents may feel new, the fundamental Zero Trust problem they create is not.

What Is a Non-Person Entity?

The National Institute of Standards and Technology (NIST) defines a Non-Person Entity as an entity with a digital identity that acts in cyberspace but is not a human actor. NPEs can include hardware, software, services, organizations, and other digital entities.

Organizations already operate enormous numbers of NPEs.

Examples include:

• Servers and virtual machines
• Network switches, routers, and appliances
• Applications and microservices
• Containers and cloud workloads
• Service accounts
• Automated scripts and processes
• Robotic process automation
• APIs and application integrations
• IoT and operational technology devices
• Software agents

These entities routinely communicate with other systems and access organizational resources without a person manually authenticating every transaction. An application may query a database. A workload may request a secret. A server may connect to another server. A service account may execute an automated process.

Each interaction raises essentially the same questions we ask about a human user:

What entity is making the request? Can it prove that identity? Is it allowed to perform this action?

That is where NPE identity management enters the Zero Trust architecture.

Where AI Agents Fit

An AI agent is fundamentally a software entity capable of performing tasks and interacting with other systems. NIST describes AI agents as software systems that use data and algorithms to autonomously perform tasks, and its current work on agent identity focuses specifically on applying established identification, authentication, authorization, auditing, and identity standards to these systems.

That makes an AI agent a natural extension of the NPE concept. There is, however, an important distinction.

Traditional NPEs often perform relatively predictable functions. While a service account may run the same scheduled job every nigh, a web server may communicate with a known database or a workload may access a defined set of cloud services, an AI agent can be much more dynamic.

Depending on how it is designed, the same agent might search organizational data, interact with SaaS platforms, call multiple APIs, modify a ticket, send a message, or invoke another agent or tool.

That flexibility makes establishing and controlling the agent’s identity particularly important.

Authentication Comes Before Agent Autonomy

Before an organization can make a meaningful authorization decision about an AI agent, it needs confidence in the agent’s identity. One tempting approach is simply to give the agent a user’s credentials. For example, imagine an employee deploys an AI agent that needs to retrieve documents from an enterprise application. The easiest implementation might be to give the agent the employee’s credentials or a long-lived API key associated with that employee.

Technically, the agent can now access the application.

From an identity perspective, however, something important has been lost.

The target application may know that Bob’s account accessed a document. It may not know whether Bob accessed it personally, whether an approved enterprise agent accessed it for Bob, or whether a compromised process possessing Bob’s credential made the request.

The identity boundary between the human and the software has disappeared.

NIST has highlighted this exact problem in its recent agentic AI identity work. Sharing human credentials with agents creates accountability gaps. Instead, agents should be treated as first-class entities with their own identifiers, credentials, and entitlements, with appropriate relationships established between the agent and the user or system on whose behalf it is operating.

That seemingly small architectural difference is critical to Zero Trust.

Instead of:

User Credential → Agent → Resource

the model becomes:

Human Identity → Delegation → Agent Identity → Resource

The resource can now distinguish the human principal from the software actor performing the transaction.

How Does an AI Agent Authenticate?

There is no single authentication technology that will apply to every AI agent architecture. Agents can run in cloud environments, SaaS platforms, containers, endpoints, local systems, and specialized agent platforms.

But the Zero Trust objective remains consistent:

Give the agent a strong, unique, verifiable identity rather than relying on implicit trust or shared credentials.

A simplified authentication flow might look like this:

1. Establish an agent identity.
The organization creates or recognizes a distinct identity for the agent within its identity infrastructure. The identity should identify the agent itself rather than disguising the agent as a human user.

2. Provision a cryptographic credential or trusted workload identity.
Depending on the environment, this could involve an X.509 certificate, workload identity, cryptographic key pair, or another mechanism capable of proving possession of the agent’s identity.

3. The agent requests access to a service.
When the agent needs to interact with an application, API, database, or another agent, it presents evidence of its identity through the appropriate authentication protocol.

4. The receiving system validates the identity.
The identity provider, authorization server, gateway, or target system validates the credential and determines whether it is legitimate, current, and associated with the expected agent.

5. The agent receives appropriately scoped access.
Once authenticated, authorization policy determines what the agent can actually do. Ideally, access is constrained by factors such as the agent’s identity, requesting user, intended resource, task, environment, and current risk.

Modern implementations may combine technologies such as enterprise PKI, X.509 certificates and mutual TLS, OAuth and OpenID Connect, short-lived tokens, workload identity platforms, and other cryptographic identity mechanisms.

The exact protocol matters less than the architectural principle that an agent should be able to prove its own identity.

Why PKI Still Matters

This is where AI agents connect particularly well to existing Zero Trust activities.

In FRC’s Zero Trust coverage of Activity 2.1.2 – NPE/PKI, Device under Management the objective is to extend managed identity beyond human users and establish verifiable identities for devices and other NPEs through enterprise Public Key Infrastructure (PKI) and identity management.

PKI provides a mechanism for binding an identity to cryptographic credentials such as X.509 certificates. Rather than authenticating an NPE because it originates from a particular network or possesses a shared password, systems can require the entity to cryptographically prove possession of a trusted credential.

For traditional NPEs, that may be a server, device, workload, or application.

For emerging architectures, the same principle can extend to AI agents and the infrastructure hosting them.

An enterprise Certificate Authority can establish a trusted credential. Certificate lifecycle management can handle issuance, renewal, rotation, and revocation. Identity infrastructure can associate that credential with the corresponding NPE. Applications and policy enforcement points can then use that verified identity when evaluating access.

This builds on the enterprise identity and trust fabric established through activities such as Activity 1.9.1 – Enterprise PKI/IdP Part 1

The important takeaway is not that every AI agent must use an X.509 certificate directly. Agent architectures are evolving, and standards organizations are examining how technologies including OAuth and workload identity can be applied to agent interactions. Current IETF work, for example, is exploring agent authentication using established OAuth and workload identity standards rather than inventing an entirely separate identity ecosystem for AI.

The broader Zero Trust requirement is that AI agents participate in the enterprise identity architecture instead of operating outside of it.

The Problem With Static Credentials

One of the greatest temptations when building an AI agent is also one of the oldest security shortcuts: the static secret. Give the agent an API key. Put it in a configuration file. Allow the agent to retrieve it when needed. It works. Until that credential is exposed.

A static API key is effectively a bearer secret. If another process obtains it, the target service may have no way to distinguish the legitimate agent from the attacker holding the same key. Long-lived credentials also increase the window in which a compromised credential can be abused.

For AI agents, this problem can become particularly serious because agents may interact with many different tools and systems. Giving a single agent multiple long-lived credentials can turn the agent runtime into a concentration point for access.

NIST has specifically cautioned against using long-lived API keys and bearer tokens as the identity foundation for agents, noting risks involving credential leakage, broad permissions, lack of proof-of-possession, and weak accountability.

Identity Also Creates Accountability

Strong agent authentication is not only about stopping unauthorized access.

It also answers another increasingly important question of what did the agent do?

Imagine an AI agent modifies a firewall policy, downloads sensitive information, changes a cloud configuration, or submits a financial transaction. If the log only shows the credentials of the employee who originally launched the agent, investigators have an incomplete picture.

If the environment instead records:

User A → delegated authority to → Agent B → performed Action C → against Resource D

the organization has a much stronger audit trail.

The human identity establishes who initiated or authorized the workflow. While the agent identity establishes what software actually performed the action. This allows the authorization record to establish what the agent was permitted to do and the resource log establishes what actually occurred.

This distinction will become increasingly important as agents operate with greater independence and participate in longer, multi-step workflows.

Zero Trust Was Built for This

The rise of AI agents may feel like an entirely new cybersecurity challenge.

From an identity perspective, much of the foundation already exists. Zero Trust assumes that network location alone is not sufficient evidence of trust. It requires organizations to identify the entities interacting with resources, authenticate them, authorize only the access they require, continuously evaluate trust, and maintain visibility into their actions.

Those principles apply whether the entity requesting access is a person, laptop, server, cloud workload, service account, or an AI agent.

The immediate challenge for organizations is ensuring that AI does not become an exception to the identity architecture they have spent years building.

In other words, organizations should treat AI agents the way Zero Trust tells us to treat every other entity attempting to access enterprise resources:

Never trust implicitly. Establish the identity. Verify it. Then decide what it is allowed to do.

As AI agents become increasingly capable, extending enterprise identity controls to these new NPEs will be one of the most important steps organizations can take to adopt agentic AI without creating a parallel—and less secure—identity ecosystem.