Zero-trust workload identity for microservices and AI agents

At a glance

What this is: This is an analysis of zero-trust authorization for microservices, with a focus on workload identity, on-behalf-of access, and AI agents as governed identities.

Why it matters: It matters because IAM, PAM, and NHI programmes increasingly have to control service-to-service and agent-to-service access with the same discipline once reserved for human users.

👉 Read Cerbos' analysis of zero-trust authorization for microservices and AI agents

Context

Zero-trust authorization in distributed systems means every service call, API request, and agent action is evaluated explicitly instead of being trusted because it sits inside the network. That shift matters for workload identity because the service itself, not just the human user, becomes the object of authorization.

The governance gap is simple: when service A can call service B by default, compromise in one place can cascade laterally through the stack. Once AI agents are added to the same trust model, the problem is no longer only microservice isolation but whether non-human identities are being authorized with enough granularity, auditability, and scope control.

Cerbos frames the answer as decoupled authorization, where policy is separated from application code and decisions can combine workload identity with user context. That is a familiar zero-trust pattern, but it becomes more important when workloads, bots, and AI agents are all treated as actors that can exceed the trust assumptions of perimeter-based design.

Key questions

Q: How should security teams implement zero-trust authorization for microservices?

A: Security teams should evaluate every internal request with policy, not perimeter trust, and base decisions on the calling workload, the resource, and any delegated user context. The goal is to separate authentication from authorization so a valid service still cannot exceed its intended scope. That approach gives consistent control across services, APIs, and AI-agent-connected workflows.

Q: Why do service-to-service permissions create lateral movement risk?

A: Service-to-service permissions create lateral movement risk because one compromised workload can reuse internal trust to reach other APIs, data stores, and control functions. If access is broad or implicit, the attacker does not need to break new authentication barriers. Strong policy boundaries and unique workload identities reduce that blast radius.

Q: What do security teams get wrong about AI agent access control?

A: Teams often secure the agent as if authentication alone is enough, but AI agents also need tightly scoped authorization for the actions they can initiate. If the agent can call tools, chain requests, or act on behalf of users, policy must constrain both the agent's own identity and the delegated context behind it.

Q: Who is accountable when delegated service access exceeds user intent?

A: Accountability sits with the organisation that allowed the delegation model to bypass explicit policy checks. When a service acts on behalf of a user, both identities must be part of the authorization decision. If they are not, the resulting access is technically authenticated but governance-wise unsupported.

Technical breakdown

Why perimeter trust breaks down in microservices

In a distributed application, perimeter trust assumes that anything already inside the network can be trusted to call anything else. That model fails because compromise of one service immediately creates a pathway for lateral movement. The real issue is not just authentication at the edge, but the absence of resource-level authorization between internal services. In practice, every service call becomes a decision point, and the decision must reflect both who is calling and what that caller is allowed to do in that context.

Practical implication: move authorization from network location to policy enforcement at each service boundary.

How workload identity changes service-to-service trust

Workload identity gives each service, bot, or automated process its own verifiable identity, usually represented by a token such as a JWT. That identity is what lets the platform distinguish one workload from another even when they share infrastructure or run in the same cluster. Once workloads are uniquely identified, policy can enforce whether a particular service may read a resource, invoke an API, or pass through a delegated request. This is the foundation for controlling machine access without collapsing everything into generic application trust.

Practical implication: issue distinct identities to workloads and bind authorization rules to those identities, not to host location.

On-behalf-of authorization for user-initiated requests

On-behalf-of authorization evaluates two identities at once: the service making the request and the user whose action initiated it. That matters because the service may be valid, but the user's scope may not justify the downstream action. By combining workload claims with user claims, policy can enforce department boundaries, role restrictions, or resource-level constraints without embedding logic in application code. This is especially important in service chains where a request traverses multiple hops and the original user intent could otherwise be lost.

Practical implication: preserve end-user context across service hops and evaluate both identities before allowing downstream access.

Threat narrative

Attacker objective: The objective is to turn one trusted internal identity into broad access across multiple services and data paths.

1. Entry occurs when one workload is trusted to reach another purely because it is inside the service boundary or holds a valid internal identity.
2. Escalation follows when a compromised or over-permissioned service reuses its legitimacy to call additional internal APIs and move laterally across the environment.
3. Impact appears when the attacker uses that trust chain to reach data, control functions, or AI-agent-connected services that should not have been accessible from the first foothold.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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

