Cloud security in 2025: forgotten permissions and exposed secrets

At a glance

What this is: This cloud security report shows that overprivileged service accounts, exposed secrets, stale roles and permissive pipelines are still compounding into attack paths across enterprise environments.

Why it matters: IAM, PAM, NHI and cloud security teams need to treat identity scope, secret exposure and pipeline governance as linked control failures rather than isolated hygiene issues.

By the numbers:

• 93% of organizations have at least one overprivileged service account.
• 85% of organizations have plaintext secrets embedded in their source code repositories.
• 40% have GitHub Actions workflows configured to allow automatic pull request approvals.

Context

Cloud security in 2025 is no longer just a misconfiguration problem. It is an identity and lifecycle problem in which service accounts, roles, secrets and pipeline approvals keep outliving the work they were created for, which turns ordinary cloud operations into persistent access risk.

The report centres on a familiar governance gap: cloud programmes often provision access faster than they can prove, review and retire it. Once permissions become stale and secrets remain embedded in code, the attack surface stops being a set of isolated issues and becomes a connected control failure.

For IAM and NHI programmes, the key question is not whether cloud assets are protected by a single control, but whether identity scope, secret handling and delivery automation are governed as one system.

Key questions

Q: What breaks when hybrid-cloud service accounts are over-privileged?

A: Over-privileged hybrid-cloud service accounts let attackers reuse trusted access paths instead of escalating from scratch. That turns a compromised server into a bridge into cloud resources, expands blast radius, and makes lateral movement easier to hide. The risk is highest when sync, admin, and workload permissions are blended into one identity.

Q: Why do exposed secrets keep creating risk after they are detected?

A: Because detection does not stop a credential from remaining valid, and exposed values often persist in repositories, logs, backups, and configuration files. Risk remains until revocation, cleanup, and dependency removal are complete, which is why exposed secrets are really lifecycle failures rather than alerting failures.

Q: What are the signs that cloud IAM is failing to protect digital identities?

A: Common warning signs include inconsistent access policies across platforms, weak password practices, limited use of multifactor authentication, and poor visibility into who can reach critical resources. If teams cannot quickly review activity logs, verify permissions, or integrate new cloud services cleanly, the IAM program is likely becoming fragmented and less reliable.

Q: How should teams respond when pipeline approvals can be bypassed automatically?

A: They should treat approval bypass as an identity control problem, not just a developer workflow issue. If unreviewed changes can reach production, the pipeline can become a privilege escalation path for malicious code, dangerous infrastructure changes or secret exposure. The right response is to restore human or policy gates before trust boundaries are crossed.

Technical breakdown

Overprivileged service accounts and stale IAM roles

Service accounts are non-human identities that perform work on behalf of applications, workloads or platforms. In this report, the core problem is not simply that these identities exist, but that they accumulate permissions faster than teams retire them. A stale IAM role that has not been used in 90 days can still be abused if it remains valid, and a single permissive role attached to many instances creates a broad compromise path from one credential. Least privilege only works when entitlements are continuously pruned and ownership is clear.

Practical implication: tie entitlement review and offboarding to NHI lifecycle ownership, not to ad hoc infrastructure cleanup.

Exposed secrets in repositories and Git history

Plaintext secrets in source code are a lifecycle failure, not just a developer mistake. API keys, OAuth tokens and database credentials often enter repositories for testing or convenience, then persist in branches, commits and history long after the original use case is gone. Once a secret lands in Git history, deletion from the working tree does not remove the credential from every clone or cache. The real control objective is preventing durable secret exposure and revoking anything that has already escaped into version control.

Practical implication: combine secret scanning with automated revocation and history hygiene so exposed credentials do not remain valid.

Pipeline controls and attack-path amplification

The report shows how cloud risk compounds when infrastructure-as-code, CI/CD and approval workflows are permissive. Automatic pull request approvals can let unreviewed changes reach production, while misconfigured cross-account roles and public storage controls create direct routes to sensitive systems. Attack paths matter because they describe how separate weaknesses connect into a usable compromise chain. A weak control in the pipeline can amplify an identity or secret problem into production access at scale.

Practical implication: govern pipeline approvals, cross-account trust and public exposure as part of one attack-path reduction programme.

Threat narrative

