Two lanes: the CI gate and the account-aware review

CBX Guard reviews the same pull request in two independent lanes, and they answer subtly different questions:

Both run the same deterministic engine and the same resolved-effect model — the only thing that differs is what live state each one can see. That difference is the whole point.

Why one lane blocks in CI and the other posts to the PR

• The CI gate blocks in the pipeline. It runs as a job in your own CI, so when a change is gated the job exits non-zero and fails the pipeline — that's what stops the merge if you've made the job a required check. It sees only the diff, planned offline. See Gate pull requests in CI.
• The account-aware review posts its own verdict onto the PR/MR. It runs on CBX Guard's servers, resolves the change against your captured account state, and writes its verdict back where you review code — a cbxguard/policy check-run plus a comment on GitHub, or an MR note plus a commit status on GitLab. It's marked "CBX Guard platform review (account-aware)" so you always know which lane you're reading.

When both lanes have run, the account-aware review is the authoritative one: it can see everything the offline gate can, plus your live account. Its comment carries a hidden marker so re-posting edits in place rather than stacking, and it supersedes (never deletes) the earlier offline note — leaving the PR consistent on the sharper verdict.

Why the account-aware review can differ from the diff-only gate

This is the reason the second lane exists. The dangerous change rarely looks dangerous in the diff. The offline CI gate can only reason about the text of the change; it has no way to know what's already in your account. The account-aware review resolves the change against your live state — so it can reach a harsher verdict on a diff that reads as perfectly clean.

A worked example: a clean diff that's actually High

Consider a one-line change to a production database's security group:

# The entire diff — a single SG-to-SG ingress rule on port 5432.
resource "aws_security_group_rule" "db_from_analytics" {
  type                     = "ingress"
  from_port                = 5432
  to_port                  = 5432
  protocol                 = "tcp"
  security_group_id        = aws_security_group.db.id
  source_security_group_id = "sg-0a1b2c3d4e5f67890"   # "the analytics connector"
}

Read on its own, this is routine: it grants one internal security group access to the database. The source isn't a broad-internet CIDR, so the offline CI gate passes it — green. The diff says clean, and from the diff alone, it is.

Now resolve it against the captured account, and two facts the diff never mentions come into view:

1. The "analytics" source group is itself world-open. In live state, sg-0a1b2c3d4e5f67890 admits 0.0.0.0/0. Granting it to the database transitively opens the database to the internet — CBX Guard's source-expansion synthesizes the broad CIDR the diff hid behind an SG reference.
2. The database it fronts is a reachable production crown jewel. The security group protects a production RDS instance that is publicly accessible — a resource the diff doesn't name at all, but the account scan captured.

Neither fact is in the change. Both come from your live account. Resolved together, the "routine internal grant" is a genuine move from safe to dangerous, on a reachable target, in an account that matters — so the account-aware review returns High and blocks the merge, and its comment names the production database the diff never showed you.

And the reverse: the review doesn't cry wolf either

The same live-state resolution keeps the review honest downward, too. A change that looks alarming in the diff can resolve to a quieter tier once your account is consulted — for example, a widened ingress on a security group that fronts a database in a private subnet with no resolved internet path stays Watch, not Critical, because reachability isn't proven. Resolved-effect cuts both ways: it escalates real exposure and it declines to interrupt on exposure that isn't real. See Concepts → resolved-effect.

What the account-aware review needs

The review lane only earns its edge when it has live state to resolve against. It needs:

• A connected repository, so it can fetch the PR's head and plan it. See Connect a repository.
• A connected cloud account that has been scanned, so there's a captured landscape to resolve against. See Connect an AWS account and Scan your account.

If a repository has no Terraform, no connected account, or the plan can't be produced, the review is recorded as failed with a stated reason — never green-on-empty, never a fabricated verdict. Without a scanned account it degrades gracefully to the same offline reasoning the CI gate uses: still a real verdict, just without the live-state sharpening.

Next steps