Cloud identity attack patterns in 2025 exposed lifecycle gaps

At a glance

What this is: This year-end analysis argues that cloud compromise in 2025 was driven by trusted identities, not broken perimeter controls, and that lifecycle governance is the missing security layer.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams must govern how identities behave after trust is granted, across human users, service accounts, OAuth grants, and automation paths.

By the numbers:

• The 2025 incidents show attackers using legitimate cloud identities, including IAM credentials, OAuth tokens, service accounts, and CI/CD identities, rather than breaking into cloud environments through traditional perimeter attacks.
• 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.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
• Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, making poorly scoped AI access 4.5x more likely to produce a security incident.

👉 Read Unosecur's year-end analysis of cloud identity attack patterns in 2025

Context

Cloud identity attacks are increasingly about using valid access after trust has already been granted. In this pattern, attackers do not need to defeat the login flow if they can reuse credentials, tokens, service accounts, or pipeline identities that the environment already accepts as normal. That is the core cloud identity governance problem this article surfaces for IAM, NHI, and lifecycle teams.

The article’s central claim is that 2025 incidents exposed a gap between authentication and governance. MFA, login portals, and perimeter checks can all succeed while attackers still operate inside trusted identities, so the real control boundary shifts to access scope, lifecycle state, and post-authentication behaviour. That starting position is typical for modern cloud environments, not exceptional.

For identity programmes, the implication is straightforward: access that remains valid, reusable, and over-scoped becomes attacker infrastructure. The relevant question is no longer whether an identity can log in, but whether it should still exist, still be trusted, and still be able to act in the first place.

Key questions

Q: What breaks when cloud identities are treated as if login security is enough?

A: When teams stop at authentication, they miss the malicious activity that happens after a valid login. A stolen key, abused token, or compromised service account can still enumerate resources, assume roles, and exfiltrate data while every preventive control appears to have worked. Runtime detection is what closes that gap.

Q: Why do static credentials create more risk than ephemeral access for cloud admins?

A: Static credentials create standing privilege, which means one leak can remain usable until someone finds and revokes it. Ephemeral access narrows that window and makes the issuance event, not the stored string, the governance object. That is why cloud admin access should be brokered and time-limited rather than managed as a durable secret.

Q: What do security teams get wrong about OAuth and connected apps?

A: Teams often assume a delegated app is safe because it was approved once, but approval is not the same as ongoing trust. OAuth grants can outlive the original need, inherit too much scope, or become a bridge into multiple SaaS tenants. Security teams should treat each grant as a revocable access path, not a permanent integration.

Q: Who is accountable when a service account or pipeline identity is misused?

A: Accountability sits with the team that granted and maintained the identity, not just the person who happened to trigger the incident. Service accounts, OAuth grants, and CI/CD identities need named owners, review cycles, and offboarding rules because they are operational identities with real business impact. Without that, no one can close the loop.

Technical breakdown

Static cloud credentials become direct cloud entry

Static cloud credentials include long-lived API keys, SSH keys, and hardcoded secrets that authenticate directly to cloud services without interactive login. In the article’s pattern, once those credentials are exposed, an attacker can call cloud APIs exactly as the original automation or workload would, which makes the activity look normal in logs. The problem is not password guessing or MFA bypass. It is that permanent credentials carry no natural expiry, and therefore no automatic pressure to re-evaluate trust, ownership, or scope.

Practical implication: treat every long-lived credential as a standing access path that must have explicit lifecycle and scope controls.

OAuth grants persist independently of user login state

OAuth access and refresh tokens are delegated credentials, not passwords. When a SaaS integration receives a standing grant, that grant can continue to function even after password resets, MFA changes, or user-session invalidation elsewhere in the stack. The article shows why this matters in cloud-connected environments: token reuse can preserve access to downstream systems long after the original user context has changed. That makes OAuth governance a separate identity problem, not just an authentication extension.

CI/CD and service identities often hold tier-0 cloud power

CI/CD pipelines, repository tokens, and service accounts often operate with broad authority because they are built to automate deployment and configuration. Once compromised, those identities can provision infrastructure, retrieve secrets, and assume higher roles without the usual human approval path. The article’s point is that cloud platforms already trust these actors, so their misuse blends into expected machine-to-machine behaviour. That means the control problem is privilege design, not just detection after the fact.

Practical implication: separate deployment authority from broad administrative reach and review pipeline privileges as part of identity governance.

Threat narrative

Attacker objective: The attacker objective is durable, low-noise access inside cloud environments using trusted identities that can operate without reauthentication.

1. Entry occurred when attackers obtained valid cloud credentials, OAuth grants, or pipeline identities from exposed repositories, compromised integrations, or poorly managed access paths.
2. Escalation happened when those identities were used to perform legitimate cloud API actions, assume privileged roles, and move across control-plane and downstream systems without triggering normal login alarms.
3. Impact followed through persistent cloud access, unauthorized configuration changes, secret access, data exposure, and privileged operations that blended into expected automation traffic.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Identity attack surface is now defined by trusted behaviour, not login failure. The article is right to separate successful authentication from safe access, because cloud incidents increasingly happen after trust is granted. That means traditional perimeter thinking misses the real control boundary, which is how identities behave once inside the environment. For IAM and NHI programmes, the practical conclusion is that usage governance must sit alongside authentication.

