Why IAM in the Cloud needs attention?

Updated August 2026: This article was originally published in August 2024 and has been comprehensively updated to reflect the latest IAM security practices, including Identity Threat Detection and Response (ITDR), CIEM, machine identity governance, non-human identity management, and the impact of AI coding agents on identity security as of 2026.

If you work in cloud security, you already know this intuitively: identity is where breaches start. Not the network. Not the firewall. Not even the application layer. The identity layer — who can access what, with which permissions, for how long — is consistently the root cause of the most expensive, most damaging cloud security incidents we see year after year.

This isn’t a new observation, but it’s one that still doesn’t get the operational attention it deserves. Let’s talk about why cloud IAM demands urgent, sustained focus — and what modern identity security actually looks like in 2026.

A Brief History of Cloud IAM

The story of cloud IAM begins in the early 2000s when organizations started migrating workloads off-premises. The initial identity model was laughably simple: usernames, passwords, and basic access control lists (ACLs) bolted onto cloud resources. It worked when you had a handful of EC2 instances and a small engineering team.

As AWS, Azure, and GCP matured, so did their IAM services. AWS IAM launched in 2010, introducing policies, roles, and the concept of least privilege at scale. Azure Active Directory (now Entra ID) and GCP IAM followed with their own models. Each brought centralized control over user access, resource-level policies, and granular permission management.

But here’s what nobody anticipated: the sheer explosion of identities. What started as managing a few dozen developer accounts has become managing hundreds of thousands of principals — human users, service accounts, CI/CD pipelines, third-party integrations, workload identities, and now AI agents. The IAM systems themselves are solid. The problem is that organizations never built the operational muscle to govern them at scale.

Why Identity Is the Perimeter (Not the Network)

In on-prem environments, the network was the perimeter. You had firewalls, VPNs, DMZs. If an attacker couldn’t get past the network boundary, they couldn’t access internal resources. That model made sense when your infrastructure lived in a physical data center.

In the cloud, there is no network boundary in the traditional sense. Every API endpoint is reachable from the internet. Every resource is accessed via credentials. The thing standing between an attacker and your production data isn’t a firewall — it’s an IAM policy.

The breach data makes this painfully clear:

• MGM Resorts (2023) — $110M+ in damages. Attackers social-engineered their way into IAM credentials, then moved laterally through the environment. The network didn’t fail. Identity did.
• Snowflake Customer Breaches (2024) — 165+ organizations compromised. Attackers used stolen credentials (many harvested from infostealer malware) to access Snowflake customer instances. No MFA was enforced. No credential rotation was in place. Ticketmaster, AT&T, Santander, and others lost hundreds of millions of records — all because of identity hygiene failures.
• Microsoft Midnight Blizzard (2024) — Corporate email compromise. A legacy test OAuth application with elevated permissions was the entry point. A single overlooked service principal gave nation-state attackers months of access to executive email.
• Change Healthcare (2024) — $22B parent company disruption. Stolen credentials to a Citrix portal without MFA led to one of the largest healthcare data breaches in US history, affecting over 100 million people.

Every one of these breaches has the same root cause: an identity with too much access, left unmonitored, for too long.

IAM — Both the Blessing and the Curse of Cloud Flexibility

In one of our ScaletoZero podcast episodes, Joseph South made a point that still resonates: the ability to create users and roles at will is simultaneously the greatest advantage and the greatest security pitfall of the cloud.

Think about what the cloud gives developers: a blank slate. Spin up infrastructure in minutes. Create service accounts for every microservice. Grant cross-account access with a few lines of Terraform. It’s powerful, and it’s exactly what enables teams to ship fast.

But every identity created is an identity that needs governance. Every role assumed is a permission boundary that needs monitoring. Every API key issued is a credential that can be stolen.

Organizations routinely grant excessive permissions — AdministratorAccess policies, wildcard resource ARNs, overly permissive trust relationships — just to unblock development. The justification is always “we’ll tighten it later.” Later never comes. And then those over-privileged identities become the attack surface.

This is why getting IAM architecture right isn’t a “nice to have” security initiative. It’s foundational. It has to come before vulnerability management, before SIEM tuning, before compliance certifications. Because if your identity layer is broken, none of those other controls matter.

The 400,000 Accounts Case Study: How to Deep Dive into IAM

