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. 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 shows how many files were reviewed again and how many were unchanged, for example "Reviewed 3 of 40 changed files; 37 unchanged since c0ffee1". 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 after a rebase onto a new base commit, when a file was not read in the previous review, and when you asked for a re-run yourself. 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 re-run review is in none of those states. It produced a result, and you can still read its findings on its own page. AISafe marks it Re-run because a later run of the same commit replaced it, and its page links to the replacement.

When a review fails, AISafe tells you what happened and what to do about it instead of showing one generic error. See Why did my review fail?.

Run again asks for a second review of the same commit. The earlier review stays as history, marked Re-run and linking to its replacement. A re-run costs the same as any review.

How much of the pull request was reviewed

Every completed review says how much of the pull request it covered, for example "Reviewed all 12 changed files", or "Reviewed 8 of 40 changed files; 32 skipped" with the reason. The reason is the review size limit, a single file whose change is too large to read, or the time limit. AISafe never presents a review that covered part of a pull request as if it covered all of it. A result of "no security findings" across 8 of 40 files means something different from a clean result across every file, and the summary tells you which of the two you are reading.

When a single file is too large, AISafe skips it and names it. The file does not make the review fail.

Some changed files contain nothing to review, and the summary counts them separately: "Reviewed 1 of 3 changed files; 2 with nothing to review (binary, no content change)". A file is in that group when it is an image, a font or another binary; when both sides are identical, which is what a rename with no edit or a permission change looks like; or when it sits outside the source the project reviews — the directories a code review skips by default, such as node_modules/, vendor/, dist/ and generated/, or, if you picked specific files for the project, anything you did not pick. Those files are named on the review page with the reason beside each one. They do not fail the review and they do not make its coverage partial, because there was nothing in them to read.

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.

The Run again button is on a review's own page. Managers and above can use it.

When AISafe could not read the whole change, the review says so. It states how many of the changed files it reviewed and lists the ones it skipped, with the reason for each. When a review read only part of a pull request, AISafe never reports a clean result for the part the review did not open.

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.