Review execution and access
Hosted reviews use isolated per-run execution environments. Review checkouts are read-only to reviewers, and source checkouts are cleaned up after the run. Privileged GitHub publishing credentials are kept out of model processes. Workspace roles and GitHub installation permissions control which repositories and results a user can access. These controls reduce risk; they do not make untrusted code or model output inherently safe.
Reports and evidence
Reports are sanitized before storage. QA evidence lives in private object storage and is accessed through authenticated, short-lived links. Screenshots or report excerpts can still contain sensitive information from the configured task. Use test environments and synthetic data, and select evidence settings appropriate to your workspace.
Your configuration matters
For the CLI and GitHub Action, protect provider keys, pin released revisions, and keep credentials out of untrusted fork workflows. Review configuration and repository rules are loaded from the trusted base revision. Keep human review and tests in your release process; neither model agreement nor a confidence score proves that a change is safe.
Report a vulnerability privately
Use GitHub’s private vulnerability reporting form. Include the affected version, impact, and reproduction steps using synthetic data. Do not put credentials or vulnerability details in a public issue. If the form is unavailable, email us to arrange a private reporting channel.
We aim to acknowledge reports within three business days and provide an initial severity assessment within seven business days, as described in the repository security policy. These are communication targets, not guaranteed resolution times.