How Do You Manage Non-Human Identities Across Multiple Clouds?

Key Takeaways

• Excessive permissions, unmanaged credentials, and fragmented visibility increase the likelihood of unauthorized access and lateral movement. The OWASP NHI Top 10 identifies excessive permissions, secret leakage, and weak lifecycle management as the most common machine identity security issues.
• Effective multi-cloud non-human identity management requires continuous discovery, risk analysis, and enforcement across every cloud environment. According to the 2026 SANS State of Identity Threats, 92% of organizations do not rotate non-human identity credentials on a 90-day cycle.
• Governing NHI across multiple clouds requires treating Zero Trust non-human identities as a first-class security program, with the same continuous evaluation, behavioral monitoring, and lifecycle governance applied to human identities, at machine scale.

Why is governing NHI across multiple clouds different from single-cloud identity management?

Most organizations manage non-human identities on a per-cloud basis: AWS IAM in one console, Azure Entra ID in another, Kubernetes RBAC in a third. The problem is that those identities do not stay isolated. A service account created in GitHub Actions gains access to AWS, then to Azure, then to a SaaS application, and nobody sees the full picture because no single tool spans all three. Multi-cloud non-human identity management is not a tool problem, it is a governance model problem. The identities operate across boundaries that existing controls were not designed to cross.

What is the best way to manage non-human identities across multiple clouds?

Managing non-human identities across multiple clouds requires continuous visibility into machine identities, their permissions, and the access they accumulate as cloud environments evolve. Effective programs should:

• Discover NHIs across multiple clouds, including AWS, Azure, Google Cloud, Kubernetes, and SaaS platforms — continuously, not periodically
• Understand permissions, trust relationships, ownership, and potential blast radius per identity across every connected environment
• Continuously monitor identity activity and detect privilege drift as workloads and integrations change
• Enforce least privilege through access reviews, credential rotation, and lifecycle governance from creation through retirement

Common multi-cloud non-human identity risks

Why multi-cloud environments create non-human identity sprawl

Cloud adoption rarely happens in a single environment. Enterprises often run workloads across AWS, Azure, Kubernetes, SaaS applications, CI/CD pipelines, and increasingly, AI agent frameworks. Every one of those environments introduces NHIs. Service accounts, API keys, OAuth grants, workload identities, secrets, and AI agents all require access to systems and data. As cloud adoption expands, these identities often grow faster than security teams can govern.

The OWASP NHI Top 10 identifies excessive permissions, secret exposure, and weak lifecycle management as leading causes of machine identity risk. An IBM survey revealed that only 11% of organizations believe they are fully prepared for the scale of AI agent deployment, which directly expands the NHI population.

From a single identity to a multi-cloud trust chain

Consider an imaginary company, Company X. Five years ago, Company X created a GitHub Actions service account to automate deployments into a development AWS environment. Slowly, they added Kubernetes workloads, Azure service principals, and ultimately, an AI operations agent. Each initiative required additional permissions, but no one assessed how much access had accumulated. Over time, a single compromised token could provide a pathway into multiple cloud environments.

Why is multi-cloud non-human identity management difficult?

Multi-cloud environments create fragmented identity visibility. AWS IAM, Azure Entra ID, Google Cloud IAM, Kubernetes, GitHub Actions, and SaaS applications all maintain separate identity models, making effective permissions and access relationships difficult to understand. Governing NHI across multiple clouds means building a unified view that none of those native tools provides on its own.

The challenge grows as AI agents are introduced. A single agent may access source code repositories, cloud infrastructure, databases, and SaaS applications, creating additional credentials, permissions, and trust relationships. According to a Deloitte survey of 3,235 IT and business leaders, only 21% of organizations have a mature governance model in place for agentic AI.

At Company X, the security team can see the GitHub Actions account, AWS role, Azure service principal, and Kubernetes workload identities individually, but not how they connect. The AI operations agent relies on credentials from all four environments, meaning a compromise in one location could create access paths across the entire ecosystem.

What risks emerge when identities span multiple clouds?

