Concepts
The verdict tiers, resolved-effect, and the read-only-first model behind every CBX Guard verdict.
Concepts
Coming soon. CBX Guard is not yet generally available. These concepts describe how the product reasons about change so you know exactly what a verdict means.
Three ideas explain everything CBX Guard does: the verdict tiers, resolved-effect, and the read-only-first model.
The verdict tiers
Every infrastructure change gets exactly one verdict, in one of four tiers. The whole system is organized around one discipline: the loudest signal is sacred and only fires when real danger is proven with facts.
| Verdict | When it fires | Delivery |
|---|---|---|
| Critical | The "look now" interrupt. Fires only when every condition for real danger holds with facts — a genuine move from safe to dangerous, on a resource that's actually reachable, in an account that actually matters. | Loud. The PR check fails. |
| High | A real danger that's missing exactly one condition, or where one condition is known only by inference rather than fact. Real and surfaced — but it never interrupts you. | Quiet. The PR check is neutral. |
| Watch | Reserved for actionable unknown context (a condition couldn't be resolved — unreadable, not proven false) and one step from dangerous. Never silent, never an interrupt. | Surfaced for review. |
| Clean | No new exposure. Includes the routine "what changed today" baseline — informational, not a warning. | Silent. |
Two things make the tiers trustworthy:
- Critical is earned, never guessed. CBX Guard withholds Critical unless the danger is established by facts — values lifted straight from the change and your live state. A condition known only by a soft signal (a tag, a label) caps the verdict at High. The deterministic core decides the tier; the AI explainer only puts the verdict into words — it can never create a finding or change a tier.
- Unknown is never silent. If CBX Guard can't resolve whether something is reachable or production, it does not quietly pass the change — it surfaces a Watch for a human. Silence is reserved for changes that are provably fine.
The day-one baseline
When you first connect an account, CBX Guard snapshots what's already there — an existing world-open security group, a pre-existing admin role — as a grandfathered baseline. Those standing facts are surfaced quietly as context, not fired as Critical. CBX Guard interrupts on a change off that baseline — the moment something moves from safe to dangerous — not on pre-existing state. So day one is quiet, and the first loud verdict is a real, new event.
Resolved-effect
This is what separates CBX Guard from a linter. A linter reads the diff and matches patterns. CBX Guard resolves the effect of a change before judging it.
The same dangerous change can be written a dozen ways across Terraform encodings, and its real risk depends entirely on context the diff doesn't contain. So before a verdict, CBX Guard:
- Normalizes the change into its effective state — the meaning of the edit, identical regardless of which IaC syntax expressed it.
- Computes the delta against the captured baseline — did this actually move something from a safe/closed state to a dangerous/open one? A config that was already dangerous is steady state, not an event.
- Resolves it against live state — is the target actually reachable from the internet (public subnet with an internet gateway, an internet-facing load balancer, a public-accessibility flag)? Is it in an account that matters (production)?
Only a change that clears all of that — a real delta, on a reachable target, in an account that matters — can reach Critical. A world-open rule on a security group attached to nothing isn't a Critical; an already-open port that's merely re-applied isn't even an event.
Why it matters: resolved-effect is why CBX Guard's verdicts reflect real exposure rather than the presence of a scary-looking keyword. It's also why connecting a cloud account makes verdicts sharper — reachability and production scope come from your live state.
Reachability is resolved, never guessed
The "is it reachable?" step draws on the network graph CBX Guard captures when it scans your account. Reachability is an honest tri-state:
- Reachable — there's a resolved internet path (a public subnet routed to an internet gateway with a world-open group, an internet-facing load balancer, a publicly-accessible database). This is what lets a verdict escalate.
- Contained — the graph proves there's no internet path; the resource is private.
- Unreadable — CBX Guard couldn't determine reachability. It is never silently treated as contained — an unreadable target routes to Watch for a human.
Before you scan an account, reachability is simply not yet resolved (everything is unreadable),
so a fresh exposure resolves only to Watch — CBX Guard can't yet confirm the internet path. The
scan is what turns that unknown into a fact. See Scan your account.
Resolved-effect runs in two lanes
The same resolved-effect model is applied in two places: the offline CI gate in your pipeline (which resolves against empty state — the diff only) and the server-side account-aware review (which resolves against your captured live account). Because the second lane can see live state the first can't, it can return a sharper verdict on the very same diff — a clean-looking change becoming High because of what's already in your account. See Two lanes.
Read-only-first
Every CBX Guard connection starts from the least privilege that still works, and every step that writes is opt-in and separate:
- Repositories are connected with read access to index your IaC. The merge gate — the only thing that ever writes to your repo — is a separate, explicit step, and it never touches your default branch.
- Cloud accounts are connected with a role carrying read-only permissions only. There is no write action anywhere in the template, and deleting the stack revokes access instantly.
- Connections are revocable, and CBX Guard is honest about what it can and can't revoke — a token you created is yours to revoke; a credential CBX Guard provisioned, it revokes for you.
The result: you can adopt CBX Guard in pure-observe mode, see real verdicts on real pull requests, and only turn on the gate when you trust it.