Static credentials created an identity blast radius that attackers could reuse at scale. Permanent API keys, hardcoded secrets, and long-lived service credentials turn automation into a durable access layer. Once those identities leak, the attacker inherits whatever privilege the automation was granted, often with no MFA challenge and no reauthentication checkpoint. The right takeaway is that static secret sprawl is not just a hygiene issue, it is an architecture choice that expands blast radius.

Lifecycle controls failed because access outlived the business relationship that justified it. This is the governance assumption that breaks in the article: access was treated as durable unless explicitly removed, even when the user, vendor, or workload no longer needed it. That assumption was designed for slower human-paced administration, but cloud identities and integrations move faster than recertification cycles. The implication is that lifecycle governance must become revocation-centric rather than review-centric.

Privilege exists in relationships as much as in roles. The article’s examples show that trust chaining, delegated permissions, and OAuth grants can create admin-like outcomes without an obvious admin role assignment. That complicates RBAC-only thinking and pushes governance toward relationship-aware control, where the identity graph matters as much as the permission matrix. Practitioners should treat hidden privilege paths as first-class access risk.

The most useful named concept here is identity blast radius. It is the amount of damage a trusted identity can cause before its misuse is detected or revoked. In cloud environments, blast radius is determined by credential lifetime, token persistence, trust chaining, and offboarding quality, not just role titles. Teams that measure only login security will miss the real exposure, while teams that govern blast radius can reduce the value of stolen trust immediately.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, which reinforces how quickly static governance models are becoming misaligned.
• Ultimate Guide to NHIs - Static vs Dynamic Secrets is the right next step for teams working through the lifecycle consequences of long-lived credentials.

What this signals

Identity blast radius should become a core programme metric for cloud and NHI teams. When 70% of organisations already grant AI systems more access than they would give a human employee performing the same job, the governance issue is no longer theoretical. Teams should measure how far a compromised identity can move before revocation, not just whether it can authenticate.

Cloud programmes now need explicit ownership for every durable trust path, including OAuth grants, pipeline identities, and service accounts. The control failure is not simply exposure, but the absence of a clean deprovisioning path when a workload, vendor, or employee relationship changes. That makes lifecycle tooling and access governance inseparable.

Practitioners should also align identity controls with the kind of access being granted, not just the platform where it runs. A human user, a service account, and an AI system may all hit the same cloud API, but the review cadence, revocation trigger, and acceptable blast radius are not the same. That distinction is now central to cloud identity governance.

For practitioners

• Map every standing cloud identity Inventory API keys, OAuth grants, service accounts, CI/CD identities, and integration tokens, then assign an owner, business purpose, and expiry expectation to each one.
• Convert static credentials into revocable lifecycle objects Replace permanent secrets with time-bound credentials where possible, and require revocation logic for identities that no longer have an active business relationship.
• Review delegated trust paths for hidden privilege Trace role chaining, SaaS grants, and pipeline permissions to find places where non-human identities can create administrative outcomes without explicit admin roles.
• Tie offboarding to technical deprovisioning Ensure employee exits, vendor changes, and workload retirement all trigger credential revocation, token invalidation, and access removal across cloud systems.
• Measure post-authentication behaviour instead of login events alone Correlate cloud API use, token reuse, and privilege changes after authentication so that misuse of trusted identities is visible even when sign-in itself looks normal.

Key takeaways

• 2025 cloud incidents showed that attackers increasingly operate through valid identities, so authentication alone no longer defines the security boundary.
• The scale of exposure is driven by standing credentials, persistent grants, and hidden trust chains that let misuse blend into ordinary cloud behaviour.
• Teams that want to reduce cloud identity risk must govern lifecycle, scope, and post-authentication behaviour, not only login events.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Standing Access: Standing access is persistent privilege that remains available without fresh approval or contextual checks. In NHI environments, standing access usually appears as long-lived tokens, reusable service accounts, or broad roles attached to automation. It is convenient operationally, but it expands risk when conditions change or secrets leak.
• Delegated Trust Path: A route into an environment created by an already-approved relationship such as OAuth, service account delegation, or API connectivity. These paths are attractive to attackers because they often inherit trust from the original configuration and can bypass direct user interaction.
• Post-Authentication Governance: Post-authentication governance is the control layer that manages access after an identity has already been verified. It covers entitlements, approvals, privilege changes and removal, and it is where many identity programmes fail because they stop at login assurance.

What's in the full article

Unosecur's full blog covers the incident patterns and cloud identity attack examples this post intentionally leaves at the analytical level:

• Eight pattern breakdowns showing how cloud identities, OAuth grants, and CI/CD access are abused in practice.
• Incident examples tied to DeepSeek AI, Tata Motors E-Dukaan, Salesloft / Drift, and AWS IAM Shadow Admin.
• The article's own framing of identity lifecycle failure, offboarding gaps, and post-authentication misuse.
• A forward view of how cloud identity attacks are likely to evolve as automation and federation expand.

👉 Unosecur's full blog covers the attack patterns, incident examples, and lifecycle failures in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity governance programme, it is worth exploring.