Top security architects in 2024 reflect cloud identity governance gaps

At a glance

What this is: This is a profile-style roundup of security architects and the cloud security responsibilities they represent, with the central finding that cloud security now depends on stronger identity governance and architecture discipline.

Why it matters: It matters to IAM teams because the same architecture, access, and oversight patterns that shape human and workload identity programmes are now being pressured by cloud scale and agentic AI adoption.

👉 Read Oasis Security's top 10 security architects roundup for cloud security context

Context

Security architecture is no longer just about network segmentation or hardened infrastructure. In cloud environments, the control plane, identity plane, and data plane overlap constantly, which makes access design as important as system design. That is why the article’s emphasis on security architects is really an identity governance story as much as it is a cloud security story.

The practitioners it highlights sit at the point where policy becomes implementation. For IAM, PAM, and NHI teams, that means architecture decisions about privilege, monitoring, and compliance are now inseparable from who or what is allowed to act in production. In that sense, the starting position is typical of modern cloud programmes, not exceptional.

Key questions

Q: How should security teams govern cloud workloads that rely on service accounts and API keys?

A: Treat workload identities as first-class governed assets, not implementation details. Assign ownership, scope permissions to specific tasks, rotate credentials on a defined cadence, and ensure every secret has a revocation path. The strongest programmes tie cloud architecture reviews to access review and offboarding processes so that hidden standing privilege cannot persist unnoticed.

Q: Why do cloud security programmes need both architecture and identity governance?

A: Cloud architecture decides where trust is created, while identity governance decides who or what can use it. If those disciplines are separated, organisations often end up with broad roles, weak auditability, and credentials that outlive their purpose. Effective cloud security joins design-time control with lifecycle management and operational monitoring.

Q: What breaks when workload identities are not lifecycle-managed?

A: Ownership becomes unclear, credentials linger after the original use case ends, and access reviews lose meaning because they are checking entitlements that no longer match reality. In cloud environments, that creates hidden persistence for service accounts, tokens, and certificates, which increases blast radius and makes incident response slower.

Q: Who should own cloud identity decisions when security architecture and IAM overlap?

A: Security architecture, IAM, PAM, and platform teams should share the model, but one group must own the final control map. Without clear ownership, cloud privilege design becomes fragmented, and no team can reliably answer who approved access, who can revoke it, or which system is responsible when controls fail.

Technical breakdown

Cloud security architecture as identity control design

Security architecture in cloud environments is not just about hardening workloads. It is the design of the identity and control relationships that determine who can create, change, access, or observe systems. In practice, that means the architect defines boundaries for authentication, authorisation, logging, key handling, and privileged operations. When those boundaries are weak, the cloud does not merely become easier to attack. It becomes easier for routine administration to turn into sustained overreach, especially when service accounts, API keys, and platform roles are left with broad standing access.

Practical implication: review cloud architecture decisions as identity decisions, not only infrastructure decisions.

Security architects, privileged access, and workload identity

Cloud security architecture increasingly depends on workload identity rather than shared secrets. That shift matters because service accounts, tokens, certificates, and platform roles often outlive the context in which they were created. Security architects therefore have to think about least privilege, rotation, observability, and offboarding together. If those controls are separated, the architecture may look sound on paper while still leaving long-lived credentials, excessive permissions, and weak audit trails in the environment.

Practical implication: align workload identity design with privileged access governance and lifecycle controls.

Why cloud security roles now intersect with agentic AI governance

As AI systems become more embedded in infrastructure operations, the same architecture patterns used for workload identity will be tested by autonomous behaviour. An AI agent that can choose tools, timing, and actions independently changes the governance problem from static entitlement management to runtime control of decisions. That is why cloud security architects are now adjacent to agentic AI governance even when the article itself is framed around traditional security roles. The architectural question shifts from whether an identity is trusted to how its actions are constrained, attributed, and continuously verified.

Practical implication: extend cloud architecture reviews to cover agentic AI access paths and runtime decision boundaries.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

Cloud security architecture is now identity governance by another name. The article frames security architects as cloud defenders, but the underlying work is entitlement design, control enforcement, and operational accountability. That means architecture choices now decide whether access is bounded, observable, and revocable across humans, workloads, and machine-driven operations. Practitioners should treat the security architect function as a governance layer, not just a technical role.

