Security and Privacy Review

Review only unless the user separately authorizes fixes. Do not probe production, post comments, change pull-request state, or expose sensitive data.

Review flow

1. Establish the base, diff, intended behavior, changed trust boundaries, and attacker- or user-controlled inputs.
2. Read repository security and ownership instructions for every changed surface.
3. Trace each changed path from identity or input through authentication, authorization, state, storage, logs, asynchronous work, and output.
4. Inspect the nearest tests and real enforcement point. UI visibility is not authorization.
5. Exclude pre-existing debt, keyword matches, style preferences, and hypothetical failures without a reachable mechanism.
6. Report only regressions introduced, worsened, or materially touched by the diff with confidence of at least 80/100, anchored to a changed file or line.

Use evidence in this order: changed code and full trust or call chain, behavior-protecting tests, runtime configuration, repository security instructions, then other documentation.

Read references/trust-boundary-patterns.md when the diff touches tenant resolution, public reads or writes, webhooks, files, secrets, logs, personal data, provider integrations, or administrative observability.

Core checks