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

# Suppression Rules

> Stop the Mjolnir PR review agent from raising patterns you don't care about

Suppression rules tell Mjolnir not to raise specific vulnerability patterns during [PR Reviews](/mjolnir/pr-reviews). Use them to mute false positives, accepted risks, or patterns that are intentional in your codebase (for example, raw HTML rendering in a static blog generator, or test code that purposely uses weak crypto).

Open Suppression Rules from **Security testing > Full pentests > Ignored findings** in the sidebar.

## Where rules come from

Rules can be created two ways:

* **Manual**: you create them on this page when you know a pattern shouldn't be raised
* **Auto-learned**: when your team ignores the same suggestion across multiple PRs and you've enabled auto-suppression in [Mjolnir Configuration](/mjolnir/configuration#pr-review), Mjolnir creates a rule automatically once the threshold is hit

Each rule shows its source so you can tell at a glance whether it came from the team or was learned from PR dismissals.

## Creating a rule

Click **New Rule** (or press `c` from the page) to open the creation dialog.

| Field                  | Description                                                                                      |
| ---------------------- | ------------------------------------------------------------------------------------------------ |
| **Scope**              | Apply the rule to a single repository or across the entire organisation                          |
| **Repository**         | When scope is repository, the full `owner/repo` name from GitHub                                 |
| **Category**           | The vulnerability category (e.g. `injection`, `authorisation`)                                   |
| **Vulnerability type** | The specific type within that category (e.g. `sql-injection`, `idor`)                            |
| **File pattern**       | Optional glob to restrict the rule to matching paths (e.g. `tests/**`, `src/legacy/*.ts`)        |
| **Reason**             | Why this pattern is acceptable. This is required and gets shown to teammates reviewing the rule. |

<Tip>
  Use file patterns to scope rules narrowly. For example, suppress `sql-injection` only in `tests/**` rather than globally — that way Mjolnir still flags it in production code paths.
</Tip>

## Managing rules

From the rules list you can:

* **Filter** by source (Manual / Auto-learned) and status (Active / Disabled)
* **Enable or disable** a rule with the toggle — disabling lets you pause a rule without losing it
* **Delete** a rule permanently — Mjolnir resumes raising findings that match it on the next PR

## Best practices

* **Document the reason** clearly. Future you (and your teammates) will thank you when reviewing why something was suppressed.
* **Prefer narrow scope**: repository-scoped rules with file patterns are safer than organisation-wide rules.
* **Review auto-learned rules** periodically. They're created from real dismissal patterns, but they can encode bad habits if your team is over-dismissing.
* **Disable rather than delete** if you're not sure — disabled rules can be re-enabled later, deleted ones can't.