Skip to main content
AI context rules give the AI SAST detection agent codebase-specific guidance to read while it analyzes your code. The agent treats each rule as reference evidence and verifies it against your actual code, applying what it can confirm and setting aside what it cannot. It uses the rules to confirm genuine vulnerabilities with greater confidence, eliminate false positives, and account for behavior that is not evident from the source code alone. AI context rules apply only to the detection agent. The AI SAST triage agent, which classifies rule-based SAST findings, does not read them. Specific claims are far more effective than general ones, so 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 reviewer marks a finding as a true positive or a false positive, that decision takes precedence over your written guidance. 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. A suppression without a discriminator, such as trust this directory or we already reviewed this, has no effect. For concrete examples, see Example AI context rules.

​
What not to include in a rule

AI context rules are reference evidence, not instructions, so the agent ignores anything that tries to override its built-in behavior. Do not include the following:
  • Instructions to turn off a detection category, such as telling the agent not to report SQL injection.
  • Instructions to ignore real secrets, such as hardcoded credentials. The agent always reports them.
  • Demands for a finding that the code evidence does not support.
  • Generic security advice, such as OWASP, CWE, or phrases like validate all input. It says nothing about your code, so the agent ignores it.
  • Secrets, tokens, private keys, personal data, or verbatim source code. Reference sensitive code by its file path and symbol name instead.
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 decisions, grounds them against your code, and uses them alongside the rules you create. Reviewer feedback takes precedence over the rules you write, and the most recent decision 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.
  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. Optionally, 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. Optionally, 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 detection agent reads AI context rules at the start of a scan. A new or updated rule therefore applies to the next scan, not to findings that already exist. Most scans are incremental. An incremental scan re-evaluates only the functions in files that changed since the last full index. Existing findings outside those files keep their previous verdict. A code change surfaces the effect of a rule only for findings in the files it touches. To re-evaluate every finding against your current rules, run a full detection scan with the --ai-sast-rescan flag.
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. Remove it after the full scan completes so later scans return to incremental mode.

​
Example AI context rules

Adapt the names and paths in these examples to your own code.
Authentication is handled 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, so the agent catches incomplete admin checks and suppresses findings in non-production paths.