Why access risk is outpacing cloud security controls

At a glance

What this is: This is a cloud access governance analysis showing that identity creation, privilege assignment, and change velocity now outstrip manual IAM controls.

Why it matters: It matters because IAM, IGA, PAM, and cloud security teams must govern service accounts, tokens, and agent access at runtime, not after drift has already expanded the attack surface.

By the numbers:

• Non-Human Identities now outnumber human employees by at least 45 to 1, according to Token Security.

Context

Cloud access risk is the gap between how fast identities and permissions are created in modern environments and how slowly security governance can review them. In Token Security's analysis, that gap is now the central problem in cloud IAM because code, automation, and autonomous decision-making have overtaken manual control cycles.

Traditional control models assume access changes slowly enough to be reviewed, certified, and remediated before exposure spreads. In cloud-native estates, ephemeral workloads, CI/CD pipelines, service accounts, and AI-driven access decisions undermine that assumption by changing the access state faster than governance can observe it.

The result is not just more access, but less durable accountability. When identities can be created, reused, and abandoned in minutes, the security problem shifts from visibility alone to governing privilege at the point of issuance.

Key questions

Q: What breaks when access reviews are only annual in cloud IAM?

A: Annual reviews miss the pace of cloud change. New roles, copied policies, temporary exceptions, and short-lived workloads can all create excessive access long before the next review cycle. By the time an auditor sees the issue, the identity may already have accumulated years of unused entitlement.

Q: Why do service accounts and tokens create more risk than many teams expect?

A: Because they often carry standing privilege, operate quietly, and remain valid long after the business need changes. That combination increases blast radius when a credential is exposed and makes detection harder than with human accounts. The risk is not the token itself. It is the duration and breadth of access it enables.

Q: How do security teams know whether cloud access policy is actually working?

A: They should test whether policy decisions are traceable from discovery to approval to revocation. If a team can see apps but cannot prove who owns the integration, what data it can touch, and how it is removed, then the policy is only partially working. Effective governance produces evidence, not just alerts.

Q: What happens when an AI agent is allowed to act in the cloud without clear containment controls?

A: A misbehaving or compromised agent can access unauthorized systems, expose sensitive data, or trigger downstream actions faster than human responders can intervene. If the environment lacks predefined containment workflows, the team may see the problem only after it has spread. Logging every action and setting thresholds for human review help limit that blast radius.

Technical breakdown

Why static IAM policies drift in cloud-native environments

Static IAM assumes access can be expressed once and kept stable until the next review cycle. That assumption breaks in cloud-native systems because infrastructure, membership, tags, and workloads mutate continuously. A policy that was correct at deployment can become stale within minutes as auto-scaling, redeployment, or workload churn changes the context that policy was written for. Drift is therefore not an edge case but the normal operating state. The control failure is temporal: the policy is still syntactically valid while the environment it governs has already changed. Practical implication: security teams need continuous entitlement evaluation, not periodic validation after drift has accumulated.

Practical implication: Move from deployment-time policy snapshots to continuous entitlement evaluation for cloud identities and workloads.

How machine-speed identity creation expands the access surface

In modern engineering pipelines, identities are created as part of software execution rather than as a separate IAM workflow. IaC, DevOps automation, and API-driven provisioning can generate service accounts, tokens, and permissions at a rate that human reviewers cannot track. That means the access surface expands at the same pace as delivery. The technical issue is not only volume, but transience: many identities exist long enough to be used but not long enough to be captured in a manual process. Access governance built around tickets, spreadsheets, and quarterly recertification cannot keep pace with that lifecycle. Practical implication: inventory and policy enforcement must operate as event-driven controls tied to identity creation events.

Practical implication: Instrument identity creation as an event stream so new permissions are inventoried and governed immediately.

Why autonomous AI agents break fixed-access assumptions

An autonomous AI agent is not just another automated workload. It can make runtime decisions about what to access, which tool to call, and when to act without a human approval gate between those steps. That changes the identity problem because the access request itself is not fully knowable in advance. Static authorization models assume the actor's intent is stable enough to predefine least privilege. With autonomous agents, privilege can expand or contract mid-session as the agent pursues a goal. That makes access boundaries dynamic, probabilistic, and harder to certify after the fact. Practical implication: governance must move from static approval to runtime containment and scoped issuance.

Practical implication: Treat autonomous agents as runtime governance problems and enforce scoped, time-bound access at issuance.

Threat narrative

Attacker objective: The objective is to exploit valid but weakly governed cloud access paths to move laterally, exfiltrate data, or control infrastructure before security teams can react.

1. Entry occurs when valid cloud identities, tokens, or service accounts are created faster than central governance can inventory them.
2. Credential or privilege exposure follows when those identities are granted broader access than their actual workload needs or are left outside review coverage.
3. Escalation happens when attackers or misbehaving automation reuse those valid credentials to reach adjacent cloud resources at machine speed.
4. Impact is unauthorized data access, lateral movement across cloud services, or control of infrastructure before manual remediation can catch up.