Workload identity remains the structural baseline for cloud trust. Service accounts, API keys, and certificates are still the most common way cloud systems act, which makes their lifecycle the central control surface. OWASP-NHI and NIST CSF both point to the same reality: if identity is not scoped, rotated, and monitored, the rest of the stack inherits that weakness. The practitioner conclusion is straightforward: architecture quality is inseparable from NHI discipline.

Security architects are now the bridge between human IAM and machine identity control. The article’s list of cloud security leaders shows how often the same people are expected to govern access, compliance, and incident response at once. That cross-domain pressure is where NHIMG’s perspective matters most, because the same design errors recur across human users, service accounts, and emerging AI systems. Practitioners should use one governance model, not three disconnected ones.

Runtime governance gap: cloud programmes often assume static access patterns even when environments change continuously. That assumption fails as soon as identities are created by automation, inherited through platform roles, or used across multiple services without human re-approval. The implication is that teams must stop treating access as a provisioning event and start treating it as an operational state that can drift minute by minute.

Cloud security architecture is becoming the control point where agentic AI will inherit NHI failure modes. Even where the article only hints at machine-speed operations, the governance lesson is clear: if organisations already struggle with service account sprawl, the same controls will be under pressure once AI systems begin taking operational actions. Practitioners should plan for that convergence now, before architecture debt is multiplied by autonomous behaviour.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• From our research: 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• The governance pattern in cloud security is shifting from isolated access controls to continuous identity oversight across humans, workloads, and autonomous systems.

What this signals

Cloud security teams are moving into a governance model where architecture reviews and identity reviews can no longer be separated. The pressure point is not just the number of controls, but whether those controls can follow fast-changing access paths across cloud platforms and machine identities. The NIST Cybersecurity Framework 2.0 remains a useful anchor for organising that work.

Identity blast radius: when cloud roles, secrets, and automation accounts are designed without lifecycle discipline, the impact of a single compromise spreads across more systems than teams expect. That is why cloud security architecture now needs explicit ownership, revocation, and auditability at every boundary, not just perimeter controls.

With 67% of organisations still relying heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey, the next phase of cloud governance will be measured by how well teams can replace persistent trust with verifiable, short-lived identity state.

For practitioners

• Map cloud architecture decisions to identity controls Inventory where authentication, authorisation, logging, and secret handling are defined in cloud design reviews, then tie each one to a named owner in IAM, PAM, or NHI governance. The goal is to stop treating architecture as a separate conversation from access governance.
• Reduce standing access for workload identities Review service accounts, tokens, and certificates for excessive permissions, long-lived validity, and unclear ownership. Replace broad platform roles with task-scoped access and explicit lifecycle checkpoints, especially for production automation.
• Add offboarding to cloud control design Require a revocation path for every non-human identity used in cloud environments, including accounts created by pipelines or infrastructure automation. If an identity cannot be cleanly retired, the architecture still depends on hidden standing privilege.
• Prepare cloud governance for autonomous execution paths Identify which approval, logging, and escalation controls assume a human is behind the request. Those controls need review before AI systems or automated operations begin making independent tool and timing decisions in production.

Key takeaways

• Security architecture is now an identity governance problem because cloud control decisions define who and what can act in production.
• Workload identities remain the most common source of hidden persistence when credentials, roles, and ownership are not lifecycle-managed.
• Cloud programmes that separate architecture from IAM will struggle to govern both today’s machine identities and tomorrow’s autonomous systems.

Key terms

• Cloud Security Architecture: The design of controls, boundaries, and trust relationships that shape how cloud systems are accessed and operated. In identity terms, it determines where authentication, authorisation, logging, and privilege limits live, and whether those controls can be enforced consistently across people, workloads, and automation.
• Workload Identity: A non-human identity used by software, services, or automation to authenticate and act within a system. It includes service accounts, tokens, certificates, and keys, and it becomes risky when ownership, scope, rotation, or revocation are unclear or inconsistent across environments.
• Identity Blast Radius: The amount of damage that can spread when one identity is compromised or misused. In cloud environments, a large blast radius usually signals excessive privilege, weak segmentation, or poor lifecycle governance, and it often shows up first in service accounts and automation credentials.
• Lifecycle Governance: The discipline of managing identity from creation through review, rotation, and retirement. For cloud and non-human identities, lifecycle governance is what prevents stale access, abandoned credentials, and unclear ownership from becoming permanent parts of the control environment.

Deepen your knowledge

Cloud security architecture and workload identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are aligning cloud controls with identity lifecycle management, it is worth exploring.

This post draws on content published by Oasis Security: Top 10 Security Architects to follow on Linkedin. Read the original.