Skip to main content
Pattern-based SAST rules cannot express every class of vulnerability. You can run a SAST scan with an AI detection agent to identify security vulnerabilities that traditional rule-based SAST cannot express. Endor Labs’ AI SAST detection agent reads your source code directly and uses a large language model (LLM) with full-repository context to find issues that pattern-based rules miss, such as multi-step logic flaws, context-dependent authorization issues, and bugs that only become exploitable when functions are composed across files. Unlike the AI SAST triage agent, the detection agent generates new findings directly and treats them as true positives. Each finding is labeled with an AI finding tag and includes the vulnerable code location, a data flow trace from source to sink, an attack vector with a concrete exploit payload and reproduction steps, an assessment of existing security controls, and a CWE classification with severity based on the context of your application. To run an AI SAST detection agent scan:
  1. Enable the AI SAST - Detection rule in finding policies.
  2. Run the following command. 
    endorctl scan --ai-sast --path=/path/to/code -n <namespace>
To view the findings generated by the AI detection agent scan, see View AI SAST detection agent findings.

​
Language support

The AI SAST detection agent supports the following languages:
  • C
  • C++
  • C#
  • Go
  • IaC YAML, such as Terraform
  • JavaScript
  • Kotlin
  • Python
  • Ruby
  • Rust
  • Scala
  • Swift
  • TypeScript
  • Skills: AI agent skill files, such as AGENT.md and CLAUDE.md

​
AI detection process

The AI detection agent uses a large language model (LLM) with full-repository context to systematically discover vulnerabilities through the following steps:
  1. Index the repository: Scan the entire codebase and build a semantically searchable representation. The agent generates file hashes, function hashes, and embeddings to capture the intent of every function, and stores them with metadata such as callers and file locations. Maximum coverage at this stage minimizes false negatives later in the pipeline.
  2. Analyze application context: Read deployment files such as Dockerfiles, Kubernetes manifests, and CI configurations to understand how the application is exposed and which framework mitigations exist. Skip files that cannot produce SAST findings, such as non-executable files. The agent uses these prioritization signals to focus security analysis on the functions that matter.
  3. Run security analysis: Review the behavior of prioritized code using LLM-based reasoning with full-repository context. The agent traces reachability to confirm whether vulnerable code paths are actually called, follows source-to-sink chains across functions and files, and detects sanitizers or other stopping logic that may prevent exploitation.
  4. Generate findings: Emit confirmed vulnerabilities as new findings labeled with the AI finding tag and treated as true positives. Each finding includes an attack vector with a concrete exploit payload and reproduction steps that show how the issue could be triggered, and a suggested code-change diff that shows how to fix the vulnerable code.
  5. Classify findings: Map each finding to a CWE and assign a severity based on the context of the application rather than the CWE category alone.

​
View AI SAST detection agent findings

The AI detection agent generates new SAST findings by identifying security vulnerabilities beyond traditional rule-based detection. Findings generated by the AI detection agent are labeled with an AI finding tag, the CWE associated with the vulnerability, and a CVSS-style severity computed from the application context. To view AI SAST detection agent findings:
  1. Select Findings > SAST from the left sidebar.
  2. Use the Attributes filter and select Yes under the AI SAST filter to view findings generated by the AI detection agent.
  3. Select a finding to view the details.
    • Info: Displays when the finding was first detected.
    • Details: Identifies where the finding is identified and its details.
      • Project: The project in which the finding was generated.
      • Location: A link to the exact file and line in the source repository where the vulnerable code is located.
      • AI Finding Title: A short, agent-generated title that summarizes the vulnerability.
    • Description: The file path with line numbers and the relevant code snippet for the vulnerable code.
    • Explanation: The agent’s full analysis of the finding.
      • Summary: Explanation of the vulnerability, including the affected function, the untrusted input it consumes, and the potential impact.
      • Data Flow: A table that traces the issue from source through propagation to sink, with the file location and the code or variable involved at each stage.
      • Exploit Reproduction: Concrete evidence that the issue is exploitable.
        • Exploit Path: Chain of code locations that an attacker can traverse from the entry point to the vulnerable sink.
        • Steps to Reproduce: Ordered steps that show how to trigger the vulnerability.
        • Sample Input: Example payload that triggers the issue.
        • Concrete Values: Specific values such as host, port, and raw and encoded payloads used to reproduce the exploit.
        • Remediation Guidance: Description of the recommended fix and a code diff that applies it.
      • Security Controls: A table that lists existing controls such as input validation, sanitization, access control, and other relevant protections, with a status of present, missing, weak, or unknown and a short rationale.
      • Verification Scorecard: A table that lists each criterion the agent verified, the verdict, such as confirmed, or not confirmed, and the evidence drawn from the code that supports the verdict.
      • Classification: The final classification of the finding, such as TRUE_POSITIVE.
      • Severity Scoring: A CVSS-style table that lists scoring factors, the assigned value, a rationale, and a numeric score, along with the adjusted total. The scoring factors are:
        • Attack Vector: How the vulnerability is reached, such as over the network, on an adjacent network, locally on the host, or with physical access.
        • Attack Complexity: How much effort or favorable conditions an attacker needs to successfully exploit the vulnerability.
        • Privileges Required: The level of access an attacker must already have before they can exploit the vulnerability.
        • User Interaction: Whether a separate user must take an action, such as clicking a link, for the exploit to succeed.
        • Confidentiality: The impact on the secrecy of data if the vulnerability is exploited.
        • Integrity: The impact on the trustworthiness and correctness of data or system state if the vulnerability is exploited.
        • Availability: The impact on the availability of the affected system or service if the vulnerability is exploited.
      • Severity: The final severity level assigned to the finding, such as Critical.
    • Remediation: Summary of the recommended fix and a code diff that applies it.
    • Metadata: Contains classification details such as the CWE ID, affected languages, and SAST tags applied to the finding.