NHI Mgmt Group analysis

Perimeter-based trust is no longer a usable authorization assumption for distributed identity systems. Microservices architecture and AI-agent-enabled workflows both destroy the idea that internal traffic is inherently safe. Once a service or agent can initiate downstream actions, identity has to be evaluated at the request level, not the network level. The implication is that access control must move from location trust to explicit policy decisions for every internal actor.

Workload identity is the control plane that makes zero-trust authorization possible for non-human actors. Services, bots, and AI agents all need distinct identities if security teams want to distinguish legitimate calls from overreach. Without that separation, authorization collapses into infrastructure trust and audit trails lose meaning. Practitioners should treat workload identity as a prerequisite for governance, not as an implementation detail.

On-behalf-of authorization closes one of the most common blind spots in distributed systems. A service can be valid while the user behind it is not entitled to the downstream action, and the reverse can also be true. That is why user context and workload context must be evaluated together when requests cross service boundaries. Teams that ignore this pattern will keep granting technically authenticated requests that are operationally out of scope.

AI agents intensify the zero-trust problem because they behave like workloads with delegated intent. If an agent can call tools, reach APIs, and chain actions across services, then the real question is not whether it is authenticated but whether its authority is bounded tightly enough to survive runtime decision-making. The field needs to stop treating AI agents as just another application component and start governing them as non-human identities with potentially broad blast radius.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control baseline, see Ultimate Guide to NHIs for lifecycle, visibility, rotation, and offboarding guidance.

What this signals

AI agent growth is turning authorization into a governance problem, not just an application design issue. If 98% of organisations expect to deploy more AI agents, the number of non-human actors that need scoped permissions, auditability, and offboarding will keep rising. Teams that still design around user-only access reviews will keep missing the control surface where agent risk actually accumulates.

Delegated access is becoming the place where identity, policy, and observability meet. In practice, that means the next control debate is not whether microservices should be authenticated, but whether every hop preserves enough context for a defensible decision. Cerbos-like patterns point toward policy-as-control-plane thinking, while the Ultimate Guide to NHIs remains the clearest anchor for the baseline identity model.

Programme owners should watch for three signals: shared credentials disappearing from service fleets, policy checks moving out of code, and AI-agent requests being evaluated with user context attached. Those are early signs that the organisation is treating workload identity as a governed discipline rather than an infrastructure convenience.

For practitioners

• Separate authorization from application logic Place policy evaluation in a dedicated control plane so service code does not hard-code access decisions. That makes service-to-service checks consistent and auditable across microservices, serverless functions, and agent-connected APIs.
• Issue unique identities to every workload Assign each service, bot, and automation path a distinct workload identity and avoid shared credentials across tiers. Use those identities as the basis for access decisions, auditing, and incident containment.
• Enforce on-behalf-of checks for delegated calls Require policies to evaluate both the calling service and the end-user context before a downstream action is approved. This is essential when requests traverse multiple services or when AI agents operate on user-triggered workflows.
• Audit internal trust paths for lateral movement risk Map which services can call which resources without explicit denial rules, then remove broad internal reach that would let one compromise fan out across the environment. Focus first on high-value APIs and data stores.

Key takeaways

• Microservices and AI agents break the old assumption that internal traffic can be trusted by default.
• Workload identity and on-behalf-of authorization are the controls that let teams govern non-human actors without flattening them into generic application access.
• The practical shift is from network-based trust to policy-based decisions at every service boundary, with auditability built in.

Key terms

• Workload Identity: A workload identity is the unique, verifiable identity assigned to a service, bot, function, or agent so it can be authenticated and authorized independently of the infrastructure it runs on. It is the basis for distinguishing one machine actor from another in policy decisions and audit trails.
• On-Behalf-Of Authorization: On-behalf-of authorization is a decision pattern that evaluates both the calling service and the original user whose action triggered the request. It prevents delegated workflows from exceeding user intent by enforcing policy on the combined identity context instead of trusting the service alone.
• Decoupled Authorization: Decoupled authorization separates policy decisions from application code so access control can be managed centrally and consistently. In distributed systems, that separation improves auditability, reduces duplicated logic, and makes it easier to enforce the same rule across microservices, APIs, and agent-driven workflows.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerbos: Zero Trust for Microservices: A Guide to Secure Authorization. Read the original.