Zero trust for the cloud is really NHI governance in disguise

At a glance

What this is: This is a zero trust overview for cloud environments, arguing that continuous authorization, least privilege, and monitoring are required as cloud and automation complexity grows.

Why it matters: It matters to IAM and NHI practitioners because the same access model that constrains humans must also govern service accounts, tokens, and automated workflows.

By the numbers:

• 91% of organizations across the globe have updated their security strategies.
• One in five organizations use restricted access controls, while 80% still need broader governance coverage for modern cloud access patterns.
• 70% of organizations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read StrongDM's guide to zero trust for cloud access

Context

Zero trust for the cloud is a governance model that assumes no user, device, workload, or action should be trusted by default. In practice, that means identity, device posture, context, and authorization must all be checked before access is granted, including for non-human identities that move through cloud services, pipelines, and automation.

The cloud has weakened the old perimeter model because workloads are distributed, credentials are reusable, and automation now acts with real execution authority. That is why the IAM problem is no longer only about authenticating employees; it is about governing the full set of service accounts, API keys, tokens, certificates, and agent identities that can reach production systems. For background on the identity layer behind this shift, see the Ultimate Guide to NHIs and the section on what are Non-Human Identities.

The article’s Clarity AI example is typical of the broader pattern: teams move toward zero trust to replace brittle VPN-era access paths with auditable, least-privilege controls. The underlying pressure is not unique to one company. It is what happens when cloud scale, remote work, and machine-driven access collide.

Key questions

Q: How should security teams apply zero trust to non-human identities in cloud environments?

A: Security teams should treat non-human identities as first-class subjects in zero trust policy. That means inventorying service accounts, API keys, tokens, and certificates, scoping them to narrow tasks, verifying each access request in context, and revoking standing access when it is no longer needed. Monitoring should confirm enforcement, not replace it.

Q: Why do cloud environments make zero trust harder to enforce?

A: Cloud environments distribute data, automate access, and reuse credentials across tools and services, which weakens perimeter-based assumptions. Zero trust becomes harder because the same identity can be used in many places, often by machines rather than people. That requires continuous authorization, better inventory, and much stricter lifecycle control.

Q: What is the difference between least privilege and zero trust?

A: Least privilege limits what an identity can do after access is granted, while zero trust decides whether access should be granted in the first place and keeps checking it over time. In practice, zero trust uses least privilege as one control, but it also depends on identity verification, device posture, segmentation, and continuous monitoring.

Q: Should organisations prioritise zero trust or NHI governance first?

A: Organisations should treat them as dependent priorities rather than competing projects. Zero trust fails quickly when NHIs are over-permissioned, undocumented, or impossible to revoke. NHI governance gives zero trust the inventory, ownership, and lifecycle controls it needs to work in cloud operations.

Technical breakdown

Identity verification in cloud zero trust

Zero trust starts with proving identity before any resource is reached, but cloud environments now need to verify more than a person’s login. In practice, the control plane should evaluate user identity, device health, session context, and workload identity every time access is requested. For NHIs, this matters because an API key or service account can present valid credentials without proving current intent, trust, or task scope. That gap is where identity-based attacks and credential replay become effective. Strong authentication alone is not enough if the identity is over-permissioned or reused across systems.

Practical implication: Treat every access request as a contextual decision, not a one-time login event.

Least-privilege access for workloads and NHIs

Least privilege in cloud security means granting only the minimum permissions needed for the current task, then removing them when the task ends. For NHIs, the design challenge is that many credentials are long-lived, reused by automation, and granted broad access for convenience. That creates persistent trust debt. Zero trust tries to shrink that debt through role scoping, task scoping, segmentation, and continuous authorization. When applied well, the model reduces blast radius, but only if the underlying identity inventory is accurate and current. Without that inventory, least privilege is mostly a policy statement.

Practical implication: Scope each NHI to a narrow job function and remove standing permissions wherever possible.

Continuous monitoring and micro-segmentation

Continuous monitoring is what keeps zero trust from becoming a static policy exercise. Cloud telemetry should track access patterns, workload behaviour, network paths, and credential use so that anomalous action can be blocked or stepped up for review. Micro-segmentation supports this by limiting how far an identity can move once it has entered the environment. For NHIs, this is especially important because machine identities often have the speed and volume to move laterally faster than human operators can respond. The architecture only works when detection, logging, and enforcement are tightly coupled.

Practical implication: Instrument NHI activity for anomaly detection and constrain lateral movement between cloud zones.

Threat narrative

Attacker objective: The attacker aims to turn a single compromised credential into broad, persistent cloud access with enough privilege to reach data, systems, or automation workflows.

1. Entry occurs when a compromised cloud credential, such as an API key or service account token, is accepted as valid because the environment trusts the identity too broadly.
2. Escalation follows when the identity has permissions beyond its operational need, allowing the attacker to enumerate resources, access additional services, or alter automation paths.
3. Impact is achieved when the attacker uses that access to exfiltrate data, disrupt workloads, or manipulate cloud resources at scale.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Zero trust for the cloud is now an NHI governance problem, not just an endpoint or network problem. The article frames zero trust as continuous authorization, which is correct but incomplete if the identity model stops at humans. Cloud workloads, bots, service accounts, and API keys are now part of the same trust chain, so every access decision must account for machine identity lifecycle, ownership, and revocation. Practitioners should treat cloud zero trust as a governance discipline for all identities with execution authority.

