As Cybersecurity Awareness month comes to a close the final part of our three part series, What Cloud Incidents Are Actually Telling Us, covers what cloud threats actually look like today, why they keep slipping past mature programs, and what security teams can do differently.
The Other Side of the Attack Surface
In the first two parts of our series on cloud incidents, we covered the current threat landscape by numbers, and looked at the four principal cloud threat types and what they mean in today’s enterprise environments. Now, in the final instalment of our series, we turn to a pressing question: Why do these gaps persist, and what can we do about it?
Part of the issue is that no single team owns the full attack surface. Cloud environments are built and operated by multiple teams with distinct mandates. Platform teams own landing zones. Security teams own policies and monitoring. Application teams own pipelines and service accounts. DevOps owns CI/CD infrastructure. Each team manages its segment competently. No team owns the full attack scenario. This is not a criticism of any individual team, it’s a structural property of how large organizations operate cloud infrastructure.
The consequence: controls exist in each domain, but the gap between domains, where a pipeline credential bridges the development environment and production infrastructure, or where a service account bridges an application layer and the management plane, is where attackers operate. In 34% of the intrusions Mandiant handled in 2024, investigators could not determine how attackers gained their initial foothold, not because of attacker sophistication, but because, as Mandiant notes, it points to potential deficiencies in enterprise logging and detection capabilities across organizational boundaries.
The shared responsibility model doesn’t map to operational accountability. The cloud shared responsibility model is a legal and contractual framework. It defines who is liable in principle. What it doesn’t define is operational accountability in practice, and that’s a harder problem than it sounds. Knowing that a customer is “responsible for security in the cloud” doesn’t tell you which named person monitors a specific log source, who would notice if a non-human identity started behaving anomalously, or how quickly that signal would reach someone able to act on it. The model answers a legal question; the organizations using it still have to answer the operational one themselves, and most haven’t built the internal structure to do so.
The Microsoft Storm-0558 case of 2023 demonstrates this gap at its most stark. Chinese state-sponsored actors accessed email accounts at approximately 25 organizations over roughly a month in 2023, downloading an estimated 60,000 emails from the US State Department alone. Detection depended on a log source — the MailItemsAccessed event type — that was available only to customers with Microsoft’s highest-tier Purview Audit Premium license at the time. Organizations without that license had no visibility into the compromise regardless of their security maturity or operational practices.
Cost pressure degrades telemetry at exactly the wrong moment. Cloud telemetry is expensive. Ingestion, storage, and processing costs are material line items. When budgets tighten, the response is typically to reduce log retention periods, filter “low-priority” event categories, or deprioritize governance of identities that aren’t on the critical path for current projects. These decisions are usually made at the infrastructure or finance layer, often with good reason in isolation. They rarely reach security teams with enough context to assess the detection impact. The result: detection rules written against a complete telemetry model, the telemetry model trimmed elsewhere, and no one connecting the two decisions until an incident makes the gap visible.
What Is Required in Practice
The structural reasons above aren’t unsolvable. They’re organizational and architectural problems with specific responses. What follows maps directly to each gap identified: governance of non-human identity (including AI agents), ownership of the CI/CD credential surface, behavioral visibility for cloud-native activity, and recovery architecture that survives control-plane compromise.
- Redefine what counts as a crown jewel. Most asset classification frameworks focus on data and applications. In cloud environments, the assets that most warrant protection are control planes, trust anchors, and recovery levers, the IAM management layer, the CI/CD secrets store, the backup management interface, the cloud provider’s root credentials. An attacker with access to any of these doesn’t just reach one asset; they can reach everything the control plane governs.
- Treat non-human identity governance as a program, not a project, and include AI agents in scope from day one. This means discovery, ownership, permissions hygiene (with particular attention to the small fraction of NHIs that control the majority of cloud permissions, and to agent identities whose permission scope was set broad “to be safe”), and rotation, enforced with automated alerts.
- Build detection around attacker workflows, not compliance requirements. The ATT&CK techniques most commonly observed in cloud incidents — credential abuse, living-off-the-land execution via cloud APIs, CI/CD pipeline manipulation, lateral movement through trust relationships are precisely the techniques with the lowest detection coverage in most SIEMs. CardinalOps’ 2025 analysis found that enterprise SIEMs detect only 21% of ATT&CK techniques even though the telemetry they ingest could support coverage of more than 90% on average.
- Invest in behavioral baselines for cloud-native activity, and close the agent-visibility gap where it’s achievable. Where compute is self-managed (containers and VMs in particular) deploying container-aware EDR/CWPP agents is a concrete step worth prioritizing and actively investigating, not assuming is already covered by endpoint EDR. Where compute is fully managed, the equivalent investment is API- and audit-log-level behavioral monitoring.
- Architect recovery infrastructure outside the blast radius, and budget for it explicitly. Effective ransomware resilience in cloud environments requires immutable backup storage with access patterns that don’t depend on the primary identity plane. This costs more than a shared-account configuration, and that cost should be presented to budget owners as a named trade-off rather than absorbed silently.
- Define telemetry ownership as an operational security requirement. The question “who would know within an acceptable window if this identity behaved anomalously?” should have a named, accountable answer for every highly privileged identity in the environment, whether that’s human, non-human, or agentic.
Threat versus Action Matrix
| Cloud Threat Type (2026) | Root Cause / Structural Gap | Core Security Action Required |
| 1. Identity & Credentials (human, machine, and AI agent) | NHIs significantly outnumber humans; a small fraction control most permissions; agent permissions often broader than guardrails assume | Implement strict NHI discovery, lifecycle ownership, and automated rotation — agents included |
| 2. CI/CD & Supply Chain | Production-level credentials sitting in pipelines no single team fully owns | Treat pipelines as crown jewels; map every token and enforce OIDC |
| 3. Living Off the Land | Attackers use legitimate APIs; EDR often isn’t present on ephemeral/managed compute; detection rules cover only 21% of techniques | Deploy container-aware EDR where compute is self-managed; build behavior baselines for native cloud tools where it isn’t |
| 4. Backup Targeting | Backup infrastructure shares the same IAM trust fabric as production; proper isolation costs more | Architect recovery outside the primary blast radius (air-gapped/isolated IAM), and budget for it explicitly |
Bringing it All Together for True Cloud Security in 2026 and Beyond
Cloud threats in 2026 don’t primarily defeat mature security programs through technical sophistication. They defeat them through structural gaps: identities that are human, machine, and now agentic, and that no team fully owns, pipelines that carry production-level credentials with no governance, shared responsibility frameworks that define liability without defining operational accountability, and telemetry decisions that quietly remove the visibility detection programs depend on.
The uncomfortable conclusion is this: there is a version of cloud security that passes audits, satisfies compliance frameworks, and still falls short in practice, not because the tools are wrong, but because the organizational structure creates blind spots at exactly the points where attackers have learned to operate. That’s not a verdict on any one team’s effort; it’s a description of how fast the surface has moved.
The question for security teams and CISOs is not “Is our cloud environment secure?” It is “Does our security program reflect how cloud environments are actually attacked today?” For most organizations, the answer requires honest examination of three things: who owns the non-human and agentic identities, who owns the pipeline credentials, and who would actually know, with evidence, within an acceptable timeframe, if any of them behaved in a way they shouldn’t.
Interested in putting you specific organizational context into the conversation? Reach out to speak to one of our experts.
