Four Eras of Cloud Security. Same Verb.

✓ Human-authored analysis; AI used for formatting and proofreading.

Scott Piper published a twenty-year retrospective on cloud security research in March 2026. It's the most useful structural history of the field I've seen — four eras, each with defining milestones, each with the tools and research that shaped cloud security. If you work in cloud security, read it first.

What follows is a question about what the history reveals when you examine one detail it doesn't discuss.

Piper divides two decades into four eras:

2006–2016, Foundational. Cloud providers built the security primitives — IAM (2011), CloudTrail (2013), Organizations and SCPs (2016). Before these existed, there was no mechanism for least privilege, no audit trail, and no organizational boundary. Security research in this era was part-time work from people with broader careers.

2016–2021, CSPM. Cloud security became a full-time job. CIS Benchmarks standardized what to check. Open-source tools proliferated — Prowler, CloudMapper, Pacu, Cloud Custodian, ScoutSuite. Cloud security during this time largely meant deploying a CSPM.

2021–2025, CNAPP. Point solutions gave way to platforms. Vendors integrated CSPM with container scanning, vulnerability management, and workload protection into a single product category. Research teams at vendors began finding cross-tenant vulnerabilities in the cloud providers themselves.

2025–present, AI. AI accelerates both attack and defense. Exploits that required deep language expertise are generated in minutes. A CTF challenge was solved by an AI within minutes of release. The industry is speed-running the cloud eras.

This is a well-evidenced narrative. Every era is defined by a change in what tools could do and who was building them.

Look at what each era's defining tools do. The direct action each tool performs on its direct object.

In the CSPM era, the defining tools match API responses against rule databases. Prowler, ScoutSuite and Cloud Custodian matches. The CIS Benchmark is a rule database. The verb is match, and the output is a finding.

In the CNAPP era, the defining tools aggregate findings from multiple scanners into a single platform. The CNAPP collects what the CSPM found, what the vulnerability scanner found, what the container scanner found, and deduplicates. The verb is aggregate, and the output is a consolidated finding.

In the AI era, the defining tools score events against learned baselines, or exploit vulnerabilities faster. The verb is score or exploit, and the output is a detection or a proof-of-concept.

Three eras of tooling. Three different verbs. But the output is always the same category: signals. A finding for human interpretation. An alert for human triage. A score for human thresholding. A detection for human review.

No era introduced a tool whose output is a decision. A deterministic, machine-verifiable, per-asset verdict that a pipeline can act on without human interpretation.

A finding says: "this S3 bucket lacks versioning." A human must decide whether that matters, whether it's a true positive, and what to do about it.

A verdict says: "this configuration is COMPLIANT or NON_COMPLIANT with respect to this control, and here is the evaluation trace." A machine reads the exit code and gates the pipeline. No interpretation, triage or threshold is required from a human.

A CSPM finding can be accurate. The difference is in what happens next. A signal enters a queue. A verdict enters a pipeline. Signals require human interpretation as a necessary step between detection and action. Verdicts are the action.

Every era improved signals. CSPMs made signals more comprehensive. CNAPPs made signals more consolidated. AI makes signals faster. But improving a signal doesn't change it. A faster finding is still a finding. A better-correlated alert is still an alert. A higher-accuracy score is still a score.

Piper's history is comprehensive within its scope. The omission is structural. Deterministic verification tools don't appear in the history because they don't appear in the field. The category doesn't exist.

The cloud security industry has produced hundreds of tools across four eras. Billions of dollars of venture capital. Thousands of dedicated security engineers. Every tool produces signals.

The question is: is this because signals are sufficient, or because the architecture of every tool category makes decisions structurally impossible?

A CSPM queries the live cloud API, matches the response against a rule, and produces a finding. The finding is a signal because the CSPM evaluates one resource at a time. It can say "this bucket lacks versioning" but cannot say "this bucket is the destination for your CloudTrail trail, and this role has permission to delete it, and no SCP blocks cross-account writes, and therefore a complete attack path exists." The compound judgment requires evaluating relationships between resources, not properties of individual resources.

A CNAPP inherits this limitation. It aggregates findings from CSPMs and scanners, but aggregation doesn't create compound reasoning. It creates compound noise. More findings from more scanners, consolidated into one dashboard, still evaluated one resource at a time.

An AI-powered tool can reason across resources in principle, but introduces a different problem: non-determinism. The same input can produce different outputs across runs. For a security tool whose findings may be presented to auditors, regulators, or courts, the finding must be reproducible. A probabilistic verdict is a contradiction in terms.

