Security review for pull requests written by Cursor

What Cursor work becomes

Cursor writes the change in the editor, in a cloud agent, or from a comment on the pull request. The result in GitHub is a diff. The author's name on the pull request may be a person, or it may be the agent. A reviewer still sees added lines, not the chat that produced them.

What changes with the agent is pace. The task asked for the feature. The ownership check, the tenant binding, the role list on the route: those are in the code you already had, and they are not in the task, so they are easy to leave behind while the diff looks complete.

What Bugbot's docs say it does

Quoted from Cursor's Bugbot docs, retrieved 2026-10-03: "Bugbot reviews pull requests and identifies bugs, security issues, and code quality problems." The same page says: "Bugbot analyzes PR diffs and leaves comments with explanations and fix suggestions. It runs automatically on each PR update or manually when triggered." The same page also says: "If you use branch protection, require the Bugbot check or build status to make sure Bugbot runs before merge."

This page does not rank Bugbot. Their docs already name security issues as part of the job. The fact that is specific here is the shape of a second read: a published class list, a cap of five findings, comments only on added lines when the quote matches, and a Check that is advisory. Aevral never blocks a merge. You decide what ships.

What a security read of that pull request looks for

Two questions, before the feature. On this route, who is the actor, and where does the gate for that actor live. On this lookup, who names the key: the session, or the request. A new handler that takes an id from the query and does not pass it through the helper the rest of the file uses is the shape worth stopping for.

Business logic is the same question in a different costume: an entitlement, a plan gate, a role compared as a label. The worked version of that read is the business-logic guide. Injection and output issues ride in when the task asked for a filter, a shell step, or a model call. They are on the class list. They are not a second product.

Your options, in order of reach

Bugbot, as Cursor documents it. The page says: If you use branch protection, require the Bugbot check or build status to make sure Bugbot runs before merge. That is their setup, not a setting inside Aevral.

Your own checklist. Open the rule before the diff. The procedure is the access-review guide. It costs attention, which is the thing a long agent queue is short of.

A second reviewer on the repository. The Aevral GitHub App installs once, on the accounts or organizations you choose, and from the next pull request it reads the diff, whether a person opened it or Cursor did. A finding is a lead with evidence and a suggested fix, at most five findings per review. You can hand the fix prompt back to Cursor. Aevral never pushes, applies, or merges.

From install to the first comment

One: install the Aevral GitHub App on the repositories you choose; a GitHub owner or admin approves the install. PR review is live on install: installing the App starts reviews on the next pull request, even before anyone signs in, and the owner can turn them off in Setup.

Two: sign in to the console with GitHub. That connects the install and starts a 14-day trial for private repositories: private reviews are free up to 500, and the trial ends at 14 days or 500 reviews, whichever comes first.

Three: open a pull request, or let your coding agent open one. Aevral reads the diff of the changed files, and the most security-relevant in full.

Four: read the result on the pull request. An advisory Check sits on the head commit, and when there is a grounded finding, inline comments sit on the added lines, at most five findings per review. Each finding carries the evidence, a suggested fix, and a Fix with your agent prompt a human can paste into Claude Code, Cursor, or Codex. Aevral never pushes, applies, or merges anything, and it never blocks a merge. You decide what ships.

What it looks for, and the published record

Aevral's PR review looks for access control, business logic, SQL and command injection, XSS, SSRF, path traversal, unsafe deserialization, token and session flaws, and LLM-integration risks, live on install. The whole-repo scan reads authorization, IDOR, and business-logic access control across the default branch, for the rules a single diff does not show.

The published record: on the Aevral receipts page, the PR review runs of 25 September 2026 read "10 of 12" (Run 1) and "11 of 12" (Run 2) on the frozen authorization slice of planted pull requests. In the page's own words: "Each recall number is the result of that named run on that corpus. It is not a product accuracy rate, and results on your code depend on your code."

Limits worth knowing: GitHub only (not GitLab, Bitbucket, or Azure DevOps). The review reads the diff of the changed files and the most security-relevant files in full; on a large pull request the most security-relevant files are reviewed first, and the review says which files it covered. It is not secret scanning, not dependency scanning, and not a general SAST.