✓ Human-authored analysis; AI used for formatting and proofreading.
A cloud account with 1,000 resources, each with 10 configurable attributes, has roughly 10^1,000 possible configuration states. More states than atoms in the observable universe by a factor of 10^920.
Prediction-based security asks: "which of these 10^1,000 states are safe and which are unsafe?" Then classifies each observed state against the model.
That question is mathematically not answerable. The state space is too large to enumerate, sample representatively and model. No ML system can learn it. No rule engine can traverse it. No human can reason about it.
There's a different question that can be answered: "which PATTERNS of state must never exist?"
The pattern count isn't 10^1,000. It's hundreds to thousands. A pattern like "no S3 bucket shall be publicly readable" covers an INFINITE number of specific forbidden states using a SINGLE statement. The pattern set grows linearly with the catalog. The state space grows exponentially with the cloud.
The first question is prediction. The second is elimination. The entire cloud security industry invested in prediction. The mathematics says only elimination works at scale.
Two modes of reasoning
| Mode | Question | How it scales |
|---|---|---|
| Prediction | What COULD happen? Classify each possibility. | Exponential in state space — intractable |
| Elimination | What must NEVER happen? Check current state against forbidden patterns. | Linear in pattern count — tractable |
The two modes have different computational properties:
| Property | Prediction | Elimination |
|---|---|---|
| Setup | Enumerate possible states (infeasible) | Enumerate forbidden patterns (feasible) |
| Per-evaluation | Search through possible states | Apply patterns to current state |
| Complexity | Exponential | Polynomial |
| Failure mode | Misses novel states outside training distribution | Misses forbidden patterns not yet cataloged |
| Output | Probability ("78% likely unsafe") | Category ("COMPLIANT or NON_COMPLIANT") |
Prediction has BOTH infeasible setup AND infeasible evaluation. Elimination has BOTH feasible setup AND feasible evaluation. The difference is categorical. One works at cloud scale. The other mathematically cannot.
Why prediction-based tools fail at scale
Most cloud security tools implicitly operate in prediction mode:
| Tool | Prediction behavior | Why it fails at scale |
|---|---|---|
| ML anomaly detection | Models "normal" behavior; predicts deviations | Training distribution doesn't match production; novel states escape |
| Threat intel correlation | Predicts which patterns indicate attack | New patterns aren't in intel feeds; always behind |
| Behavioral baselines | Models expected behavior; flags anomalies | "Normal" changes faster than baselines update |
| Risk scoring | Predicts which findings are critical | Severity rankings don't match business risk |
| Attack-path analysis | Predicts paths attackers might take | Real attackers find paths the model didn't anticipate |
Each tool's value depends on PREDICTION ACCURACY. The accuracy depends on COVERAGE of the possible-state space. The coverage is STRUCTURALLY BOUNDED by combinatorial explosion.
The failure modes are INTRINSIC to prediction-mode reasoning:
ML drift: Training distribution ≠ production (always, by construction)
Threat intel lag: New patterns arrive after exploitation (always, by definition)
Baseline obsolescence: "Normal" evolves faster than baselines (always, in dynamic systems)
Score miscalibration: Severity ≠ business impact (always, without business context)
Path incompleteness: Real attackers find unmodeled paths (always, in complex systems)
Each failure is a CONSEQUENCE of attempting to predict in a space too large to traverse. Making the tools smarter or faster doesn't overcome the combinatorial barrier. The barrier is mathematical, not engineering.
How elimination scales
Elimination scales because of four properties:
1. Forbidden patterns are sparse
Cloud systems have MANY possible states but only SOME are unsafe. The unsafe set is a small fraction. An invariant like "no public bucket" eliminates a specific PATTERN — not a specific state. The pattern covers ALL states where ANY bucket has public_read=true, regardless of every other attribute.
One pattern. Infinite specific forbidden states covered.
2. Patterns generalize
"No S3 bucket may be publicly readable" covers:
→ All current S3 buckets in the account
→ All future S3 buckets (not yet created)
→ Buckets in every region
→ Buckets with any other attribute combination
→ Buckets regardless of who created them or when
One statement. Universal coverage for that pattern. No ML model achieves this generalization because ML models learn from SPECIFIC EXAMPLES, not from UNIVERSAL PATTERNS. The pattern's explicitness makes generalization work.
3. Evaluation is local
Checking whether a specific asset matches a forbidden pattern doesn't require knowing the rest of the state space. The check is LOCAL to the asset being evaluated:
For each asset in snapshot:
For each control in catalog:
Does this asset match this forbidden pattern?
Yes → mark violation
No → continue
Complexity: O(assets × controls)
NOT: O(possible-states) ← which would be O(10^1000)
The evaluation parallelizes well, produces interpretable per-asset results, and doesn't require re-evaluating old assets when new ones are added.
4. Patterns compose
Multiple patterns apply to the same state. The verdict is the CONJUNCTION: if pattern A holds AND pattern B holds AND pattern C holds → all three safety properties are satisfied. The composition is straightforward and formally sound (Alpern-Schneider: safety properties compose by conjunction).
Prediction-mode tools DON'T compose this easily. Two ML models' predictions can conflict. Two risk scores can disagree. Two behavioral baselines can contradict. The composition problem is unsolved in prediction mode and trivially solved in elimination mode.
The type-system analogy
The elimination approach has a precise analogy in programming languages: TYPE SYSTEMS.
A type system doesn't predict which programs will crash. It ELIMINATES a CLASS of programs, those that don't typecheck. The ill-typed programs are FORBIDDEN. They don't exist as valid programs.
Type system: "This function requires an integer. You passed a string. REJECTED."
Invariant system: "This bucket requires private access. You configured public. REJECTED."
Both are ELIMINATION reasoning. Both catch CLASSES of errors, not specific instances. Both operate at the STRUCTURAL level, not the behavioral level.
The type-system revolution in programming caught classes of bugs that runtime checks couldn't such as null pointer dereferences, type mismatches, uninitialized variables. The invariant system catches classes of misconfigurations that runtime monitoring can't such as public resources, overpermissive roles, expired credentials, toxic combinations.
The parallel is structural:
| Property | Type system | Invariant system |
|---|---|---|
| What it eliminates | Ill-typed programs | Unsafe cloud states |
| How it specifies | Type declarations | Catalog entries (CEL predicates) |
| When it checks | Compile time | Pre-deployment + periodic evaluation |
| What passes | Programs that typecheck | States that satisfy all invariants |
| What's rejected | Programs that don't typecheck | States that violate any invariant |
| Failure mode | Overly restrictive types → valid programs rejected | Overly restrictive invariants → valid configs rejected |
The theoretical foundations are mature
Elimination-mode reasoning has deep foundations across multiple engineering disciplines:
| Discipline | Elimination mechanism | Maturity |
|---|---|---|
| Formal methods | Specifications as constraints verified by model checkers | 40+ years |
| Type systems | Forbidden programs eliminated at compile time | 50+ years |
| Database integrity | Constraints as forbidden states (CHECK, FOREIGN KEY) | 40+ years |
| Hardware verification | Safety properties verified by SMT solvers | 30+ years |
| Control theory | Safety regions defined; controller prevents departure | 70+ years |
| Cloud security | ??? | Least mature |
Every other engineering discipline adopted elimination-mode reasoning decades ago. Cloud security is the LAST major discipline to make the move. The theory exists. The engineering patterns exist. The tools exist (SMT solvers, model checkers, constraint engines). The application to cloud security is the missing step.
The practical-theoretical synthesis
Pure elimination (theoretical only) produces specifications nobody implements. Pure prediction (practical only) produces tools that fail at scale. The system that works operates in the INTERSECTION:
Pure theoretical: Formal specifications → nobody implements them
Pure practical: ML/behavioral tools → fail at combinatorial scale
Intersection: Formally specified invariants evaluated against cloud state
The intersection means:
Practically anchored. Every catalog control corresponds to a REAL misconfiguration pattern observed in the field. The catalog is empirically driven. Each control exists because someone observed a real breach or misconfiguration it would catch.
Theoretically disciplined. Every catalog control is a PRECISE specification, not a probabilistic detector. The control either fires or doesn't. The evaluation is deterministic. The verdict is categorical.
The practical anchoring ensures RELEVANCE (the catalog forbids states that cause breaches). The theoretical discipline ensures COVERAGE CLARITY (the catalog names categories, not just instances — "any public storage" covers both observed and not-yet-observed instances of the pattern).
What elimination doesn't cover
Novel attacks. New attack patterns require new forbidden states. The catalog must keep pace with attacker innovation. Until a new pattern is cataloged, elimination can't catch it. This is the same limitation type systems have: they catch known bug classes but not logic errors.
Probabilistic safety. Some safety concerns are genuinely probabilistic such as anomaly detection of UNKNOWN patterns, user-behavior analytics, zero-day detection. These don't reduce to elimination. They remain in prediction territory.
Context-dependent states. "Public S3 bucket" is forbidden in most contexts but ALLOWED for specific public-asset hosting. Elimination handles this via profile-based catalog selection, but the context-dependence adds catalog complexity.
The bounded claim: elimination covers the CATALOG-COVERABLE subset of cloud security where 95%+ of misconfiguration breaches live. The remaining 5% (novel attacks, genuinely probabilistic threats) still needs prediction-mode tools. The two approaches are complementary.
The investment question
The cloud security industry's investment is overwhelmingly in prediction:
PREDICTION INVESTMENT (current): ELIMINATION INVESTMENT (needed):
ML model training Catalog authoring
Threat intelligence feeds Pattern discovery
Behavioral baseline tuning Catalog review and testing
Severity score calibration Invariant design
Attack-path simulation Catalog coverage expansion
The investment is categorically misaligned with the problem's mathematical structure. Prediction investment hits diminishing returns because the combinatorial barrier is STRUCTURAL. Elimination investment has INCREASING returns because each new pattern covers an infinite class of specific states.
Should we stop investing in prediction? Some prediction capability is valuable for the genuinely novel. The question is: "should 90% of our investment go to prediction when elimination covers 95%+ of the problem more effectively?"
For founders: prediction vs elimination checklist
Test your system against the distinction:
1. Does your system enumerate POSSIBLE states or FORBIDDEN states? If possible → prediction mode (combinatorial barrier). If forbidden → elimination mode (tractable).
2. Is your output PROBABILISTIC or CATEGORICAL? If probability → prediction. If binary/categorical → elimination. Categorical outputs drive pipeline action without interpretation.
3. Does adding cloud complexity INCREASE or NOT AFFECT your evaluation cost? If increase → prediction (evaluation cost grows with state space). If not affected → elimination (evaluation cost depends on catalog size, not cloud size).
4. Does one specification cover MANY specific states? If yes → elimination (pattern generalization). If no → prediction (instance-by-instance classification).
5. Do your evaluations COMPOSE formally? If two evaluations' results combine cleanly (conjunction) → elimination. If they conflict or require reconciliation → prediction.
Your cloud has 10^1,000 possible states. Prediction tries to classify them. Elimination defines the forbidden patterns and checks current state against them. One is mathematically impossible at scale. The other is linear in catalog size. The mathematics isn't a suggestion.
Elimination-mode reasoning — 3,000+ forbidden-pattern controls evaluated against air-gapped snapshots via CEL predicates. Linear in catalog size, not exponential in state space. Each pattern covers infinite specific states. Categorical verdicts, not probabilities. Standardized facts (JSONL, SMT-LIB) exported for external reasoning engines. Stave, an open-source risk reasoning engine. Define the forbidden. Eliminate it. Try it: bash examples/demo-ai-security/run.sh
Top comments (0)