Joe shared a case study that perfectly illustrates the identity sprawl problem. A company migrated to the cloud without a dedicated security team. Their estimate: roughly 40,000 user accounts. The reality after a thorough audit: over 400,000 accounts. A 10x discrepancy.

How does this happen? Service accounts proliferate. CI/CD pipelines spawn credentials. Developers create test users. Third-party integrations get access keys. Former employees’ accounts persist. Nobody is tracking the full identity inventory because nobody owns it.

If you’re facing this situation, here’s the operational playbook:

Step 1: Enforce Tagging as Identity Metadata

In cloud environments, tagging is your first line of defense for identity governance. Every principal, every role, every service account should carry tags that answer: Who created this? Who owns it? What team does it belong to? What workload does it support?

Without tags, you have 400,000 anonymous accounts and no way to triage them.

Step 2: Identify Dormant and Over-Privileged Accounts

Pull access logs. Find accounts that haven’t authenticated in 90 days, 180 days, a year. Cross-reference their permissions. An account with AdministratorAccess that hasn’t been used in 12 months is a ticking time bomb — it’s either a forgotten service account or a former employee’s credentials waiting to be compromised.

Step 3: Engage Teams with Specific Questions

Once you have your dormant/over-privileged list, reach out to owning teams:

• What accounts do you own, and which are actively needed?
• What’s the minimum permission set required for each role?
• Can we consolidate overlapping roles?
• Can any of these be converted to time-bound (JIT) access?
• Are there accounts from vendors you no longer contract with?

Step 4: Implement Continuous Governance

This isn’t a one-time cleanup. Identity sprawl is a constant force. You need automated discovery, continuous right-sizing, and alerting on permission drift.

This is exactly what Cloudanix CIEM provides — continuous visibility into your identity posture, automated detection of over-privileged accounts, and actionable recommendations for least privilege enforcement.

Prioritizing Between Identity Types: Human, Machine, Third-Party, and AI Agents

Not all identities carry the same risk profile. Effective IAM governance requires understanding the taxonomy:

Human Identities

Humans remain the weakest link. They fall for phishing. They reuse passwords. They leave companies without their access being revoked. Start here.

Prioritize active human identities with elevated permissions. Understand who has admin access, who has access to production data, and whether their access level matches their current role. Discuss with teams whether consolidating roles or implementing time-bound access can reduce standing privilege.

Machine Identities (Non-Human Identities)

Here’s the reality most organizations haven’t fully grasped: machine identities outnumber human identities by 45:1 or more in typical cloud environments. Service accounts, workload identities, CI/CD pipeline principals, Lambda execution roles, Kubernetes service accounts — these are the bulk of your identity surface.

Machine identities are particularly dangerous because they often have broader permissions than any human (think deployment pipelines with full admin access), they rarely have MFA, their credentials are long-lived, and nobody monitors their behavior patterns.

Third-Party Identities

Vendors, consultants, SaaS integrations — all of these create identity footprints in your environment. Review questions to ask: Are we still in contract? Do they still need access? Is their access scoped appropriately? When was the last time they authenticated?

Organizations routinely discover vendor access that persists years after the engagement ended.

AI Agent Identities — The Newest Surface

This is the category that didn’t exist two years ago and is now one of the fastest-growing identity surfaces in cloud environments. AI coding agents like Claude Code, Cursor, and Kiro are being given AWS credentials, cloud API access, and the ability to create infrastructure. These agents operate with long-lived access keys, often with broad permissions, and their actions are difficult to distinguish from legitimate developer activity.

We’ll cover this in depth below, but recognize that AI agents represent a fundamentally new class of identity that traditional IAM governance wasn’t designed for.

Non-Human Identity (NHI) Governance

Non-Human Identity management has emerged as its own discipline because the scale and risk profile of machine identities demands dedicated tooling and process.

Consider what NHIs look like in a modern cloud environment:

• Service accounts — used by applications to access cloud APIs
• CI/CD principals — GitHub Actions, Jenkins, GitLab runners with deployment permissions
• Workload identities — Kubernetes pods, Lambda functions, ECS tasks with IAM roles
• API keys and tokens — long-lived credentials embedded in configuration
• OAuth applications — third-party integrations with delegated permissions
• Federated identities — cross-account and cross-cloud trust relationships

The challenge with NHIs is threefold. First, there’s no human to authenticate via MFA or respond to a suspicious login alert. Second, their credentials tend to be long-lived (some API keys never expire). Third, their permission boundaries are often set once and never reviewed.