The architectural gap is specific: no tool category evaluates the configuration graph (relationships between resources, not just properties of resources) deterministically (same input, same output, every time) from a coherent snapshot (point-in-time capture, not a stream of events).

The history has four eras of verbs: match, aggregate, score, exploit. The missing verb is evaluate — produce a deterministic categorical verdict per asset by applying an enumerated catalog of controls to a snapshot of cloud state.

The distinction is operational:

A tool that matches takes an API response and a rule, and outputs a finding. The finding enters a triage queue.

A tool that evaluates takes a configuration snapshot and a control catalog, and outputs a verdict. The verdict enters a pipeline as an exit code.

The input is different (snapshot vs API response). The substrate is different (enumerated catalog vs rule database). The output is different (verdict vs finding). The downstream consumer is different (pipeline vs human).

This is a different primary function that produces a different output type. In the same way that CNAPP was not a better CSPM but a platform that aggregated them, the missing tool is not a better version of any existing category. It occupies a structural gap in what the toolchain produces.

The sharpest illustration of the gap is compound risk. Consider a specific scenario documented by Unit 42 in June 2026: an attacker who can delete an S3 bucket that serves as a CloudTrail destination can recreate the bucket under their own account, silently rerouting security telemetry to attacker-controlled storage. No credentials stolen or network exploitation. Pure configuration-graph exploitation.

Detecting this from individual resource properties is impossible. The bucket's own properties are fine. The IAM role's own properties are fine. The CloudTrail trail's own properties are fine. The vulnerability exists only in the relationship between them. The fact that the role can delete the bucket, the trail depends on the bucket, and no organizational policy prevents cross-account writes.

A CSPM checking each resource individually sees three compliant resources. A CNAPP aggregating those three findings sees three compliant resources. Neither can see the graph. The compound chain — identity → permission → destination → trail → missing data perimeter is invisible to any tool that evaluates nodes without evaluating edges.

This is not a coverage gap (add more rules). It's an architectural gap. The tool's primary function cannot express the finding. The missing verb — evaluate a snapshot against a catalog — operates on the graph, not on individual resources. The compound chain is a natural output of graph evaluation, and a structural impossibility for resource-level matching.

Piper frames the AI era around speed: faster exploits, faster patching, faster detection. AI solved a CTF in minutes. AI generated an exploit in 10 minutes. The implicit thesis: the bottleneck is speed, and AI removes it.

But if the output type hasn't changed, if AI produces faster signals rather than different outputs, then the bottleneck isn't speed. It's the gap between signals and decisions. A faster finding still enters a triage queue. A faster alert still requires human interpretation. A faster score still needs a threshold.

AI applied to the existing toolchain makes each verb faster. AI-powered matching. AI-powered aggregation. AI-powered scoring. The verbs stay the same. The output stays the same. The signals arrive faster, in greater volume, with higher confidence and still require a human to close the loop.

The alternative is not AI replacing the human. It's changing the output type so the loop doesn't need closing. A deterministic verdict, mechanically evaluated, same answer every time, with an auditable evaluation trace. That's a tool whose output a pipeline can act on directly, at any speed, because the human isn't in the loop between detection and action.

That's not the AI era's contribution. That's the contribution of a different verb.

Piper's history is a four-column table. Each column is an era. Each era has tools, verbs, and outputs. Adding a fifth column doesn't extend the table. It changes what the table measures:

The first four columns improve along the same axis: better, more, faster signals. The fifth column is orthogonal. It doesn't make signals better. It produces a different output type.

The history doesn't mention this column because nobody has built it. The field went from matching to aggregating to scoring without ever stopping to ask: what if the output wasn't a signal?

When you remove humans in the loop where they are slow and the weakest link in the system, they move to a different loop where the expert judgement is encoded in controls that can be evaluated at machine speed without slowing down the Agentic era development loop. Slow and deliberate when human expertise is required. Fast and accurate when agents are required. Two different loops that serve diffferent purpose.

That question is answered by Stave. The verb is evaluate. The input is a configuration snapshot. The output is a deterministic per-asset verdict with an auditable evaluation trace. The compound chain in the Unit 42 example — identity with delete permission on a CloudTrail destination bucket, no SCP data perimeter — is a finding Stave produces and no signal-producing tool structurally can. Twenty years of cloud security built the signal infrastructure. The decision layer was never built. stave apply --observations ./your-snapshot/