Getting started

The Security Reviewer turns a target, either a local repository or a pull request, into a report. This page explains the flow, then points you to the way of running it that fits you.

How a review runs

1. Intake (read-only). The target is read through a fixed allowlist of read commands. For a local repository it reads a full-repo sample of security-relevant files, or a base...HEAD diff. For a pull request it reads the PR metadata and diff. Nothing is written to the target.
2. Fan-out finders. Five finders run in parallel, each focused on one class of risk: auth, tenant isolation and IDOR, injection, secrets and config, and webhooks and MCP.
3. Adversarial verification. Each finding is challenged by a panel of refuters. A finding is confirmed only when a majority fail to refute it.
4. Report. Confirmed findings are ranked by severity and written into one report with a verdict of reviewed or flagged. The report is saved to the database and to local Markdown and JSON files.

Choose how to run it

• GitHub App. The App reviews pull requests automatically and posts the verdict back. See Register and install and Auto-review on pull requests.
• API. Trigger a review on demand for a repository path or a pull request. See API and triggers.
• Command line. Run a one-off review locally that prints the report and keeps the files. See Command line.
• Daemon. Review a configured set of repositories on a schedule. See Self-host the daemon.

What you need

• An Agentic Suite backend running with its database migrated.
• At least one model configured for the reviewer to use.
• The gh command line for pull request intake, and git for local reviews.

Read-only guarantee

Reviews never modify the code they inspect. The only write action is a verdict comment on a pull request, and that happens only when a review runs in execute mode, which is off by default. See Safety controls.