Why Workload Identity Alone Is Not Enough for AI Agents
- Mayank Soni
- May 19
- 9 min read
Abstract
Agentic AI systems introduce an identity problem that traditional infrastructure was not designed to fully solve. When a software agent acts autonomously, querying APIs, invoking tools, calling services, or coordinating with other agents — the identity question is not only:
“What workload is making this request?”
The more important question becomes:
“Which human authorised this action, through which agent, for what purpose, with what scope, and can that be proven at every step?”
Workload identity frameworks such as SPIFFE(Secure Production Identity Framework for Everyone)/SPIRE(SPIFFE Runtime Environment) can establish strong cryptographic proof of workload identity. They can prove that a workload is genuine, short-lived credentials are being used, and the workload identity was issued based on runtime attestation. However, workload identity alone does not carry the human context required for agentic AI systems.
An agent may be a valid workload and still lack proof that a specific user authorised a specific action. For agentic AI systems, identity must therefore combine workload identity with delegated human context.
1. Introduction
Many modern systems are built around service-to-service authentication. A service calls another service, proves its identity, and is allowed or denied based on whether that service is trusted.
This model works well when the workload itself is the principal actor.
Agentic AI systems change this model.
An AI agent may query data, call tools, invoke APIs, modify resources, or coordinate with other agents. These actions are often performed on behalf of a human user. The user may see one AI assistant or one interface, but behind that interface there may be multiple workloads and downstream services participating in the task.
This creates an identity gap.
A system may be able to prove that the calling workload is a valid agent process. But that does not prove that a specific human user authorised the agent to perform the requested action. It also does not prove the scope of that authorisation or whether downstream services can verify the original user intent.
For agentic AI systems, identity must answer two questions at the same time:
What workload is making the request?
Which user authorised this action, and within what scope?
Workload identity answers the first question. It does not, by itself, answer the second.
2. Workload Identity as the Default Starting Point
When teams first approach agent identity, the natural instinct is to use workload identity. This instinct is reasonable because agents are, at runtime, software workloads.
A deployed agent may run as a process, a service, a container, or a workload in a larger platform. It needs an identity. Other services need to know whether the calling agent is genuine. The system needs a way to avoid static secrets, long-lived credentials, or identity based only on network location.
Workload identity is designed for this problem.
It answers:
“Is this workload really the workload it claims to be?”
This is important for agentic AI systems. A system should be able to verify that a request came from the expected agent workload, not from an unknown or impersonating process.
However, agentic AI introduces another layer of meaning. The workload is not always acting only for itself. It may be acting on behalf of a human user.
That distinction is where workload identity alone becomes insufficient.
3. What SPIFFE/SPIRE Solves
SPIFFE and its reference implementation, SPIRE, provide a structured approach to workload identity.
They improve on older models based on network location, static API keys, or long-lived service account credentials. Instead of relying on a manually distributed credential, identity is issued to a workload based on attestation of runtime properties.
The core mechanism is the SVID, or SPIFFE Verifiable Identity Document.
An SVID may be issued as a short-lived X.509 certificate or JWT. It is issued to a workload by a trust authority based on properties such as:
The workload’s service account
The node where it is running
Characteristics of the running process
The SVID asserts a SPIFFE ID in the following form:
spiffe://trust-domain/path
A relying party can cryptographically verify this identity if it trusts the issuing authority.
SPIFFE/SPIRE provides several properties that are useful for agentic AI systems.
3.1 Short-lived credentials
SVIDs are short-lived and rotate automatically. This reduces dependence on long-lived secrets that must be manually managed, leaked, revoked, or rotated.
For an agent process, this means identity can be issued and refreshed throughout the workload’s lifetime without manual intervention.
3.2 Attestation-based issuance
Identity is derived from what the workload is, not simply from a credential it was given.
An agent running with a specific service account, on a specific node, with specific runtime characteristics can receive an identity that reflects those properties. This makes impersonation harder than in models where credentials are passed around or stored directly by the application.
3.3 Trust across environments
SPIRE federation allows workloads across different clusters, cloud providers, and trust domains to verify each other’s identities without sharing a common secret or a common certificate authority.
For agentic AI systems that span multiple environments, this is valuable. Agents and services can establish workload-level trust across boundaries.
4. The Missing Dimension: Human Context
The limitation of workload identity is precise:
It proves what the workload is. It does not prove who authorised the workload’s action.
An SVID issued to an agent process establishes the identity of that process. It does not establish that a specific user authorised the agent to perform a specific task.
It does not carry:
The identity of the human user on whose behalf the agent is acting
The scope of the user’s authorisation
The user’s original intent
The chain of delegation through which the request arrived
Proof that the downstream action remains within what the user approved
This is not a flaw in SPIFFE/SPIRE. It is a matter of design scope. Workload identity was designed to identify workloads. It was not designed to represent delegated human authorisation.
In simple service-to-service systems, that may be enough. In agentic AI systems, it is not.
If an agent is querying user data, modifying resources, invoking tools, or initiating actions with real-world consequences, the receiving service needs more than proof that the agent workload is genuine. It needs proof that the agent is authorised to act for the specific user in the specific context.
5. Why Agentic AI Changes the Identity Question
Traditional workload identity focuses on this question:
“Is this the service it claims to be?”
Agentic AI requires a broader question:
“Is this service authorised to act on behalf of this specific user, for this specific purpose, to this specific extent?”
That is a different identity model.
In a workload-first model, the workload is the principal. The service is the actor. Authorisation decisions are based on whether that service is trusted to perform a given operation.
In an agentic AI model, the workload may be an actor, but it may not be the original source of authority. The agent may be carrying delegated authority from a human user.
For example, a service may receive a request from a valid agent workload. Workload identity can prove that the caller is a trusted agent process. But the service still cannot determine whether:
The user authorised this specific action
The user granted the required scope
The agent is operating within that scope
The request is part of a legitimate user-driven task
The action can later be traced back to the user’s intent
This is the central identity gap in agentic AI systems.
6. Why Configuration Alone Does Not Solve the Problem
The gap between workload identity and delegated human context cannot be closed by configuration alone.
A team can configure service identities, trust domains, workload certificates, client credentials, policies, and access rules. These controls are useful. But they do not automatically create a model where human authorisation is preserved across agent actions.
The issue is architectural.
An agentic AI system must deliberately decide how user context is established, represented, propagated, constrained, and verified. Those decisions become difficult to reverse once agents are running in production and downstream services have been built around early assumptions.
The question is not whether workload identity should be used. It should remain a foundational layer.
The question is how workload identity should be combined with a second layer: one that represents the human principal and the scope of authorisation.
7. The Single-Agent Case
In a simple single-agent scenario, user authorisation can be represented more cleanly.
The user interacts with one agent. The user is redirected to an authorisation server. The requested scopes are presented. The user grants consent. The agent receives an access token scoped to what the user approved. The agent then presents that token to resource servers, which validate it and enforce the scope.
In this model:
The sub claim identifies the user
The token scope defines what was granted
The agent’s client ID identifies the agent
For one user, one agent, and one clearly scoped task, this model can work well.
However, this model depends on several assumptions:
The user is present at authorisation time
The same agent that requests the token is the agent that uses it
The required scope is known and finite when consent is granted
These assumptions begin to break down as agentic AI systems become more complex.
8. The Boundary Where Workload Identity Falls Short
Workload identity remains necessary, but it becomes incomplete when agents begin to operate beyond simple service-to-service calls.
The gap appears when:
An agent acts on behalf of a user
A user-facing agent delegates work to another agent
Several agents participate in one user task
A downstream service needs to know the original user context
A resource modification must be audited back to human intent
The system must prove not only which workload acted, but why it was allowed to act
In these cases, workload identity can identify each agent workload, but it cannot by itself preserve the human authorisation chain.
The system may know:
“Agent service A made this request.”
But it may not know:
“Agent service A made this request because this user authorised this task with this scope.”
That distinction is critical.
9. Technical Implications for Agentic AI Design
Several technical implications follow from this identity model.
9.1 Workload identity should remain foundational
Workload identity provides strong proof of what the agent workload is. Short-lived credentials, attestation-based issuance, and trust federation are valuable properties.
Agentic AI systems should build on workload identity rather than bypass it.
9.2 Workload identity must not be treated as user authorisation
A valid workload identity does not mean the workload is authorised to act for a user.
A service receiving a request from an agent should not assume that workload trust equals user consent. The system must separately represent the human principal and the authorised scope.
9.3 Human principal context must be explicit
The user context cannot remain implicit.
If an agent is acting for a user, the system needs a way to represent:
Who the user is
Which agent is acting
What scope was granted
Whether the current action is within that scope
Without this, downstream services cannot reliably distinguish between a valid agent workload and a valid user-authorised action.
9.4 Agent identity is a composition
Agent identity should not be treated as a single credential or single claim.
It is a composition of at least two layers:
Workload identity: proof of what the agent workload is
Delegated human context: proof of who authorised the action and what was granted
Both are required for a sound agentic identity model.
9.5 Early design choices matter
Identity architecture should be decided before agent chains become complex.
If early systems are built around workload identity alone, downstream services may later need to be changed to understand user context, scope, delegation, and audit requirements. Retrofitting those properties after production deployment can become difficult.
10. A Practical Design Principle
A useful design principle for agentic AI systems is:
Workload identity proves the agent is genuine. Delegated human context proves the action is authorised.
Both sides are necessary.
A valid agent workload should not be allowed to perform arbitrary user-impacting actions simply because the workload itself is trusted. The system must also verify that the action is connected to a specific user authorisation and remains within the intended scope.
This distinction helps avoid a common design mistake: assuming that because an agent is trusted infrastructure, every action it takes is automatically authorised.
In agentic AI systems, the agent is not just infrastructure. It is often an intermediary carrying human intent.
11. Conclusion
Workload identity is an essential foundation for agentic AI systems, but it is not a complete agent identity model.
SPIFFE/SPIRE can establish what an agent workload is. It can provide short-lived credentials, attestation-based identity, and trust federation across environments. These properties are valuable and should remain part of the architecture.
But an agent is often more than a workload. It may act on behalf of a human user, invoke tools, call downstream services, or coordinate with other agents. In those cases, the system must also preserve human principal context, authorised scope, and a verifiable link between the action and the user’s intent.
The design lesson is clear:
Agent identity must start with workload identity, but it cannot stop there.
Writer's Overview
Mayank Soni – DevSecOps Specialist
Mayank leads DevSecOps initiatives at Midships, driving platform-level automation, CI/CD pipeline optimization, and secure infrastructure delivery. With a dual role as contributor and team lead, he focuses on scalable deployment strategies, cost-efficient infrastructure, and faster feedback loops across cloud environments. His hands-on experience spans infrastructure, security, and application layers—including building and deploying full-stack services using modern cloud-native architectures.
Short bio: Mayank is a DevSecOps expert with 6+ years of experience across AWS, Azure, and GCP. He specializes in infrastructure automation, secure CI/CD pipelines, and observability systems. With a strong foundation in both cloud engineering and application development, he supports Midships’ cloud transformation across Southeast Asia.
Comments