Zero Trust for Non-Human Identities

An agent is not a person, but it can still read data, call applications, trigger workflows, and make mistakes at machine speed. That makes its identity a security boundary. Zero Trust asks a simple question at every step: why should this request be allowed right now? For non-human identities such as agents, the answer must come from the agent’s registered identity, its purpose, its sponsor, its current risk, the data it is trying to reach, and the network path it is using.

Zero Trust, applied to agents

Zero Trust is the security model that refuses to treat location as proof of safety. A request is not trusted just because it comes from inside a corporate network, from a familiar application, or from an identity that already has some access. Each request is evaluated in context.

For agents, that context has to include more than a client identifier or a secret. A governed agent should have a known identity, a defined purpose, a human sponsor, a technical owner, scoped permissions, useful labels, and policies that can react when its behavior changes.

Microsoft Entra Agent ID extends this model to agent identities. It gives agents a place in the identity system so they can be created, managed, reviewed, protected, and retired like other important identities rather than treated as loose credentials hidden inside automation.

Least privilege is the base layer

The first control is still the oldest and most important one: least privilege. An agent should receive only the permissions it needs for the task it performs, and those permissions should be narrow enough that a fault, prompt injection, stolen credential, or bad instruction cannot become a broad breach.

This matters because agents often connect several systems. A sales assistant might read customer relationship management records, summarize email threads, and create follow-up tasks. A service desk agent might inspect tickets, query device state, and draft responses. Each connection is useful, but each one is also a possible path to data or action the agent should not have.

Least privilege is not a one-time setup choice. It has to be reviewed as the agent changes, as its tools change, and as the business process around it changes. Access that was reasonable during a pilot may be excessive in production.

Four controls that bring Zero Trust into operation

Microsoft Entra Agent ID adds practical controls that make Zero Trust enforceable for agent identities rather than merely aspirational.

Conditional Access can target agents so policy decisions are made for agent identities and agent resources, not only for human users. Policies can also use an agent’s calculated risk level, which allows controls to respond to behavior instead of relying only on static allow and deny rules.

Identity Protection for agents detects and responds to risky agent behavior. Examples include an agent attempting an unusually high number of sign-ins or reaching for a resource that is unfamiliar for that agent. These signals help separate normal automation from behavior that deserves a challenge, restriction, or investigation.

Network-level controls extend the same idea beyond identity tokens. Through a secure web and artificial intelligence (AI) gateway, organizations can apply web content filtering, threat intelligence filtering, and file filtering to agent traffic.

• Conditional Access policies written for agent identities and agent resources.
• Risk-based policy decisions that use the agent’s calculated risk level.
• Identity Protection that detects and responds to unusual agent behavior.
• Secure web and AI gateway controls that filter web content, threats, and files in agent traffic.

Two identity patterns: interactive and autonomous

Agent identity design depends on how the agent works. The first pattern is an interactive agent. It acts on behalf of a specific user, and its access is evaluated in that user’s context. The token it obtains carries both user context and agent context, so the system can see both who the human is and which agent is acting.

The second pattern is an autonomous agent. It operates independently and authenticates using its own blueprint credentials rather than borrowing a user’s context. This is the right shape for agents that run on schedules, process queues, perform background work, or act without a person actively present.

Microsoft Entra Agent ID supports both patterns and standardizes how they are created and managed. Builders use the familiar Microsoft identity platform approach: register blueprints, provision identities, and acquire tokens through Microsoft Graph. The goal is to make the agent a first-class identity from the beginning, not an anonymous script with a secret added later.

Sponsor and owner are not the same job

Every governed agent needs human accountability, but there are two different kinds. The sponsor is the person, or supported group, accountable for the business reason the agent exists. The sponsor decides whether the agent is still needed, approves extensions when access is close to expiring, and authorizes suspension during a security incident.

The owner has a different responsibility: technical operation and incident response. The owner keeps the agent working, understands its implementation, and helps investigate when it behaves unexpectedly.

Keeping these roles separate is not administrative decoration. It is what lets governance workflows route the right question to the right human. If a sponsor leaves the organization, lifecycle workflows can route notifications to that sponsor’s manager. Access-package expiry escalations can go to the sponsor. Entitlement-management approvers can use the sponsor relationship to decide whether continued access still makes business sense.

For this reason, every agent identity and every agent identity blueprint requires at least one sponsor. Without that link, an agent can keep running after its business purpose has disappeared.

Tag agents at birth

A simple operational habit prevents many later governance problems: assign custom security attributes when the agent is provisioned. In practice, this means the agent is labeled at creation with attributes such as business unit, environment, data sensitivity, sponsor, purpose, or workload type.

Those labels make the agent filterable, reviewable, and targetable by policy from its first moment. Conditional Access rules can use the tags. Reporting can group agents by risk or owner. Reviews can focus on production agents that touch sensitive data. Incident responders can quickly identify which agents belong to the affected process.

The alternative is familiar and painful: create first, classify later. That leaves a gap in which the agent exists but is not easy to govern. At scale, that gap becomes an inventory problem, then a policy problem, and eventually a security problem.

The decisions leaders and practitioners must make

Zero Trust for agents becomes real through design decisions, not slogans. Leaders decide the minimum governance standard for any agent that reaches enterprise data. Architects decide which identity pattern fits each class of agent. Security teams decide which risk signals should trigger restriction, review, or suspension. Platform teams decide how tagging and sponsor assignment become part of provisioning rather than manual cleanup.

A useful test is to pick one important agent and ask five questions. Can we identify it unambiguously? Do we know its sponsor and owner? Can we explain every permission it has? Can policy treat it differently based on its tags and risk? Can we see and filter its network traffic? If any answer is no, the agent is not yet fully inside the Zero Trust model.

The goal is not to slow down useful agent work. The goal is to make safe deployment the default path. When identity, tags, sponsors, policies, and traffic controls are built into the platform, teams can create agents faster because the guardrails are already there.

1. Choose the identity pattern: interactive for user-context work, autonomous for independent work.
2. Require at least one sponsor before the agent or blueprint is treated as governed.
3. Separate sponsor responsibility from technical owner responsibility.
4. Tag the agent during provisioning, not after deployment.
5. Use risk, Conditional Access, Identity Protection, and network filtering as ongoing controls.

Glossary

Zero Trust

A security model that verifies each request in context instead of trusting it because of network location or prior access.

Non-human identity

An identity used by software, services, automation, or agents rather than by a person.

Microsoft Entra Agent ID

A Microsoft Entra capability for giving agents managed identities, governance relationships, and security controls.

Conditional Access

A policy system that decides whether to allow, block, or restrict access based on signals such as identity, resource, condition, and risk.

Identity Protection

A capability that detects risky identity behavior and can trigger protective responses.

Least privilege

The practice of granting only the permissions required to perform a specific task.

Agent blueprint

A registered definition or pattern used to provision and manage agent identities.

Custom security attributes

Organization-defined labels assigned to identities so they can be filtered, governed, and targeted by policy.

Microsoft Graph

Microsoft’s unified interface for accessing and managing Microsoft 365 and Entra resources programmatically.