> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coderabbit.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Steer AI Deep Scans
> Choose repository context, Custom Path Instructions, Security Learnings, linked repositories, and path exclusions to guide AI Deep Scans.
AI Deep Scan uses your repository's code and saved security settings to investigate vulnerabilities. You can explain how the system works, direct analysis toward specific security requirements, teach scans from finding feedback, and choose which source is in scope. These controls work together and apply to subsequent scans.
## Choose the right control
| What you need | Use | Example |
| - | - | - |
| Explain architecture, sensitive data, or trust boundaries across the repository | [Repository context](#repository-context) | Describe public entry points, tenant isolation, and where authorization happens. |
| Tell the scan what to check in particular files or directories | [Custom Path Instructions](#custom-path-instructions) | Check every handler in `src/api/**` for object-level authorization. |
| Avoid repeating a finding whose specific behavior you have accepted | [Suppression Learnings](#learn-from-a-finding) | Accept a documented risk in one file while keeping other findings eligible. |
| Correct a vulnerability's severity and teach future scans why | [Severity feedback](#calibrate-severity) | Explain the prerequisites or impact that justify a different severity. |
| Provide implementation evidence from another repository | [Linked repositories](#linked-repositories) | Let an API scan inspect its shared authentication library. |
| Skip files or directories entirely | [Path Exclude Filters](#path-exclude-filters) | Exclude generated output that you do not want assessed. |
| Assess a particular committed version | [Scan branch](#scan-branch) | Scan a release branch instead of the provider default branch. |
To configure context, path instructions, exclusions, and the scan branch, open **Security > Repositories**, select a repository, and go to **Settings > Scan configuration**. Create Learnings from an existing finding and manage them in the repository's **Learnings** tab.
These controls are separate from the settings of the same names used in pull request reviews. [Path Instructions](/configuration/path-instructions), [path filters](/configuration/path-instructions#path-filters), and [Learnings](/knowledge-base/learnings) configured for pull request reviews do not affect AI Deep Scans, and the settings on this page do not affect pull request reviews.
## Repository context
Use **AI Deep Scan > Context** for facts that help explain the repository as a whole. This is a good starting point before your first scan, especially when the code alone does not explain the business domain or deployment model.
Include concrete details such as:
* The service's purpose and the sensitive data it handles.
* Public entry points, internal services, background workers, and the origins of their input.
* Authentication, authorization, tenant boundaries, and the files that implement those controls.
* Deployment assumptions and where to verify them in committed configuration.
For example:
```text wrap theme={null}
This repository runs a multi-tenant billing API. Public HTTP handlers are in src/api/. Authentication is implemented in src/middleware/auth.ts; handlers must also authorize access to the tenant named in each request. Background workers in src/jobs/ consume events derived from customer input. Deployment and ingress configuration is in deploy/.
```
Prefer statements with file references over broad claims such as "all input is trusted." CodeRabbit checks security-relevant claims against repository evidence; context cannot override scan instructions or establish safety by itself.
Enter up to 4,000 characters. Saved context applies to later scans of the repository; clearing the field removes it.
AI Deep Scan does not retrieve context through connected MCP servers. If relevant architecture or operating assumptions live in an external document or dashboard, include the relevant facts directly in Context and identify repository evidence where available.
## Custom Path Instructions
Use **AI Deep Scan > Custom Path Instructions** when you want a security check applied to a known part of the codebase. You can add instructions before any findings exist, or choose **Create a path instruction** from a finding's **Dismiss finding** action.
Each entry contains a repository-relative path or glob and an instruction for matching files. For example:
| Path | Instruction |
| - | - |
| `src/api/**` | Check that each handler authorizes the authenticated user for the requested tenant and object, including bulk operations. |
| `src/webhooks/**` | Verify signatures against the raw request body before parsing or processing events. Check replay protection. |
| `src/jobs/**` | Trace customer-controlled fields from queued events to database queries, file access, and command execution. |
Context explains the system; a path instruction tells the scan what to investigate in matching code. Adding an instruction does not exclude matching files. To skip them, use [Path Exclude Filters](#path-exclude-filters).
You can save up to 100 instructions per repository, with up to 4,000 characters per instruction. Paths use the same [validation rules as exclusions](/security#branch-and-exclusions). See [Custom Path Instructions](/security#custom-path-instructions) for access requirements.
## Learn from a finding
Use a suppression Learning when an existing finding identifies behavior you have reviewed and accepted, and you want later scans to recognize that same situation. Explain the accepted behavior, why it is acceptable, and the limits of that decision.
For example, for an intentionally public download handler:
```text wrap theme={null}
In src/api/public-download.ts, anonymous downloads of published reports are intentional. Accept missing authentication only for reports marked public. Draft reports and private reports still require tenant authorization.
```
Open **Dismiss finding > Create a learning**, enter the rationale, and choose a scope:
| Scope | When to use it |
| - | - |
| **Current file** | The rationale depends on behavior in this exact repository-relative file. Use this for a local exception. |
| **Entire repository** | The same accepted-risk rationale holds across the repository. The finding's behavior must still match. |
| **Auto** | Let CodeRabbit infer scope from the guidance. It defaults to the current file when the scope is unclear. |
Later scans suppress a finding only when its behavior and scope match the Learning. A file-scoped Learning does not cover an entire directory or glob. Use a path instruction when you need guidance for a group of files, or repository context when you need to explain the system generally.
Creating a Learning or path instruction leaves the current finding's status unchanged. Choose **Ignore this finding** separately if you want to mark it ignored. Ignoring alone saves no guidance for later scans. If the vulnerability has been fixed, use [Resolve finding](/security#resolve-finding) with supporting fix context.
Review saved guidance in **Security > Repositories > your repository > Learnings**. Edit or delete guidance when its assumptions change. These Security Learnings are separate from pull request review Learnings. See [Dismiss finding and Learnings](/security#dismiss-finding-and-learnings) for management and access details.
## Calibrate severity
Use a vulnerability's **Change severity** action when the issue should remain a finding but its severity needs correction. Choose the severity and enter a reason, then select **Save severity and learning**.
The reason is saved as a Learning for future scans. Severity Learnings are file-scoped by default; repository-scoped guidance applies across files only when the reason explicitly supports that scope. Explain the evidence behind the change, such as required privileges, attacker prerequisites, or the affected data. Future scans apply that severity guidance only when current evidence supports the rationale. Lowering severity does not suppress the finding.
Changing severity requires Security write access. Use **Create a learning** from **Dismiss finding** when your intention is to suppress matching accepted-risk findings instead.
## Linked repositories
Use linked repositories when the evidence needed to understand a finding lives outside the repository you are scanning. For example, an API service might rely on authorization implemented in a shared library.
In **Run AI Deep Scan > Advanced configuration > Linked repositories**, select **Edit** to manage links and relationship instructions. Select **Save review and scan links** to save the links and linking mode. In **Manual** mode, use the **Source access** checkboxes and select **Save source access**. Save or discard pending changes before you select **Run Deep Scan**. Repository context can describe the relationship, but source access supplies code the scan can inspect.
Linked source is read-only context. Findings and coverage belong to the primary repository; scan each linked repository separately to assess it. Source is pinned to a commit on each linked repository's default branch, which does not establish the deployed version.
Linked source access is available on GitHub Cloud, GitHub Enterprise Server, and GitLab Cloud. It requires AI Deep Scan access and a plan supporting Multi-Repo Analysis. See [Linked repositories](/security#linked-repositories) for platform requirements, plan limits, and how Manual and Automatic modes choose source context.
## Path Exclude Filters
Use **AI Deep Scan > Path Exclude Filters** only when you want matching files skipped during analysis. Enter one repository-relative path or glob per line, for example:
```text theme={null}
generated/**
docs/examples/**
```
Choose exclusions based on what you intend to assess. Generated code, examples, and fixtures can still contain security-relevant behavior; exclude them only when they are outside your intended scope. If you want to keep investigating a file while avoiding one accepted issue, use a narrowly scoped Learning.
Exclusions affect scan coverage and the pre-scan credit estimate. Instructions targeting an excluded path do not bring it back into scope. Filtering the **Findings** table by severity, status, or text only changes the results you see; it does not change scan scope.
You can save up to 100 excluded paths per repository. See [Branch and exclusions](/security#branch-and-exclusions) for path validation rules.
## Scan branch
For GitHub repositories, choose the branch to assess in scan configuration. Use **Provider default** to follow the repository's default branch, or select a custom branch when you need to assess a release or another maintained version.
Context, instructions, and Learnings are saved for the repository. Check that their assumptions and file paths still apply to the branch you select. Changing the primary scan branch does not change the default-branch revision used for linked repository context.
## Put the controls together
For a multi-tenant API, start with repository context that names its trust boundaries and authorization code. Add path instructions for tenant checks in API handlers and signature checks in webhooks. Link the shared authorization library if the implementation is in another repository. Exclude only paths outside your intended assessment.
After reviewing findings, save narrow Learnings for accepted risks and severity feedback for incorrect severity. Update the saved guidance when the architecture or accepted risks change, then run another scan and inspect both findings and coverage. Saving guidance does not itself start a scan or guarantee complete coverage.
## What's next
Start a scan with your saved settings and review its estimate and status.
Inspect evidence, manage finding status, and start supported fixes.
Understand verification coverage and identify areas that need further investigation.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.