Effective NHI governance requires:

1. Discovery — You can’t secure what you can’t see. Inventory every non-human principal, its permissions, its last authentication time, and its owning team.
2. Classification — Not all NHIs carry equal risk. A read-only monitoring service account is different from a deployment pipeline with admin access.
3. Lifecycle management — Credentials should rotate automatically. Unused NHIs should be deprovisioned. Permissions should right-size based on actual usage.
4. Behavioral monitoring — Establish baselines for NHI activity patterns and alert on anomalies.

Cloudanix Non-Human Identity governance provides this end-to-end lifecycle management — from discovery and classification through continuous monitoring and automated remediation of NHI risk.

AI Coding Agents: The Newest Identity Surface

The rise of AI-assisted development has introduced a category of identity that security teams are still catching up to. Tools like Claude Code, Cursor, GitHub Copilot Workspace, and Kiro are increasingly given direct access to cloud environments — not just code repositories, but actual infrastructure.

Here’s the typical pattern: a developer configures an AI coding agent with AWS credentials (often long-lived access keys) so the agent can deploy infrastructure, run tests against cloud services, or manage resources. These credentials frequently have the same broad permissions as the developer themselves — sometimes broader, because developers don’t want the agent to hit permission errors mid-task.

The security implications are significant:

• Long-lived credentials — AI agents typically use static access keys rather than short-lived session tokens
• Broad permissions — Agents are given wide access to avoid friction during development
• Opaque action chains — When an AI agent takes 50 actions in sequence, distinguishing legitimate from malicious behavior is nearly impossible
• No MFA capability — AI agents can’t respond to MFA challenges
• Session persistence — Agents may maintain credentials across sessions, expanding the window of exposure

This is why Cloudanix Coding Agent JIT exists — to provide just-in-time, scoped, time-bound credentials to AI coding agents instead of long-lived keys. The agent gets the access it needs, for the duration it needs it, with permissions scoped to the specific task. When the session ends, access revokes automatically.

Identity Threat Detection and Response (ITDR)

ITDR has emerged as a critical capability because traditional security tools weren’t designed to detect identity-based attacks. A SIEM can tell you that an API call happened. ITDR can tell you whether that API call is consistent with the identity’s historical behavior.

What does ITDR look like in practice?

• Behavioral Baselines: Every identity — human and machine — develops a pattern. A developer who normally accesses S3 and Lambda in us-east-1 between 9am and 6pm EST suddenly making IAM changes in ap-southeast-1 at 3am is an anomaly worth investigating.
• Credential Misuse Detection: When stolen credentials are used, the attacker’s behavior rarely matches the legitimate user’s patterns. Different IP ranges, different API calls, different resource access patterns. ITDR systems detect this deviation.
• Privilege Escalation Monitoring: Attackers who gain initial access with limited permissions will attempt to escalate. ITDR tracks the sequence of identity-related API calls that indicate escalation attempts — creating new roles, attaching admin policies, modifying trust relationships.
• Impossible Travel Detection: An identity authenticating from two geographically distant locations within a timeframe that makes physical travel impossible is a strong signal of credential compromise.
• Session Anomalies: Detecting unusual session durations, abnormal numbers of concurrent sessions, or sessions that persist beyond expected lifetimes.

ITDR isn’t optional anymore. It’s how you detect the attacks that bypass your preventive controls — because they always will. No IAM policy is perfect, and attackers are sophisticated enough to exploit the gaps.

CIEM: The Visibility Layer

Cloud Infrastructure Entitlement Management (CIEM) is the foundation that makes everything else possible. Without visibility into who has access to what, you can’t enforce least privilege, you can’t detect anomalies, and you can’t respond to incidents.

CIEM answers the questions that keep security teams up at night:

• Which identities have permissions they’ve never used?
• Which roles could access production data if compromised?
• What’s the blast radius of any single credential being stolen?
• Where are the cross-account trust relationships that could enable lateral movement?
• Which service accounts have admin-equivalent permissions?

Critically, CIEM operates across cloud providers. Your identity risk isn’t siloed to AWS or Azure or GCP — it spans all of them. A compromised identity in one cloud can potentially pivot to resources in another through federated trust.