Breaches seen in the wild

• Internet Archive breach 2024: An exposed GitLab token opened Internet Archive code and 31 million user records; unrotated Zendesk tokens let the attacker back in weeks later.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

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

NHI Mgmt Group analysis

Velocity, not visibility, is now the primary control problem: cloud governance fails when access changes faster than review cycles can observe it. The issue is not that organisations cannot see identities at all, but that they see them too late to influence the risk state. This shifts identity security from periodic assurance to continuous control of issuance, privilege, and duration. Practitioners should treat time-to-governance as a control metric, not an operational inconvenience.

Static IAM was designed for stable states, not event-driven identity creation: the model assumes a durable relationship between subject, entitlement, and review window. That assumption fails when identities are spawned by code, altered by pipelines, and abandoned within minutes. The implication is that access governance has to move closer to runtime events, because the old review cadence no longer maps to the actual lifecycle of access.

Access review debt is accumulating faster than certification programmes can clear it: quarterly review processes cannot meaningfully certify machine-generated entitlements at cloud scale. This is especially true where service accounts, tokens, and API-connected tools proliferate outside the IAM team's line of sight. The practical conclusion is that review programmes must stop being the primary control for fast-changing non-human access.

Ephemeral credential trust debt: the cloud has normalised credentials that are issued quickly, used briefly, and then forgotten by governance. That creates trust debt whenever the issuance event is not paired with automatic scope, inventory, and expiry enforcement. The result is a structural mismatch between how access is consumed and how it is governed. Practitioners should redesign for issuance-time control rather than retrospective cleanup.

Autonomous decision-making collapses precomputed least-privilege assumptions: least privilege was designed for actors whose task scope is known before execution begins. That assumption fails when an AI agent can choose tools and access paths at runtime without human approval. The implication is that teams must rethink whether least privilege is still a provisioning-time concept or becomes a session-scoped containment problem.

From our research library:

• 82% of breaches involved data stored in the cloud, according to IBM (2024).

What this signals

Ephemeral credential trust debt: organisations now accumulate risk whenever access is issued faster than it can be inventoried, scoped, and retired. That debt is especially visible in cloud estates where service accounts, tokens, and AI-driven access all outlive the governance processes designed to manage them.

The practical response is to move governance closer to issuance and runtime. For identity teams, that means treating continuous entitlement evaluation, short-lived access, and automatic downscoping as baseline controls rather than advanced maturity markers.

For practitioners

• Implement event-driven identity inventory Capture every new service account, token, and workload identity as it is created in cloud and SaaS environments. Use the creation event to trigger ownership, expiry, and policy checks before access becomes invisible to the IAM team.
• Replace quarterly reviews for fast-changing access Limit human access reviews to durable entitlements and move machine identity governance to continuous verification. Quarterly recertification is too slow for identities that are issued and abandoned inside a deployment cycle.
• Enforce just-in-time access for privileged cloud actions Remove standing privilege for sensitive operations and require short-lived issuance tied to a specific task or request. That reduces the window in which a stolen credential can be reused against cloud resources.
• Downscope overprivileged service accounts automatically Compare actual permissions with observed usage and remove excess access without waiting for a manual ticket. Automated right-sizing is the control that keeps privilege aligned with workload behaviour.
• Contain autonomous agent access at issuance time Treat AI agents as runtime identities whose access should be bounded before the task starts and revoked when the task ends. Do not rely on post hoc review to explain what an agent already chose to access.

Key takeaways

• Cloud access risk has outgrown manual IAM because identities and permissions now change at machine speed.
• The control gap is visible in service accounts, tokens, ephemeral workloads, and autonomous agents that outlive review cycles.
• Continuous inventory, just-in-time access, and automatic downscoping are the controls that matter most when governance is slower than execution.

Key terms

• Access Risk Velocity: The rate at which identities, permissions, and trust relationships change in an environment. In cloud and agentic systems, access risk velocity matters because security controls can become stale before they are reviewed, turning governance lag into an active exposure window.
• Shadow Access: Shadow access is unauthorised or unmanaged access that continues to exist because a credential, role, or account was forgotten, reused, or never properly revoked. In NHI programmes, shadow access is especially dangerous because it can remain active across cloud, SaaS, and automation layers without obvious human ownership.
• Ephemeral Workload Identity: Ephemeral workload identity is a short-lived credential issued to a container, service, or agent for a specific task window. It reduces exposure by avoiding durable secrets on disk or in environment variables, which limits what an attacker can steal if runtime code is compromised.
• Just-in-Time Access Request: Just-in-Time Access Request is a pattern that grants access only when it is needed and only for the duration required. It reduces standing privilege by making access temporary, policy driven, and task scoped. This approach is especially useful for contractors, sensitive systems, and short-lived operational work.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.