How it works

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

1. A pull request opens or updates on a connected GitHub or GitLab repository.
2. AISafe detects the pull request, finds the explicitly selected project in each workspace, and creates an independent PR review for each workspace.
3. A status check appears on the commit straight away, so you can see the review is running.
4. AISafe pins the exact base and head commits of the triggering repository and freezes each companion repository at one identical commit on both sides. The AI agent loads the combined application context and reviews the changed paths. It reads the pull request's title and description as the author's account of the change, and checks that account against the code. It is not told who opened the pull request. 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

AISafe posts one summary for each workspace and selected project, and edits it as you push. The summary lists every finding with its severity, a one-line description and a link to the exact line. AISafe updates this comment in place on each new commit instead of posting a fresh one. When a review finds nothing, the summary says so, and if an earlier commit had findings that are now fixed, AISafe updates the same comment to show that.

AISafe adds inline comments for selected findings. 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 that workspace and project on the pull request, so pushing again does not repeat it. Other workspaces keep separate comments and checks.

When you push again, AISafe reviews what changed. When you push to a pull request AISafe has already reviewed, it re-reads only the files that differ from the ones it read last time. The other files keep the result from the previous review, so the review of a large pull request comes back faster on each commit after the first. The summary says how many files kept the earlier result, for example "37 files unchanged since c0ffee1 keep the previous review's result". A finding carried forward from the earlier review keeps its page and its comment and is not posted again. When something makes the comparison unsafe, AISafe runs a full review instead, without you asking. This happens, for example, after a rebase onto a new base commit and when you retry a review that failed. This does not change what you pay, because PR review billing counts pull requests rather than commits. See Credits & billing.

AISafe adds a status check to each commit. By default the check reports only that the review finished. It does not report whether the review was clean, so making the check required does not block a merge because of findings. To block merges on findings for a repository, set 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.

When a review fails or cannot publish, AISafe records the failure on its run and attempts to close the check it opened. If provider access has been revoked, AISafe may not be able to close the check. In that case, repair the connection and open the run to see what to do next.

Application context and private evidence

A review can use the other repositories coupled in its project as context. The comments AISafe posts automatically on the provider include source evidence only from the triggering repository. Details from private companion repositories stay in AISafe, and only people with access to the review can see them. If you change a project's repositories or policy while a review is running, the review still posts its result to the same place as before and keeps the source context it already read.

When a newer commit arrives while AISafe is posting the previous review, AISafe waits for that publication to finish before it starts the replacement review. This keeps an older result from overwriting the newer summary.

Review outcomes

AISafe shows the state of a review run separately from its 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 shown is the time the review reached its final state, not the last time its record changed.

A review marked Re-run is from before a completed review became final. Back then a later run of the same commit could replace it; it keeps its findings and links to its replacement.

If a review run fails on AISafe's side, AISafe runs it again by itself, so you never need to push a commit to get a review. When a review still does not finish, the review and its check say so, and say what to do next only when the cause is on your side, such as repository access. See Why did my review fail?.

A completed review is final. AISafe does not review the same commit twice, because a second answer about unchanged code would only add noise; the next push starts the next review. Asking with @aisafe review on a commit that was already reviewed points you to that review. Retry review appears only on a review that failed or was skipped, and starts a new attempt at the same commit.

When a pull request closes without merging, its untriaged issues are marked fixed: the change that introduced them never reached your code. Issues you already triaged keep your decision.

What a completed review shows

A completed review lists the findings from the changed files it reviewed and says how many files it reviewed. A review that finds nothing says so. A completed review is charged as one review. A review that does not finish is refunded; see Why did my review fail?.

A pull request that changes only images, fonts, other binary files, renames or files outside the source the project reviews has nothing to review. The directories a code review leaves out by default are node_modules/, vendor/, dist/ and generated/, and, if you picked specific files for the project, anything you did not pick. Such a pull request is not charged.

In the dashboard

Open a project's PR Reviews tab to read every review it has run. A review opens at its own address, so a link works in a ticket. Its page shows the pull request, the exact base and head commits, what started the review, and a table of the findings it produced. Suppressed findings are listed separately from the ones posted on the pull request, and each list has its own count.

Open a finding to read it in full, with its severity, class, file and line, the suggested fix, and a link to the comment on the pull request. From there you can Accept risk or Mark false positive: both record a reason and stop AISafe posting that finding on later reviews of the same code. An accepted risk needs a date and returns for review when it passes. Remove puts the finding back on the next review; the rule stays in the project's Suppressions register as revoked, so you can still see the decision and who made it. Suppression decisions need an organization admin.

Each issue a review reports is also recorded on the project as an untriaged finding with the review's code, for example PR-ACME-XQV-003, and its page links back to the review. It is recorded once per pull request: when a later push reports the same issue, the finding keeps the code of the first review that found it. Untriaged findings do not count in the project's findings or posture until someone triages them, so a pull request that never merges does not change your numbers.

The Retry review button is on the page of a review that failed or was skipped. Managers and above can use it.

Why it is not an assessment

PR review is a continuous capability of a project rather than an Assessment. It produces inline PR comments instead of a findings report. This way developers get security feedback quickly, 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

Each project has a living knowledge base that collects 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.