Skip to main content
AI context rules give the AI SAST detection agent codebase-specific guidance about your code. The agent treats the rules as trusted facts from your security team. It applies them in each step that decides findings: detection, validation, classification and severity, and the refresh of findings. The agent accepts what a rule states about your deployment, infrastructure, compensating controls, scope, and triage policy, even when the code does not show it. The rules help it confirm genuine vulnerabilities, eliminate false positives, and account for behavior that is not evident from the source code alone. Rules do not change the content of the exploit reproduction or the remediation guidance. A rule that sets the severity can decide whether a finding gets them, because the agent generates them only for high and critical findings. The detection agent also reads the feedback you give on its findings. See Give feedback on AI SAST findings. Specific claims are far more effective than general ones. Anchor every rule to a file, directory, framework, route, or function name the agent can locate. AI SAST scans then produce findings that closely reflect the actual security posture of your codebase. AI context rules fill the gap before reviewers act on findings, and complement their decisions afterward. When a rule and reviewer feedback disagree, the rule takes precedence. Each rule belongs to a namespace and applies to every project in it. You can narrow it with inclusions or exclusions.

​
What makes an effective rule

Include facts the agent cannot infer from the code on its own. Describe your codebase so the agent understands what it reads and which attacks are realistic:
  • The primary languages and frameworks you use on the frontend and backend.
  • The entry points where untrusted input arrives, such as the package that holds your HTTP handlers.
  • The authentication and authorization enforcement points, such as the middleware that protects your API routes and the file it lives in.
  • The trust boundaries in your code, identified by file or directory.
  • The sinks and sanitizers specific to your project, named exactly.
  • The sources of secrets and configuration, such as a secrets manager loaded at boot rather than values hardcoded in source.
  • The deployment shape, such as a static frontend with all authorization enforced server-side.
Highlight the patterns you want the agent to keep reporting so recurring risks specific to your codebase are not under-weighted. Name the pattern, where it recurs, why it is real, and what should make the agent raise it again. Explain the patterns that look dangerous but are safe so the agent stops reporting them. Name the pattern, its location, why it is benign in your codebase, and a discriminator that separates it from a real issue. The agent applies a suppression to every finding at the symbol, file, location, or finding class that the rule names. A broad suppression, such as trust this directory, therefore also hides real issues there. For concrete examples, see Example AI context rules.

​
Set finding severity with a rule

A rule can set the severity of the findings it covers. The agent first computes a severity from the Score Metrics. It then applies the severity that your rule states. A rule can set an exact severity, a minimum, or a maximum:
  • Exact: Rate SQL injection findings in services/billing as Critical.
  • Minimum: Rate authorization findings in the admin API as at least High.
  • Maximum: Rate findings in internal tools under tools/ as at most Medium.
The agent quotes the rule that sets the severity. If the quote does not match the text of your rules, the agent keeps the computed severity. When a rule changes the severity, the Severity line in the Score Metrics shows the quoted rule and the computed severity. If the computed severity already meets the rule, the line shows only the computed severity. The agent applies a severity rule when it classifies a finding during detection. The refresh does not change the severity of stored findings. To apply a new severity rule to existing findings, run a full detection scan.

​
What not to include in a rule

The agent trusts every rule, so a rule takes effect even when the code does not support it. Do not include the following content in a rule:
  • Suppressions broader than you intend, such as telling the agent not to report SQL injection anywhere. A rule that ignores a finding class or location suppresses every finding it covers, including hardcoded secrets.
  • Generic security advice, such as OWASP, CWE, or phrases like validate all input. It says nothing about your code.
  • Secrets, tokens, private keys, personal data, or verbatim source code. Endor Labs sends the text of your rules to the AI model in each step that decides findings. Reference sensitive code by its file path and symbol name instead.
Rules cannot change the format of the agent’s results or the tools it uses. A rule is not a substitute for fixing code, so suppress a finding only when the code is genuinely safe.

​
Automatic context from repository files

During a scan, Endor Labs also builds context automatically. It reads guidance files in your repository along with prior reviewer feedback, grounds them against your code, and uses them alongside the rules you create. Unlike your AI context rules, the agent treats this automatic context as reference only. Your rules take precedence over reviewer feedback, and the most recent feedback takes precedence when reviewers disagree over time. By default, a scan reads these files when they are within the scan scope:
  • CLAUDE.md, and files under .claude/agents/ and .claude/rules/.
  • AGENTS.md.
  • .cursorrules, and files under .cursor/rules/.
  • .github/copilot-instructions.md.
  • SKILL.md files, such as .claude/skills/<name>/SKILL.md.
  • memory.md.