Attacker objective: The attacker wants to turn forgotten permissions and exposed secrets into reliable access to cloud data, workloads and privileged control planes.

1. Entry begins when attackers find exposed plaintext secrets in repositories or inherit broad access through an overprivileged service account.
2. Credential access follows because stale IAM roles, embedded API keys and reused permissions remain valid long after the original operational need has passed.
3. Escalation and lateral movement occur when one permissive role or compromised secret opens multiple instances, accounts or connected cloud assets.
4. Impact lands in exposed data stores, compromised hosts or broader cloud takeover because attack paths were already present across identity and pipeline controls.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud security now behaves like an identity lifecycle problem: the report’s real message is that permissions, secrets and pipeline approvals are all forms of access that outlive their intended use. When service accounts remain overprivileged and roles stay active for months, cloud risk becomes a governance failure about ownership, review and retirement rather than a single technical defect. The practitioner conclusion is that cloud governance must track who or what still has power after the original need has gone.

Exposed secrets are only half the failure without revocation: the article shows how plaintext credentials in source repositories become durable exposure when teams do not remove validity as aggressively as they remove code. That makes secret leakage a lifecycle and revocation problem, not just a discovery problem. The practitioner conclusion is that detection without invalidation leaves the environment exposed long after remediation was supposed to happen.

Attack-path thinking is the right mental model for cloud IAM: the report demonstrates that overprivilege, stale access and public exposure are dangerous because they connect, not because they exist in isolation. A single role attached to many instances or a single permissive pipeline can convert a local issue into broad compromise. The practitioner conclusion is that programme metrics should measure how far an attacker can move, not just how many findings were found.

Cloud delivery pipelines have become identity enforcement points: automatic pull request approval, cross-account access without MFA or external IDs, and publicly readable storage are all governance choices about who can change what and when. That means pipeline design now sits inside the identity model, not beside it. The practitioner conclusion is that IAM, NHI and DevSecOps teams need shared accountability for change promotion, trust boundaries and secret handling.

Identity blast radius is the named concept cloud teams should adopt: the report is really about how much damage one credential, one role or one workflow can create once it is over-scoped or left active. In practical terms, blast radius is the better metric than raw inventory counts because it captures how permissions and secrets connect across environments. The practitioner conclusion is to evaluate cloud controls by containment potential, not by control count.

From our research library:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Identity blast radius is now the cloud control variable that matters most: teams should stop treating overprivileged accounts, stale roles and exposed secrets as separate hygiene findings and start measuring how quickly each issue can expand compromise across accounts and workloads. A single permissive role attached to many instances is not a minor misconfiguration, it is a containment failure.

Secrets scanning only becomes a governance control when it is paired with invalidation and ownership. If a plaintext credential can still be used after discovery, the environment has merely documented exposure rather than reduced risk.

For practitioners

• Map and shrink identity blast radius Inventory service accounts and IAM roles by actual use, then remove unused privilege and collapse roles that grant broad access to many instances or accounts.
• Automate secret revocation workflows Treat plaintext secrets in repositories as invalid the moment they are detected, and pair scanning with revocation so exposed credentials do not remain usable.
• Review pipeline approval gates Block automatic pull request approvals for infrastructure and application changes that can alter trust boundaries, permissions or public exposure.
• Reduce cross-account trust exposure Require explicit trust conditions for roles that cross account boundaries, and verify that MFA or external identity checks are enforced where the article shows they are missing.

Key takeaways

• The report shows that cloud security failures are increasingly driven by identity scope, secret persistence and permissive automation working together.
• Its evidence points to broad operational exposure, including overprivileged service accounts, long-lived roles and plaintext secrets that remain usable.
• The control lesson is to manage cloud access as a lifecycle problem, with ownership, review, revocation and approval boundaries aligned.

Key terms

• Overprivileged Service Account: A service account that has been granted more permissions than its workload needs. In cloud environments, this creates unnecessary blast radius because compromise of one non-human identity can expose multiple systems, data stores, or accounts through inherited or broad entitlements.
• Secrets Leakage: Secrets leakage is the exposure of credentials such as API keys, tokens, or certificates in places where they can be discovered and reused. The risk is not just disclosure, but unauthorized authentication that turns a coding or pipeline mistake into active access.
• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.

Deepen your knowledge

NHI governance, secrets management, and workload 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 programme, it is worth exploring.