Notifications
Clear all
Topic starter
17/08/2026 5:40 pm
TL;DR: 2025 cloud incidents showed that attackers now rely on valid IAM credentials, OAuth tokens, service accounts, and CI/CD identities to move through trusted paths, according to Unosecur’s year-end analysis. The governing problem is no longer login security alone, but whether identity lifecycle controls can constrain post-authentication misuse across human and non-human access.
NHIMG editorial — based on content published by Unosecur: 2025 Year-End Cloud Identity Attack Case Study
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Unosecur's year-end analysis of cloud identity attack patterns in 2025 →
Cloud identity attack patterns in 2025: what changed for teams?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 5:40 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Cloud identity attack patterns in 2025 exposed lifecycle gaps