At first glance, Company X's problem appeared to be identity sprawl. In reality, the larger issue was accumulated access. Each new project added permissions, integrations, and trust relationships, gradually expanding what a single compromised identity could reach.

As a result, the GitHub Actions service account that originally deployed code into a development environment eventually gained permission to:

• Deploy workloads into production AWS accounts
• Read secrets from Kubernetes secrets management
• Trigger Azure automation workflows
• Access monitoring platforms used by the AI operations agent
• Connect to SaaS applications through OAuth integrations

None of these permissions appeared dangerous on its own. Together, they created a large risk profile. Yet years of operational changes can produce exactly this outcome.

This pattern is not hypothetical. In 2025, the Salesloft Drift incident demonstrated how a compromised OAuth application could provide attackers access to connected customer environments through trusted machine-to-machine relationships. According to the FINRA cybersecurity alert, attackers stole OAuth tokens and used them to access Salesforce, Google Workspace, Slack, and cloud credentials across more than 700 organizations. The incident underscored how identity trust chains can extend far beyond a single application, creating pathways that are often difficult to detect and govern.

The consequences of poor multi-cloud non-human identity management

When Company X's security team conducted an access review, they discovered a troubling problem. They could see the GitHub Actions account, but they could not determine every system it could reach. The identity had accumulated access across AWS, Azure, Kubernetes, SaaS applications, and the company's AI operations agent. If the token were stolen, incident responders could not quickly identify which resources were exposed or accurately determine the potential blast radius.

This challenge extends beyond security. Operational teams spend time investigating unknown identities. Compliance teams struggle to demonstrate access controls. Cloud teams inherit permissions with unclear ownership. NIST and CISA continue to emphasize identity governance and least-privilege principles because access control failures remain a common contributor to security incidents. When non-human identities are unmanaged, organizations face failed audits, longer incident investigations, higher operational costs, limited visibility into AI agent activity, and expanding attack surfaces.

The result is a growing gap between cloud adoption and identity governance.

A practical approach to multi-cloud non-human identity management

Security teams that successfully manage machine identities generally follow the same process: continuously discover identities, analyze trust relationships, and enforce governance.

Discover every identity

The security team inventoried every identity connected to the GitHub Actions account, including AWS roles, Azure service principals, Kubernetes workload identities, OAuth grants, API tokens, AI agent credentials, and third-party integrations. The effort uncovered several dormant identities and credentials that no longer served a business purpose. When governing NHI across multiple clouds, this discovery step must run continuously because identities are created by automated pipelines, not by human access requests.

Understand permissions

Discovery alone was not enough. The team needed to understand how identities interacted across environments. By mapping effective permissions, cross-cloud trust relationships, access inheritance, credential exposure, and potential attack paths, they discovered that a compromise in GitHub could affect resources across multiple cloud providers. For the first time, they had a clear picture of the account's blast radius.

Enforce controls continuously

The final step is enforcement. Organizations reduce risk by removing unnecessary permissions, deleting unused service accounts, rotating long-lived secrets and API tokens, and establishing lifecycle governance for identities that support automation and AI workflows. Yet these practices remain inconsistent. The 2026 SANS State of Identity Threats found that 92% of organizations do not rotate non-human identity credentials on a 90-day cycle, leaving long-lived credentials exposed to unnecessary risk. Organizations should also implement behavioral monitoring and regularly review OAuth grants and third-party integrations to identify compromised or overprivileged identities.

Best practices for Zero Trust non-human identities

This approach aligns closely with Zero Trust non-human identities principles because access is continuously evaluated rather than assumed. Zero Trust non-human identities programs require that every machine identity authenticate continuously, hold only the permissions its declared purpose requires, and be monitored for behavioral drift in real time. Organizations managing NHI across multiple clouds should prioritize:

• Maintaining an accurate inventory of machine identities across every cloud, SaaS, and AI environment
• Analyzing blast radius before granting new permissions or cross-cloud trust relationships
• Applying least-privilege controls consistently — permissions tied to declared purpose, not historical accumulation
• Rotating secrets and API tokens regularly, with automated workflows that do not depend on manual ticket queues
• Governing identities from creation through retirement using NHI lifecycle controls
• Including AI agents within identity governance programs — every agent is a governed NHI
• Reviewing OAuth grants and third-party integrations regularly to identify compromised or overprivileged identities

