Identity for Non-Human Actors — Governing AI Agents

Most security models begin with a human signing in, but much of modern computing happens when no person is at the keyboard. A build pipeline publishes code, a device sends telemetry, an application reads a database, and an artificial intelligence agent calls a tool. Each of these non-human actors needs a trustworthy way to say, “This is me,” and each resource needs a trustworthy way to answer, “Here is what you may do.”

Start with the basic question: who is acting?

Identity is the way a system represents an actor so it can make decisions about access, accountability, and risk. For humans, the actor is usually a person. For non-human actors, the actor might be an application, a container, a virtual machine, a scheduled job, a device, a robot, or an artificial intelligence agent.

The important idea is not whether the actor has a face. The important idea is whether the actor can be named, authenticated, authorized, monitored, and eventually retired. If a system cannot distinguish one automated actor from another, it cannot reliably limit damage or explain what happened.

A non-human actor should not borrow a human identity just because that is convenient. When a deployment job uses a developer’s account, logs say the developer made every change, even if the job did. That weakens both security and auditability.

Authentication proves identity; authorization limits power

Authentication is the process of proving an actor is who it claims to be. Authorization is the process of deciding what that authenticated actor is allowed to do. These are related, but they are not the same.

A common pattern has five parts. First, a non-human actor presents a credential. Second, an identity provider validates that credential. Third, the identity provider issues a token. Fourth, the target resource checks the token and its own policy. Fifth, the resource allows or denies the requested action.

This pattern matters because the resource should not have to know every detail about how the actor proved itself. It should receive a clear, time-limited statement from a trusted identity provider and then apply local authorization rules.

Authentication proves who is acting; authorization decides what they may do.

A principal is the security record for an actor

In many identity systems, the security record that represents an actor is called a principal. A principal is the thing to which permissions are assigned and against which activity is logged. A human user can be a principal, but so can an application or workload.

In Microsoft Entra ID, non-human actors are commonly represented through application and service principal records, or through managed identities attached to supported compute resources. The product names differ across platforms, but the principle is the same: create a distinct identity record for the thing that acts.

Good design makes principals specific enough to be meaningful. One identity for every workload in a company is too broad. One identity for every temporary process may be too hard to manage. The useful boundary is usually a deployable component, environment, or trust zone.

⚠️

Avoid borrowed accounts. A non-human actor that uses a person’s account hides accountability and often keeps access after the person changes roles.

Credentials are where many designs fail

A credential is the proof an actor uses to authenticate. For people, this might include a password, a passkey, or a multifactor prompt. For non-human actors, common credentials include client secrets, certificates, signed assertions, and platform-issued identity tokens.

Long-lived secrets are easy to understand but hard to protect. They are often copied into configuration files, build systems, ticket comments, local developer machines, and logs. Once a secret spreads, no one can be sure who has it. Rotating it then becomes both urgent and risky.

Safer designs reduce the need for stored secrets. A managed identity lets a supported cloud resource request tokens without embedding a secret in application code. Workload identity federation lets one trusted platform exchange a signed token for another platform’s token, often avoiding a shared secret between them.

Use long-lived client secrets only when better options are not available, and rotate them on a defined schedule.
Prefer certificates over plain secrets when the operating model supports secure key storage and renewal.
Prefer managed identities for workloads running on supported Microsoft cloud resources.
Prefer workload identity federation for trusted connections between platforms such as deployment systems and cloud identity providers.
Keep credentials out of source code, container images, logs, and human chat channels.

Long-lived secrets spread and are hard to rotate; secretless designs avoid them.

Tokens should be narrow, short-lived, and checked

A token is a time-limited statement issued by an identity provider. It usually says who the actor is, who the token is for, when it expires, and what claims are being made about the actor. A resource should validate the token before trusting it.

OpenID Connect is an identity layer commonly used to sign in actors and issue identity-related tokens. OAuth 2.0 is an authorization framework commonly used to delegate access to resources. In practice, modern workload identity often uses both ideas: a trusted issuer, signed tokens, scopes or roles, and strict validation by the receiving service.

The lifetime of a token is a security trade-off. A very short lifetime reduces the window for misuse if the token is stolen, but may increase operational complexity. A very long lifetime is convenient, but it turns a stolen token into a durable key.

A resource must validate a token before it trusts anything the token claims.

