> ## Documentation Index
> Fetch the complete documentation index at: https://docs.amnify.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Pull request security review

> A security review with inline comments on every pull request, before the change merges.

Turn the toggle on for a repository and every pull request gets a security review. An agent reads the change with the repository around it and answers one question: does this introduce a security problem?

```mermaid theme={null}
flowchart TB
  P["Pull request opened,<br/>updated or marked ready"] --> R["Security review<br/>of the new change"]
  R --> C["Inline comments with severity<br/>and a suggested fix"]
  R --> S["Status check on<br/>the pull request"]
  C --> H["You reply"]
  H --> A["Amnify answers in the thread"]
  A --> H
```

## Setting it up

Turn reviews on per repository in [Scan automation](/scanning/automation). It is independent of your scan schedule, so enabling one never enables the other.

## What triggers a review

| Event                   | Result                                            |
| ----------------------- | ------------------------------------------------- |
| Pull request opened     | Reviewed                                          |
| New commits pushed      | Reviewed again, as a new round on the same review |
| Reopened                | Reviewed                                          |
| Marked ready for review | Reviewed, and this is a draft's first review      |
| Opened as a draft       | Not reviewed                                      |
| Converted back to draft | A review that has not started is withdrawn        |
| Closed                  | Any queued review is withdrawn                    |

A newer push supersedes a queued review of the same pull request, so a rapid series of pushes produces one review of the final state rather than one per commit.

## Scope of the review

* **The new change only.** Not the whole repository.
* **Read with the repository around it**, so a change is judged in the context of the code it touches, not as a diff in isolation.
* **Aware of what was already said.** A later push resumes the same review, keeping its prior rounds.

## What it posts

<CardGroup cols={2}>
  <Card title="Inline comments" icon="comment">
    Anchored to the exact line, with a severity from Critical to Info and an apply ready suggestion when the fix is a direct edit.
  </Card>

  <Card title="A status check" icon="circle-check">
    Mirrors the highest severity found, so branch protection can block an unsafe merge. Critical or High fails, Medium or Low is neutral, clean passes.
  </Card>
</CardGroup>

| Signal | Meaning                                         |
| ------ | ----------------------------------------------- |
| Red    | At least one Critical or High comment           |
| Yellow | Medium or Low comments only                     |
| Green  | Nothing found, or every issue verified as fixed |

<Note>
  Nothing else. A review never creates or changes [Findings](/getting-started/manage-findings). Your findings record describes the state of your systems, and a pull request is a proposal.
</Note>

## Replying to Amnify

Amnify is a participant, not a one shot bot. Reply in one of its threads or mention it anywhere on the pull request and it answers.

```mermaid theme={null}
flowchart TB
  H["You reply in a thread,<br/>or mention Amnify"] --> W["Short debounce"]
  W --> A["One answer covering<br/>every new comment"]
  A -->|"issue demonstrated<br/>as a false positive"| R["Thread resolved"]
```

A round answers. It does not re-review, raises no findings, and posts no status check. A burst of comments becomes one coherent answer rather than one reply per comment, and a review always takes precedence over a conversation round on the same pull request. Rounds per pull request are capped, so a long argument cannot consume unbounded work.

## Injection resistance

Pull request content and comments are attacker controllable, especially on public repositories.

* Comment text is handled strictly as data, kept to a bounded length, and stripped of anything crafted to look like an instruction to the agent.
* Only the conversation Amnify is actually part of is read: its own threads with their replies, plus comments that mention it. Threads between other people are never ingested.
* Comments from bots, and from authors with no relationship to the repository, never trigger a round.
* The reviewer can do two things and nothing else: post comments and post replies. It cannot create findings, context or remediations, so the worst case of a successful injection is an unhelpful comment.
* A reply can only be posted into a thread on the same pull request that Amnify is already part of.