OWASP, NIST, and CISA all emphasize these practices as foundational elements of modern identity security and Zero Trust non-human identities programs.

How Token Security approaches multi-cloud non-human identity management

Token Security applies an intent-based security model built specifically for non-human identities.

The challenge

Company X's security team knew thousands of machine identities existed across AWS, Azure, Kubernetes, SaaS applications, and AI systems. What they lacked was a way to understand how those identities connected to one another and where excessive access existed. Governing NHI across multiple clouds without a unified view of trust relationships and blast radius is governance in name only.

The approach

Token Security applies a machine-first security model built specifically for non-human identities. The approach follows three core stages:

• Discover: identify non-human identities across cloud providers, SaaS applications, AI environments, development platforms, and infrastructure
• Understand: use entitlement mapping, blast-radius analysis, and behavioral baselines to reveal effective permissions, risk exposure, and unusual activity across all clouds
• Enforce: reduce risk through automated remediation and lifecycle governance that ensures identities remain governed throughout their lifecycle

The outcome

Organizations gain visibility into their machine identity inventory, identify high-risk trust chains, reduce unnecessary permissions, and establish governance processes that scale alongside cloud and AI adoption.

Real-world results from intent-based security

Organizations managing non-human identities across cloud and AI environments are already seeing the operational impact of identity visibility and governance gaps.

Gaining visibility into machine identity risk

A digital insurance company needed better visibility into machine identity exposure across a growing multi-cloud environment. The challenge was not a lack of security tooling — it was the absence of signal specific enough to act on. In environments where NHI across multiple clouds spans dozens of platforms, distinguishing meaningful risk from routine noise is the operational problem that determines whether governance happens in practice or on paper.

"Token Security has enhanced our security by providing us accurate and relevant visibility into machine identity risks, something I have yet to see from other vendors. It's the first service I've seen that delivers on the widely-made claim of finding machine identity risk. It provides us with the right amount of detail to mitigate issues without burdening us with tens of rows of useless alerts." — Jonathan Jaffe, CISO at Lemonade

This experience reinforces a common challenge in multi-cloud environments: discovering risk is only valuable when security teams can prioritize and act on it. Multi-cloud non-human identity management programs that surface thousands of findings without prioritization do not produce governance. They produce paralysis.

Bringing AI agents under identity governance

A global HR technology company needed visibility into AI agents operating across its environment. AI adoption was accelerating faster than the identity governance program could track — the agents were creating their own NHI population that sat entirely outside the existing review cadence.

"Token Security gives us visibility we simply didn't have before. We can now automatically identify and control custom GPT agents running in our environment and ensure the required security level. Knowing that no AI agent is operating beyond our oversight means we can confidently accelerate our AI adoption, allowing our business to quickly evolve, which is a game-changer for both our security and growth." — Tamir Ronen, Global CISO at HiBob

This example highlights how AI governance increasingly depends on identity governance. As AI agents gain access to cloud resources, managing NHI across multiple clouds must include agentic AI identities alongside traditional service accounts and API tokens. Every agent is a non-human identity. Every agent needs the same governance.

Why non-human identities require a new security model

Multi-cloud architectures, AI agents, and machine-driven automation are changing how access works inside modern enterprises. The challenge is no longer authenticating users. It is governing thousands of machine identities operating continuously across cloud providers, SaaS applications, development environments, and AI systems.

Identity has become the control plane for cloud security and agentic AI because every AI agent ultimately depends on non-human identities, permissions, and credentials to operate. Zero Trust non-human identities is not a framework addition to the existing program, it is the operating model that multi-cloud identity governance requires from the start.

Organizations that can continuously discover identities, understand access relationships, and enforce appropriate controls will be better positioned to support cloud growth, govern AI adoption, and reduce emerging risks. Those who cannot will face expanding blind spots across their environments.