Subscribe to the Non-Human & AI Identity Journal

How should organisations govern identity across hybrid cloud environments?

Treat hybrid identity as a single policy problem, not separate cloud and on-prem tasks. Standardize roles, approvals, and logging across environments, then enforce least privilege and time-bound access for both humans and NHIs. The goal is consistent authorization, because inconsistent controls create the gaps attackers exploit.

Why This Matters for Security Teams

Hybrid cloud identity governance breaks when teams treat each platform as a separate control plane. Humans, service accounts, API keys, CI/CD runners, and AI agents all move across the same business processes, but they often inherit different approval paths, different logging quality, and different revocation speeds. That mismatch is where exposure accumulates. NHIMG research shows Ultimate Guide to NHIs found 97% of NHIs carry excessive privileges, which is a clear signal that entitlement sprawl is already a governance problem, not just a technical one. The right lens is identity lifecycle control, not cloud-by-cloud administration, supported by a common policy model and audit trail. Current guidance from NIST Cybersecurity Framework 2.0 also points toward centralized governance, continuous monitoring, and access discipline rather than siloed exception handling. In practice, many security teams encounter hybrid identity failures only after a breach review reveals that “temporary” access was never really temporary.

How It Works in Practice

Organisations should govern hybrid identity as a single set of identity services wrapped around many execution environments. That means one policy model for provisioning, one approval standard, one logging format, and one revocation process whether the identity lives in an on-prem directory, a cloud IAM service, or a workload runtime. For NHIs, that usually means pairing Lifecycle Processes for Managing NHIs with secrets rotation, offboarding, and access reviews, instead of leaving each platform team to invent its own version. For humans, RBAC should define baseline job access, but JIT elevation should be used for sensitive actions so standing privilege stays low. For machines, workload identity should be the default, because it proves what the workload is without forcing long-lived shared secrets into code or pipelines.

A practical implementation usually includes:

  • centralised identity sources synced into each cloud and on-prem platform
  • policy-as-code for approvals, session duration, and step-up authentication
  • short-lived credentials for both human elevation and NHI access
  • consistent telemetry that feeds SIEM, SOAR, and access review workflows
  • periodic validation against NIST Cybersecurity Framework 2.0 to confirm access, monitoring, and recovery controls are working together

This matters because over-privileged NHIs create disproportionate risk: NHIMG’s 52 NHI Breaches Analysis shows how credential misuse and weak scoping repeatedly turn routine automation into incident pathways. These controls tend to break down when cloud teams, platform teams, and application owners each manage their own entitlement model because revocation becomes inconsistent across environments.

Common Variations and Edge Cases

Tighter access governance often increases operational overhead, so organisations have to balance speed against control friction. That tradeoff is real in multi-account cloud estates, regulated environments, and DevOps pipelines where release velocity can tempt teams to keep static credentials for convenience. Best practice is evolving, but current guidance suggests using JIT and ephemeral secrets wherever possible, especially for admin and production access. For agentic workloads, the challenge is sharper: autonomous systems do not follow stable, human-like access patterns, so static RBAC alone is not enough. Intent-based authorisation is emerging as the better pattern, where the policy decision is made at request time based on what the agent is trying to do, what tool it is using, and whether the action matches its permitted objective.

There is no universal standard for this yet, which means organisations should document the policy decisions they make and make the assumptions auditable. That is especially important when AI agents can chain tools, move laterally, or request secrets across multiple clouds in one workflow. NHIMG’s Top 10 NHI Issues and 230M AWS environment compromise both reinforce the same lesson: when identity boundaries are inconsistent, compromise spreads faster than teams can manually respond. Organisations that keep static secrets in legacy automation or split access governance across cloud silos tend to lose the ability to prove who had access, when, and why.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Non-Human Identity Top 10 NHI-03 Addresses NHI credential rotation and standing secret risk in hybrid estates.
NIST CSF 2.0 PR.AC-4 Maps to least-privilege access governance across cloud and on-prem systems.
NIST AI RMF Supports governance for autonomous AI agents using hybrid identities.

Replace long-lived secrets with short-lived credentials and enforce rotation across all hybrid workloads.