Artificial intelligence agents make identity more visible

An artificial intelligence agent is software that can take steps toward a goal, often by calling tools, reading data, writing records, or asking other services to act. That makes identity design especially important. The question is not only what the model can generate, but what the agent is authorized to do.

In Microsoft Foundry, an agent or application may connect to data sources, models, APIs, and Foundry Tools. Each connection should be evaluated as an identity and authorization decision. If the agent can send email, update a customer record, or run code, the permissions behind that action should be explicit and limited.

A useful rule is to separate the identity of the user, the application, and the agent’s tools. Sometimes an agent should act on behalf of a signed-in user. Sometimes it should act as the application itself. Sometimes a tool should have its own constrained identity. These are different trust choices, and logs should make the distinction clear.

⚠️

Prompting is not permission. A system instruction that tells an agent to behave safely is not a substitute for identity, authorization, and enforcement at the resource.

Lifecycle is the real control plane

Creating an identity is only the beginning. Every non-human identity needs an owner, a purpose, an environment, assigned permissions, monitoring, credential handling, and an end-of-life plan. Without lifecycle discipline, organizations accumulate invisible actors with unclear power.

The lifecycle should be boring and repeatable. Register the identity, grant only the access required, monitor actual use, rotate or renew credentials, and remove the identity when the workload is retired. Boring is good here; it means security does not depend on heroic memory.

Monitoring should focus on behavior as well as configuration. An identity that normally reads one database but suddenly lists keys, exports data, or calls a new region deserves attention. For high-risk workloads, Conditional Access in Microsoft Entra ID and other policy controls can add further checks based on location, device context, risk, or workload conditions where supported.

Every non-human identity needs a boring, repeatable path from birth to retirement.

The decisions leaders and practitioners actually face

Identity for non-human actors is not just an implementation detail. It affects delivery speed, incident response, regulatory evidence, cloud cost, and how safely teams can adopt automation and artificial intelligence. The practical challenge is to set defaults that are secure enough without making every deployment a special project.

Leaders should ask for a small number of clear standards rather than a large policy that nobody can apply. Practitioners should be able to answer which identity a workload uses, who owns it, what it can access, how it proves itself, where its activity is logged, and how it will be retired.

The best programs make the safe path the easy path. Templates, platform services, and paved roads can create managed identities, assign least-privilege roles, configure logging, and avoid long-lived secrets by default.

What is the standard identity pattern for applications, jobs, devices, agents, and pipelines?
When are secrets allowed, and who approves exceptions?
Which permissions are granted by default, and how are elevated permissions reviewed?
Where can teams see ownership, credential age, last use, and risky behavior?
How quickly can the organization disable one compromised non-human identity without breaking unrelated systems?

✅

Good default. A well-run platform gives each workload a distinct identity, minimal access, short-lived tokens, and useful logs without asking every team to reinvent the pattern.

Key takeaways

Non-human actors need distinct identities so systems can authenticate, authorize, log, and retire them.
Do not let automated systems borrow human accounts; it weakens accountability and often leaves excess access behind.
Prefer managed identities and workload identity federation over long-lived shared secrets when the platform supports them.
Tokens should be short-lived, audience-specific, and validated by the resource that receives them.
Artificial intelligence agents need enforced permissions at the tool and resource layer, not just safety instructions.
Lifecycle management matters: every non-human identity needs an owner, purpose, permissions, monitoring, renewal, and retirement.

Glossary

Non-human actor: A software system, device, job, agent, or other automated thing that performs actions without being the person at the keyboard.
Identity: A representation of an actor that systems use to make access, logging, and accountability decisions.
Principal: The security record for an actor to which permissions can be assigned and activity can be logged.
Credential: The proof an actor presents to authenticate, such as a secret, certificate, or signed token.
Token: A time-limited statement from an identity provider that a resource can validate before allowing access.
Managed identity: A platform-provided identity for a supported cloud resource that can request tokens without storing a secret in application code.
Workload identity federation: A trust pattern where one platform accepts a signed token from another trusted platform and exchanges it for access without a shared long-lived secret.
Least privilege: The practice of granting only the access an actor needs to perform its intended task, and no more.
Conditional Access: A Microsoft Entra ID policy capability that can add access controls based on conditions such as risk, location, or workload context where supported.