Cloud Security Tool Does Not Have to Guess.

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

Two tools, same alert, opposite reasons

A scanner flags your S3 bucket as public. It might be a data leak. It might be your CDN serving logo.png as designed. The configuration is identical in both cases. The intent is opposite. Just looking at the configuration does not tell you about the purpose.

This is the problem of cloud security posture. Almost every tool handles it the same way by guessing. They call the guess different things (ML, anomaly detection, "AI-powered intent analysis"). But it's the same move: infer what you probably meant from what the config happens to look like. That guess is an approximation by construction. It produces false positives that causes team fatigue and false negatives that miss your breaches.

Inference is the lower form of knowledge

Two ways a system can know your intent:

• Inference — reconstruct your intent from shadows: file names, traffic patterns, access logs. "This bucket has images in it, so it's probably for marketing." A guess, however sophisticated.
• Declaration — you state it. "This bucket hosts public marketing assets." Ground truth, because you defined the truth.

Inference is always the weaker form. If declaration beats inference, why does the whole industry infer?

Three reasons and they're the objections to any declare-first tool:

1. Humans make mistakes. You intend "internal only" and type 0.0.0.0/0.
2. Humans don't scale. Nobody hand-annotates 50,000 permissions.
3. Nobody sees the whole picture. Three admins each make a reasonable local choice and accidentally compose an internet-to-database path no single person intended.

The industry's answer to these three is "so let the machine guess." That's the wrong answer. Because there's a fourth option that gets the truth-value of declaration and the scale of automation.

Deterministic evaluation is not inference

There are two kinds of "machine analysis," and they are different:

• Probabilistic inference — ML, anomaly scores, "87% likely malicious." A statistical guess. An approximation.
• Deterministic evaluation — a rule, a predicate, a proof. It says exactly what it says, every time, traceable to the input. Not a guess or an approximation.

A tool that declares intent and then deterministically checks configuration against that declaration is in the second camp. It never guesses what you meant — you told it. It only computes whether your config honors what you said.

It is like a compiler for cloud intent. You write the spec; the engine checks your infrastructure against it and tells you precisely where reality and declaration diverge. Stave, the open-source tool I work on, is built on this model. CEL predicates over config snapshots, no ML in the verdict path.

Now watch the three objections dissolve:

The typo (objection #1). You declared "internal only"; the config says 0.0.0.0/0. Catching that contradiction isn't inferring your intent. You stated your intent, and the config violates it. That's a syntax check against a semantic requirement. A compiler catching a type error isn't guessing what you meant. It's holding you to what you declared. The machine's verdict is superior to your typo because it has no opinion of its own. It just enforces yours.

The hidden path (objection #3). Can user A reach database B through a chain of interconnected resources? That is not a probability. It is a graph traversal. A mathematical fact about the configuration you provided. A node-by-node scanner can't see it because the risk lives in the edges, not any single resource. Deterministic path analysis over the whole graph can see the risk. The path exists in your configuration is a claim you can prove.

You prove the path exists in the snapshot you were given. That's a proof about an artifact. It beats probabilistic scanning. But it's a proof about a frozen state, not a guarantee about the live environment this instant, and reachability isn't the same as exploitability. There may be controls the snapshot doesn't capture. The precise claim: "we deterministically prove this path exists in your config" is unassailable. The inflated version: "we prove you're breachable" invites a dozen caveats.

The compiler is only as honest as its spec

Garbage spec in, garbage verdict out. A real compiler checks against a fixed, externally-defined language standard. A cloud-intent compiler checks against a spec you wrote. So a wrong declaration produces a confidently compiled wrong result. Determinism guarantees consistency with what you declared. It does not guarantee your declaration was right.

The model needs two things most spec-first tools skip. Skipping them is the reason formal-verification tools died.

Weakness 1: Drift — the confident false negative

This is the silent killer. You declare "this is a test server" on Day 1. On Day 200 it's holding production PII, but the spec still says "test," so the engine says green. A confident green over a now-dangerous resource is worse than a false positive. It's a false negative wearing the authority of a clear verdict, with a human's name on the approval.

The fix is to treat intent as a contract, not a label:

• Contextual invariants. "Test server" isn't a string. It's a set of constraints (small instance class, no Elastic IP, not on the production VPC CIDR). If the resource drifts out of those constraints, the contract is breached — deterministically, not by an AI noticing something looks off.
• An attestation loop. Generalize TTLs to intent itself. When a declaration goes stale, the finding isn't secure and isn't breach — it's "unverified intent." That routes the resource back to a human to re-affirm or retire. A declaration nobody has reaffirmed against current state is itself a finding.

Weakness 2: Cold start — useless on Day 1

A CISO buys a tool to reduce 5,000 alerts. A tool that replaces them with 5,000 "intent missing" warnings gets uninstalled quickly. A declare-first system that demands declarations up front has no Day-1 value. That's the most common way these tools fail.

The fix is progressive disclosure of intent:

• Ship a sane baseline. Don't start from a blank slate. Start from reasonable defaults — "assume buckets are private and databases internal-only unless declared otherwise". So the tool delivers value on run one by flagging contradictions to reasonable intent.
• Snapshot-to-spec, then bless. On first run, show the user their current reality and let them codify it as the baseline. You are not inferring that their mess is correct. You're asking them to consciously declare "this is my starting point," which makes every future drift deterministically detectable. You move them from unknown to known-and-stable in one step.

Hybrid, not either/or

It is not deterministic instead of ML. It's a ratchet. Let inference do what it's good at — suggesting candidate intent on Day 1 so the tool isn't blank. But a suggestion is never a verdict. A human reviews each inferred intent and either confirms or corrects it, and the confirmed intent becomes a declared spec the deterministic engine enforces forever after.

That's a one-way ratchet: every approval permanently moves one resource from guessed to known, and known intent never regresses to guessing. The probabilistic layer is allowed to propose. Only declared intent is allowed to decide. The moment you let an unconfirmed guess flow into a verdict unlabeled, you've rebuilt the approximation engine you set out to replace. So provenance has to be first-class. Every verdict traces to either a deterministic rule or a named human's recorded approval, and a verdict resting on an unverified assumption must say so.

Over time, more intent gets formalized, the deterministic core covers more ground, and the probabilistic tooling does less work — used only where it's needed. Costs fall. But the win is that the system's confidence in its own verdicts only increases, with an auditable human-decision trail behind each one.

Boundary

This model displaces configuration-posture scanning — "does this config violate a stated invariant." It does not replace runtime behavioral detection such as the credential-theft login that violates no config rule, the living-off-the-land attacker mimicking a legitimate user. Those are a different risk class, and a fully-formalized intent engine still wouldn't catch them. Anyone claiming "deterministic beats ML everywhere" is overclaiming. The defensible claim is narrower and still strong:

For the posture question — does your cloud do exactly what you said it should, and nothing else? — deterministic evaluation against declared intent beats probabilistic inference. It doesn't guess and tire you with false positives. It doesn't guess and miss your breaches. It computes, provably, where your reality and your intent diverge.

That's not a better scanner. It's a different category: a compiler for cloud intent. It is honest about its spec, hardened against drift, useful on Day 1, and getting more trustworthy every time a human says "yes, that's what I meant."

---

Stave is an open-source implementation of this model. The deterministic evaluation of cloud config snapshots against declared safety invariants, no ML in the verdict path. Apache 2.0. Disconfirmation welcome: if you've seen a case where probabilistic inference catches a posture problem deterministic evaluation structurally can't, I want to hear it.