Every cloud environment depends on machines trusting other machines.
Virtual machines access storage. Containers communicate with databases. Serverless functions call APIs. CI/CD pipelines deploy applications, and microservices communicate with each other. Increasingly, AI models, inference workloads and autonomous agents are joining this web of machine-to-machine interaction.
Every interaction requires answers to two fundamental questions: What is making the request, and should it be trusted?
This is the challenge of workload identity and cloud-native trust.
The Cloud Has an Identity Problem
Identity and Access Management has traditionally focused primarily on people: employees authenticate to applications, administrators receive privileged access, and customers authenticate to digital services.
Cloud computing has changed the balance. Modern environments contain enormous numbers of non-human identities (NHIs) associated with workloads, applications, APIs, service accounts and infrastructure automation. Industry estimates vary considerably, but studies suggest that NHIs may outnumber human identities by between 20 and 90 times.
More importantly, they are everywhere.
A cloud-native application may involve identities associated with virtual machines, containers, serverless functions, storage, databases, microservices, APIs and CI/CD pipelines. Generative AI adds model endpoints, inference workloads, vector databases and AI agents.
Unlike human identities, these identities may also be created and destroyed continuously as workloads scale, move or disappear. The result is an identity population that is large, distributed, dynamic and difficult to govern.
Cloud-Native Trust Is Fragmented
Cloud providers give organizations powerful identity controls, but they also make workload identity management more complicated.
AWS IAM roles, Microsoft Azure Managed Identities and Google Cloud service accounts address broadly similar requirements but use different identity constructs, policy models and administrative interfaces. This makes consistent workload identity governance across multiple clouds difficult.
Cloud-native infrastructure is also increasingly ephemeral. A traditional service account might exist for years, while the identity associated with a container, serverless function or CI/CD pipeline may exist for seconds.
This creates a fundamental question: How do you establish persistent trust when the workload itself may not be persistent?
The answer cannot simply be to give every workload a long-lived password or API key.
Secrets Are Not Identities
One persistent weakness in cloud-native security is dependence on static credentials.
API keys, tokens and passwords may be embedded in configuration files, stored in repositories or passed between applications. If an attacker obtains one of these secrets, they may be able to impersonate the workload that owns it.
A secret proves possession of a credential. It does not necessarily prove that the entity presenting it is the workload that should possess it.
Cloud-native architectures therefore need to move towards stronger workload identity, where workloads establish what they are and receive appropriate, preferably short-lived, credentials based upon that identity.
This represents an important evolution:
Static secret → managed secret → short-lived credential → trusted workload identity
Secrets management remains important, but reducing dependence on persistent secrets can eliminate an entire category of credential risk.
Establishing Trust Through Workload Attestation
Moving away from static credentials raises another question: How does a workload prove that it really is what it claims to be?
This is where workload identity and attestation become important.
The Secure Production Identity Framework for Everyone (SPIFFE) provides an open standard for assigning identities to workloads across heterogeneous environments. Rather than tying identity to a long-lived secret, a workload receives a cryptographically verifiable SPIFFE identity that it can use to authenticate to other workloads and services.
SPIRE, an implementation of SPIFFE, provides mechanisms for establishing whether a workload should receive that identity. It can attest the node on which a workload operates and the workload itself using evidence from its execution environment.
This changes the trust question from “Does this process possess the correct secret?” to “Can I establish what this workload is and whether it should receive this identity?”
Once attested, workloads can receive automatically issued, short-lived identity credentials. This is particularly valuable across hybrid and multi-cloud infrastructure, where cloud providers use different native identity constructs.
Attestation, however, only establishes part of trust. Knowing that a workload genuinely is Workload X does not determine whether Workload X should be allowed to access a database or modify a cloud resource.
Put simply: Attestation establishes what the workload is. Identity establishes who it is. Authorization establishes what it may do.
Identity Without Least Privilege Is Not Trust
Excessive permissions remain one of the most significant cloud identity risks. Service accounts, workload roles and tokens are frequently given broader permissions than required because doing so makes applications easier to deploy.
A workload that only needs to read objects from one storage bucket should not have administrative access to the cloud account.
The principle is straightforward: a workload should have only the authority required to perform its role, for only as long as that authority is required.
The difficulty is maintaining this principle while workloads, infrastructure and identities continuously change.
There is also the problem of identities organizations do not know about. CI/CD systems can create temporary service identities. SaaS integrations may introduce service accounts. Marketplace applications can create back-end identities with cloud access. Applications may be decommissioned while their identities and credentials remain active.
Discovery and inventory are therefore foundational to workload identity governance. But organizations need more than a list. They must understand the relationships between identities, workloads, credentials, resources and permissions.
Multi-Cloud Visibility Is Not a Single Identity Model
Claims of complete NHI visibility across every cloud should be treated cautiously.
AWS IAM roles, Azure Managed Identities and Google Cloud service accounts are different constructs, and each cloud exposes different information. Some identities are also created indirectly by applications and services rather than appearing cleanly through IAM interfaces.
Ephemeral infrastructure creates another challenge. By the time a periodic scanner looks for an identity, the associated workload may already have disappeared.
A multi-cloud identity security platform can normalize much of this information into a valuable, consolidated view. But a single dashboard should not be confused with a single underlying identity model.
This matters for Zero Trust. “Never trust, always verify” must apply to machine identities just as it applies to humans.
When one service calls another, trust should be based upon verifiable workload identity, appropriate authorization and policy rather than simply possession of a valid credential.
Agentic AI Changes the Equation
AI agents behave differently from traditional NHIs.
Traditional workloads generally execute predefined application logic. An AI agent may decide which tool to use, which API to call, what information to retrieve and which action to take.
Agentic AI therefore changes NHI security from primarily a problem of quantity into one of quantity, unpredictability and control.
Each agent may require its own identity, while agentic workflows may create sub-agents or processes requiring additional identities. Agents also need access to applications, cloud services, data stores and APIs, and their access patterns may change according to the task being performed.
This creates a difficult security question: What constitutes normal behavior for a machine designed to make decisions dynamically?
It also makes least privilege and delegated authority increasingly important. An agent may be technically capable of calling an API, but that does not mean it should be authorized to use every operation exposed by it.
From Workload Identity to Agentic Trust
AI agents introduce another dimension to workload identity: on whose authority is the workload acting?
A conventional application normally operates according to permissions assigned to it. An AI agent may operate autonomously on behalf of a human user.
Organizations therefore increasingly need to understand not only:
Which identity performed this action?
but also:
On whose behalf was it acting?
This can create a chain of trust:
Human user → AI agent → workload identity → API → cloud resource
Every step needs sufficient identity and authorization context to establish who initiated the activity and what authority was delegated. Otherwise, an audit trail may tell us that a token accessed a database without explaining why it happened or whose authority ultimately enabled the action.
This suggests that the principles underlying workload attestation may become increasingly relevant to agentic trust. For a conventional workload, we want evidence of what workload is running and where. For an AI agent, organizations may increasingly need to establish which agent is operating, who instantiated it, which tools and services it can use, what authority has been delegated, and which policies constrain its behavior.
Five Priorities for Cloud-Native Trust
Organizations should therefore focus on five areas:
- Discover and inventory NHIs across cloud infrastructure, applications, CI/CD, SaaS integrations and AI environments.
- Reduce long-lived secrets by moving towards short-lived credentials and identity-based authentication.
- Implement least privilege, continuously aligning permissions with the minimum that workloads need and only for as long as needed.
- Monitor identity use, correlating authentication and access with workload, application and cloud-resource context.
- Apply Zero Trust to machines, requiring verifiable identity and explicit authorization for machine-to-machine interactions.
Identity becomes the Cloud Trust Fabric
Cloud-native computing has already forced organizations to think about identity beyond the human user. Applications now consist of constantly changing workloads, APIs, containers and services, each requiring identities and permissions.
Agentic AI accelerates this transition by introducing machine identities capable not only of executing instructions but of making decisions and taking actions.
Organizations therefore need to know what is acting, what it is allowed to do, which resources it can reach and, increasingly, on whose behalf it is acting.
Workload attestation establishes what is running. Workload identity enables it to authenticate. Authorization determines what it may do. Governance constrains how that authority is exercised.
Together, they provide the foundation for cloud-native trust — and increasingly, for trust in the agentic enterprise.
Explore This Live at AIdentity & Non-Human Identity Impact Day 2026
Attestation, identity, and authorization are not just architectural principles. They are the working sessions at this year's AIdentity & Non-Human Identity Impact Day 2026, October 6 in Munich.
Join the in-person conference for analyst insight and practitioner case studies on building this foundation in your own environment.