Cloudanix CIEM provides this multi-cloud visibility layer — mapping effective permissions across your entire identity surface, identifying over-privileged accounts, detecting permission drift, and providing the actionable intelligence needed to enforce least privilege continuously.

JIT Access: The Enforcement Layer

If CIEM gives you visibility, Just-In-Time (JIT) access gives you enforcement. The principle is simple: eliminate standing privilege entirely. No human, no machine, no agent should have persistent access to sensitive resources. Instead, access is granted on-demand, scoped to the specific task, time-bound, and automatically revoked.

Why does standing privilege matter? Because every persistent credential is a liability. If an access key sits in a config file for six months, that’s six months where a compromised laptop, a leaked repository, or an infostealer infection can turn that key into a breach.

JIT eliminates this entire attack class. If there’s no standing privilege to steal, credential theft becomes significantly less impactful.

Cloudanix JIT Access implements this across seven distinct access patterns:

1. Cloud JIT — Time-bound elevation for cloud console and API access
2. Database JIT — Temporary credentials for database access without persistent connection strings
3. VM JIT — Just-in-time SSH/RDP access to virtual machines
4. Kubernetes JIT — Scoped, time-bound access to K8s clusters and namespaces
5. SaaS JIT — Temporary elevated permissions in SaaS applications
6. Agentic JIT — Time-bound credentials for autonomous AI agents operating in cloud environments
7. Coding Agent JIT — Scoped access for AI development tools like Claude Code, Cursor, and Kiro

The results speak for themselves. Moneyview eliminated standing privilege across their cloud environment using Cloudanix JIT. Finfinity achieved a 100% reduction in privileged access exposure — meaning zero persistent admin credentials in their production environment.

Putting It All Together: The Modern Identity Security Stack

Modern cloud identity security isn’t a single tool or a single practice. It’s a layered approach:

1. Discovery and Inventory (CIEM) — Know every identity, every permission, every trust relationship across every cloud
2. Governance (NHI + Human Identity Management) — Classify identities, assign ownership, enforce lifecycle management
3. Least Privilege Enforcement (JIT) — Eliminate standing privilege, implement time-bound access, automate revocation
4. Detection (ITDR) — Monitor identity behavior, detect anomalies, alert on credential misuse
5. Response — When identity-based attacks occur, have automated playbooks for credential rotation, session revocation, and blast radius containment

Each layer depends on the ones below it. You can’t enforce least privilege without visibility. You can’t detect anomalies without baselines. You can’t respond effectively without detection.

Where to Start

If you’re staring at your cloud environment wondering where to begin, here’s a pragmatic sequence:

• Week 1-2: Get visibility. Deploy CIEM tooling and inventory your identity surface. You’ll be surprised by what you find — most organizations have 3-5x more identities than they think.
• Week 3-4: Identify the highest-risk identities. Admin-equivalent permissions, long-lived credentials, dormant accounts with elevated access. These are your immediate priorities.
• Month 2: Implement JIT for your most sensitive access patterns. Start with production database access and cloud admin roles — these are the highest-impact, highest-risk credentials.
• Month 3: Expand to NHI governance. Inventory your service accounts, CI/CD credentials, and API keys. Implement rotation policies and behavioral monitoring.
• Ongoing: Build toward zero standing privilege. Every persistent credential eliminated is one less thing that can be stolen.

Conclusion

IAM in the cloud isn’t a problem you solve once. It’s an operational discipline that requires continuous attention, modern tooling, and organizational commitment. The threat landscape is evolving — attackers are increasingly targeting identities because it works. The breaches at MGM, Snowflake, Microsoft, and Change Healthcare all prove that identity is where security fails first.

The good news: the tooling has caught up. Between CIEM for visibility, JIT for enforcement, ITDR for detection, and NHI governance for the machine identity surface, organizations have the capabilities needed to secure their identity perimeter. The question is whether they’ll invest the operational effort to actually implement them.

Identity is the perimeter. Treat it accordingly.

People Also Read

• IAM Governance for Cloud: CIEM & JIT Access
• A Complete List of AWS IAM Misconfigurations
• Top 6 AWS IAM Misconfigurations To Avoid
• AWS IAM Permission Boundary and Why You Shouldn’t Ignore It
• Implementing IAM in the Google Cloud Platform (GCP)
• Top 10 Identity and Access Management Solutions
• Role of AI in Identity and Access Management
• Elevate your Security with IAM Just-In-Time (JIT) Access