Skip to main content

How it works

PR Review runs in the background on a Project. The flow is:

  1. A pull request opens or updates on the connected GitHub or GitLab repository.
  2. AISafe detects the pull request, identifies the project, and creates a PR review.
  3. A status check appears on the commit straight away, so you can see the review is running.
  4. The AI agent pins the exact base and head commits, loads the changed files and needed repository context, and reviews those paths. If the project has knowledge from an earlier audit, the agent uses it as extra context; an earlier audit is not required.
  5. AISafe posts a summary comment listing everything it found, adds inline comments on the findings that carry a fix or a high severity, and completes the status check.

What you see on the pull request​

One summary comment, edited as you push. It lists every finding with its severity, a one-line description and a link to the exact line, and it is updated in place on each new commit rather than posting a fresh comment. When a review comes back clean it says so, and if an earlier commit had findings that are now fixed, the same comment is updated to reflect that.

Inline comments on the findings worth anchoring. A finding gets its own comment on the line when it carries a one-click fix or is rated high or critical. Everything else stays in the summary list. A finding is commented on once for the whole pull request, so pushing again does not repeat it.

A status check on each commit. By default it reports that the review finished, not whether it was clean, so requiring the check does not block a merge on findings. A project that wants findings to block a merge sets Fail the check at to a severity band in its PR review settings.

Changing the status-check setting affects new reviews. A review already in progress still completes the check it opened.

If AISafe cannot start, finish, or publish a review, it closes its status as neutral and links to the review run. An AISafe outage never leaves the pull request waiting or blocks the merge.

Review outcomes​

AISafe keeps run state separate from the security result. No issues found appears only after a review completes. Queued and running reviews say that work is still under way. Failed, skipped, and superseded reviews say that no result was produced and show the next step when one is available. The finish time is the terminal transition time, not the last time the row changed.

Why it is not an assessment​

PR review is a project-level continuous capability, not an Assessment. It produces inline PR comments rather than a findings report. This keeps the feedback loop tight: developers get security feedback in their existing code review workflow without switching tools.

Delivery log​

Each VCS-backed project includes a delivery log on its Source tab. Use it to diagnose why a push or pull request did not trigger a review or source sync. Delivery rows show the repository, commit, event type, status, and a readable ignored reason such as an unbound project, branch filter mismatch, or disabled PR review.

Knowledge base​

The project owns a living knowledge base that accumulates context across scans. PR review uses that knowledge when it exists, but it can review the first pull request on a new project from the pinned diff and repository context alone. The review records the exact base and head commits and states when no prior project audit was available. See Concepts: Project for how the knowledge base works.