AI context rules

AI context rules give the AI SAST agents codebase-specific guidance to read while they analyze your code. The agents treat each rule as reference evidence and verify it against your actual code, applying what they can confirm and setting aside what they cannot. They use 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. Specific claims are far more effective than general ones, so anchor every rule to a file, directory, framework, route, or function name the agents 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 agents cannot infer from the code on their own. Describe your codebase so the agents understand what they read 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 agents 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 agents raise it again. Explain the patterns that look dangerous but are safe so the agents stop 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 agents ignore anything that tries to override their built-in behavior. Do not include the following:

Instructions to turn off a detection category, such as telling the agents not to report SQL injection.
Instructions to ignore real secrets, such as hardcoded credentials. The agents always report 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 agents ignore 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 agents guidance about your code. You can enable or disable a rule at any time after you create it. To create an AI context rule:

Select Policies from the user menu.
Select AI Context Rules.
Select Create AI Context.
Enter the following details:
- AI Context Name: A name that identifies the rule.
- Context: The guidance the agents read. Describe the codebase, the conditions to look for, or background about the project.
Under Scope, select the namespace the rule applies to. By default, the rule applies to all projects in the namespace.
To limit the rule to specific projects, use Inclusions:
- Click Add more under Inclusions.
- Select the projects you want to include.
- Click Update.
Optionally, enter the tags of the projects you want to include.
To exclude specific projects, use Exclusions:
- Click Add more under Exclusions.
- Select the projects you want to exclude.
- Click Update.
Optionally, enter the tags of the projects you want to exclude.
Click Create AI Context.

If a project matches both inclusions and exclusions, the exclusion takes precedence.

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 agents do not work from stale guidance. Edit a rule to update its name, context, or scope.

Select Policies from the user menu.
Select AI Context Rules.
Click the vertical three dots next to the rule you want to edit.
Select Edit.
Update the AI context name, context, inclusions, or exclusions.
Click Update AI Context.

Clone a rule to create a new rule with the same name, context, and scope.

Select Policies from the user menu.
Select AI Context Rules.
Click the vertical three dots next to the rule you want to clone and select Clone.
Update the AI context name, context, inclusions, and exclusions for the new rule.
Click Create AI Context.

Delete a rule to remove it from your tenant.

Select Policies from the user menu.
Select AI Context Rules.
Click the vertical three dots next to the rule you want to remove and select Delete.

Example AI context rules

Adapt the names and paths in these examples to your own code.

Authentication happens in another service

Authentication is handled upstream, so the agents stop flagging missing authentication in this service but keep reporting missing resource authorization.

Architecture: these services sit behind an API gateway. User authentication is
performed by auth-service before requests reach these handlers, and the verified
identity arrives in the X-Verified-User header, but only treat that as
authentication when route or middleware wiring shows it is required. Still report
missing tenant, ownership, role, or scope authorization in this service:
authentication upstream does not prove resource authorization here.

A dependency provides the sanitizer

A shared library sanitizes HTML, so the agents suppress XSS findings on output that passes through it while still reporting sinks that bypass it.

HTML output produced through github.com/acme/safehtml.Render or the
@acme/security-html sanitizeHtml helper is sanitized by our shared security library.
Do not report XSS when attacker-controlled text reaches templates only through those
APIs and no later code calls an unsafe raw-HTML sink. Continue to report direct
innerHTML, bypassRawHtml, template.HTML, or other sinks that skip the sanitizer.

A required authentication mechanism for every endpoint

Every protected endpoint must use a specific middleware, so the agents report routes registered without it and leave public routes alone.

All production HTTP endpoints under /api/v1 must require the RequireSessionAuth
middleware or an equivalent @RequireSessionAuth annotation. Endpoints under
/healthz, /readyz, /metrics, and /static are public by design. Report protected
/api/v1 endpoints registered without RequireSessionAuth, even when they call
downstream services that perform business-logic checks.

Tenant boundary fields

Specific fields enforce tenant isolation, so the agents report routes that scope queries by user instead of by tenant.

Tenant isolation is enforced with organization_id and customer_id. Any route that
reads or writes invoices, users, projects, findings, or package metadata must
constrain DB queries and service calls by the caller's organization_id or
customer_id. A user_id check alone is not sufficient for cross-tenant resources.

Custom admin model and low-noise scope

Admin actions need two separate checks and some directories are out of scope, so the agents catch incomplete admin checks and suppress findings in non-production paths.

Admin-only actions require BOTH the AdminSession middleware AND the security.admin
scope in token claims. Report handlers that check only one of these before modifying
users, roles, integrations, billing, or signing keys.
Files under tools/, scripts/, testdata/, generated/, and docs/ are not deployed to
production. Suppress findings there unless the vulnerable file is copied into a
runtime container image or consumed by production code.

Introduction

Setup & Deployment

Inventory & Insights

Scan with Endor Labs

Risk Remediation

Integrations

Secure AI Coding

Platform Administration

Best Practices

Research Open Source Risks

Trust & Compliance

What makes an effective rule

What not to include in a rule

Automatic context from repository files

Create an AI context rule

Manage AI context rules

Example AI context rules

​What makes an effective rule

​What not to include in a rule

​Automatic context from repository files

​Create an AI context rule

​Manage AI context rules

​Example AI context rules

What makes an effective rule

What not to include in a rule

Automatic context from repository files

Create an AI context rule

Manage AI context rules

Example AI context rules