HomeGuidesRLS analysis guide
RLS analysis guide

Use deterministic rules and AI review where each is strongest.

Reliable tenant-isolation CI does not require choosing between fixed rules and AI. Known unsafe policy states should stay deterministic; contextual relationships can benefit from an advisory semantic review that never hides or replaces the repeatable result.

Deterministic analysis answers narrow, repeatable questions

A deterministic rule has a reviewable condition and returns the same answer for the same final migration state. This makes it appropriate for required CI checks, baselines, waivers, and audit evidence.

  • Is RLS enabled on every exposed table?
  • Does an anon, PUBLIC, or authenticated policy reduce to true?
  • Is a SECURITY DEFINER search path pinned?
  • Was default PUBLIC execution explicitly revoked?

AI review explores relationships that resist one syntax rule

A policy may contain auth.uid(), a membership lookup, and a tenant column yet connect them incorrectly. Contextual review can examine those definitions together and explain a plausible cross-tenant path for a human to validate.

The tradeoff is probabilistic output: a model can miss a flaw or raise an unhelpful concern. BoundaryCI therefore labels managed findings and keeps them advisory by default.

Let the risk determine the review layer

Use deterministic rules for known conditions that must be enforced consistently. Use AI to widen reviewer attention when meaning depends on several policies, functions, or membership relationships. Use runtime tests when the answer depends on actual roles, claims, requests, or application code.

  • Merge gate: deterministic findings by default
  • Contextual hypothesis: AI-assisted finding with human validation
  • Behavioral proof: active negative tests with two tenants
  • Broad assurance: threat modeling, manual review, and independent testing

Adopt AI review without making CI fragile

Run both layers on representative repositories and measure whether AI findings identify useful policy interactions. Keep deterministic checks enabled, preserve AI findings separately, and leave them out of the exit code until the team has an evidence-based reason to change that default.

Provider unavailability should degrade to a warning. Repository and organization opt-outs should remain available so an outage, sensitive project, or noisy review never requires removing the underlying security gate.

Make transmission a consented decision

BoundaryCI requires eligible-plan status and manager authorization before managed review. The runner checks eligibility before sending migration content, redacts common secret patterns locally, and limits input size. BoundaryCI does not store the forwarded migration text.

Frequently asked questions

Is AI more accurate than deterministic RLS analysis?

They answer different questions. Deterministic rules are more reliable for known syntax and final-state conditions. AI can surface contextual relationships those rules do not model, but its findings require human validation.

Should AI findings fail CI?

Not initially. BoundaryCI keeps them advisory by default. Teams should measure quality on their own migrations before explicitly including AI findings in an exit decision.

Do I need both AI review and runtime RLS tests?

Yes, when the boundary is important. Static review cannot execute live JWT claims, application queries, storage access, or service-role paths. Two-tenant negative tests provide a separate kind of evidence.

Protect the boundary

Build the reliable layer first, then widen the review.

BoundaryCI starts with deterministic tenant-isolation checks and adds managed AI as a clearly labeled, consent-gated signal.

Run deterministic checks first Read managed AI docs