Identity blast radius is the concept teams should operationalize first. In cloud systems, the damage from one credential is defined less by where it is used and more by what it can reach. A broad service account can bypass carefully written perimeter controls because the privilege already exists at the identity layer. That means the real control objective is not only verifying access, but narrowing the reachable surface of each NHI before compromise occurs. Practitioners should design for smaller blast radius, not just stronger login checks.

Continuous monitoring is necessary, but monitoring alone does not solve standing access. The article emphasizes visibility, real-time logging, and anomaly detection, all of which are valuable. Yet if credentials remain long-lived and over-scoped, the environment is still relying on trust that should have expired. The operational lesson is clear: zero trust must be paired with rotation, offboarding, and task-scoped access for NHIs. Practitioners should align monitoring with lifecycle enforcement, not use it as a substitute.

Zero trust adoption will keep failing where cloud teams treat automation as a special exception. DevOps pipelines, IaC tooling, and machine-driven workflows often receive broader permissions because teams optimize for speed. That shortcut is exactly where NHI sprawl and shadow access develop. The broader market signal is that cloud security programs must converge with IAM and NHI governance, or the access model will remain split between policy and reality. Practitioners should bring automation identities into the same review cycle as human users.

Practical zero trust design now depends on workload identity standardization. When credentials are issued inconsistently across clouds and pipelines, policy becomes brittle and hard to audit. Standardised workload identity, short-lived credentials, and explicit trust boundaries reduce that complexity, especially when paired with least privilege and telemetry. The field is moving toward controls that can scale across heterogeneous cloud environments. Practitioners should standardise identity formats before they attempt to standardise policy enforcement.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• For lifecycle controls, see Ultimate Guide to NHIs - Key Challenges and Risks for the governance gap behind over-privilege and weak rotation.

What this signals

Identity blast radius: cloud teams should now measure not only whether an identity is authenticated, but how far it can move before detection or revocation. When an NHI can reach production services with persistent privilege, zero trust becomes a containment exercise instead of a prevention model. Practitioners should tighten scope, shorten credential lifetimes, and review every automation path that bypasses human approval.

With 70% of organisations granting AI systems more access than human employees performing the same job, per the 2026 Infrastructure Identity Survey, the broader identity model is already shifting. Security teams should expect more non-human execution authority, more policy exceptions, and more demand for machine-native access controls. The programme implication is clear: IAM roadmaps must cover autonomous workloads, not just employees.

The cloud zero trust conversation will increasingly converge with workload identity standardisation. Teams that cannot consistently identify and constrain machine access across clouds will continue to rely on brittle exceptions. Practitioners should prepare for governance models that link inventory, policy, and telemetry across both human and non-human identities.

For practitioners

• Map every cloud credential to an owner and purpose Build an inventory that includes service accounts, API keys, tokens, certificates, and automation identities. Record who owns each credential, what system uses it, and when it should be revoked or rotated.
• Replace standing access with task-scoped permissions Define access bundles for common workflows, then grant them only for the duration of the task. Use short-lived credentials and revoke unused permissions after the job completes.
• Segment workload access by environment and function Separate production, staging, and development access paths, and restrict each NHI to the smallest set of services it needs. This reduces lateral movement if a credential is exposed.
• Tie detection rules to credential behavior Alert on unusual token use, impossible travel patterns for interactive sessions, unexpected service-account logins, and access to new resources outside normal job scope.

Key takeaways

• Cloud zero trust is only durable when it includes non-human identities, because service accounts and tokens can bypass human-centric access controls.
• The scale problem is already visible: over-privileged NHIs create a larger attack surface than most perimeter controls can contain.
• Practitioners should pair identity verification with lifecycle enforcement, short-lived access, and segmentation to reduce blast radius.

Key terms

• Non-Human Identity: A non-human identity is any machine, workload, or automated actor that authenticates to systems and receives access decisions. This includes service accounts, API keys, tokens, certificates, and AI agents. The security challenge is governance: ownership, scope, lifecycle, and revocation must be managed with the same discipline as human identity.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and actions an identity can reach if it is misused or compromised. The wider the permissions, the greater the blast radius. In cloud and NHI environments, reducing this radius is often more effective than relying on detection after compromise.
• Continuous Authorization: Continuous authorization is the practice of re-evaluating access throughout a session or workflow instead of trusting a login event once and for all. In zero trust models, this means context, posture, and policy remain active checks. For NHIs, it helps limit long-lived access that can be abused later.
• Micro-segmentation: Micro-segmentation divides cloud environments into smaller trust zones so that identities cannot move freely between systems. It is a containment strategy rather than a prevention strategy. For NHI governance, it limits lateral movement and reduces the damage caused by compromised machine credentials.

Deepen your knowledge

Zero trust for the cloud and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your programme is trying to extend zero trust beyond human access, this is a relevant starting point.

This post draws on content published by StrongDM: What Is Zero Trust for the Cloud? (And Why It's Important). Read the original.