​
Create an AI context rule

Create a rule to give the agent guidance about your code. You can enable or disable a rule at any time after you create it. To create an AI context rule:
  1. Select Policies from the user menu.
  2. Select AI Context Rules.
  3. Select Create AI Context.
  4. Enter the following details:
    • AI Context Name: A name that identifies the rule.
    • Context: The guidance the agent reads. Describe the codebase, the conditions to look for, or background about the project.
  5. Under Scope, select the namespace the rule applies to. By default, the rule applies to all projects in the namespace, including projects added later.
  6. To limit the rule to specific projects, use Inclusions:
    • Click Add more under Inclusions.
    • Select the projects you want to include.
    • Click Update.
  7. Optional: Enter the tags of the projects you want to include.
  8. To exclude specific projects, use Exclusions:
    • Click Add more under Exclusions.
    • Select the projects you want to exclude.
    • Click Update.
  9. Optional: Enter the tags of the projects you want to exclude.
  10. Click Create AI Context.
If a project matches both inclusions and exclusions, the exclusion takes precedence. Create an AI context rule

​
Manage AI context rules

You can edit, clone, delete, enable, or disable a rule at any time. Update or delete a rule when the code it describes moves or changes, so the agent does not work from stale guidance. Edit a rule to update its name, context, or scope.
  1. Select Policies from the user menu.
  2. Select AI Context Rules.
  3. Click the vertical three dots next to the rule you want to edit.
  4. Select Edit.
  5. Update the AI context name, context, inclusions, or exclusions.
  6. Click Update AI Context.
Clone a rule to create a new rule with the same name, context, and scope.
  1. Select Policies from the user menu.
  2. Select AI Context Rules.
  3. Click the vertical three dots next to the rule you want to clone and select Clone.
  4. Update the AI context name, context, inclusions, and exclusions for the new rule.
  5. Click Create AI Context.
Delete a rule to remove it from your tenant.
  1. Select Policies from the user menu.
  2. Select AI Context Rules.
  3. Click the vertical three dots next to the rule you want to remove and select Delete.

​
When rules take effect

The agent reads AI context rules at the start of each scan. A new, edited, or deleted rule applies to the results of the next scan. A rule change also reaches existing findings through the refresh of findings. A rule change makes every stored finding due. Later default branch scans re-evaluate them against the updated rules, oldest first, within each scan’s time budget. This happens even when the code has not changed since the last scan. Most scans are incremental. An incremental scan runs detection only on the functions in files that changed since the last full index. A rule that asks the agent to look for a new pattern therefore surfaces findings in unchanged files only after a full detection scan. To run detection on every function against your current rules, run a full detection scan with the --ai-sast-rescan flag.
A full detection scan publishes only the findings it detects, and deletes stored findings that it does not detect again. It keeps findings in files that it could not analyze, such as files that a failed scan did not reach or that a sparse checkout leaves out. For scans that Endor Labs runs for you, add ENDOR_SCAN_AI_SAST_RESCAN=true to the additional environment variables of the project’s scan profile. While the scan profile sets the variable, every default branch scan is a full detection scan. Remove the variable after the full scan completes so later scans return to incremental mode.
A full detection scan deletes every stored finding that it does not detect again, including findings that you already triaged. While a scan profile sets ENDOR_SCAN_AI_SAST_RESCAN, PR scans also skip cached results, which increases scan time and cost.

​
Example AI context rules

Adapt the names and paths in these examples to your own code.
Another service handles authentication upstream, so the agent stops flagging missing authentication in this service but keeps reporting missing resource authorization.
A shared library sanitizes HTML, so the agent suppresses XSS findings on output that passes through it while still reporting sinks that bypass it.
Every protected endpoint must use a specific middleware, so the agent reports routes registered without it and leaves public routes alone.
Specific fields enforce tenant isolation, so the agent reports routes that scope queries by user instead of by tenant.
Admin actions need two separate checks and some directories are out of scope. The agent catches incomplete admin checks and suppresses findings in non-production paths.