Same analysis, your account: BYOK for Endor Labs AI SAST

Today, we're introducing bring your own key (BYOK) support for AI SAST and AI Chat in the Endor Labs AURI platform. With BYOK, AI model requests go through your own OpenAI, Azure OpenAI, Gemini, or Vertex AI account instead of ours. It’s built for organizations with strict data residency, privacy, and compliance requirements like those in financial services, healthcare, critical infrastructure, and other regulated industries.

This helps teams in regulated industries in three main ways:

1. Faster security reviews in regulated industries. Security reviews can stall on tools that send code to a vendor-selected LLM. With BYOK, Endor Labs uses the provider your organization has already approved.
2. Data handling and residency. Privacy, residency, and procurement requirements frequently specify where source-code analysis can be sent. BYOK lets you meet them with your existing provider agreement.
3. Model usage in your own records. AI model requests appear in the same usage records and controls your team already uses for other AI workloads. Security and platform teams can audit what gets sent to AI models without relying on a vendor's report.

In this post, we'll cover how BYOK works and how Endor Labs AI SAST finds 2.6x the real vulnerabilities of the leading frontier model and 4x the high-severity findings of the strongest pattern-based SAST tool.

How BYOK works

By default, Endor Labs AI SAST and AI Chat send model requests to our provider accounts. With BYOK, those model requests go to your OpenAI, Azure OpenAI, Gemini, or Vertex AI account instead. Additionally, if your provider lets you choose a region, like Azure OpenAI and Vertex AI, BYOK runs requests in the region you've chosen.

Turning on BYOK doesn’t change how AI SAST analyzes your code. AI SAST still uses the same frontier models, each tuned and tested for particular tasks, and we run continuous benchmarks so each task runs on the model suited to it. AI SAST still builds the call graph and dataflow model of your application, and it works wherever you already run scans: locally, on pull requests before merge, or in CI/CD.

BYOK is all or nothing. Once you configure a key, every model request Endor Labs makes on your behalf runs on your provider account or it fails. It never falls back to Endor Labs' credentials.

Every request goes through the Endor Labs AI Gateway, which applies these controls:

• Encrypted key store: provider API keys stored in the Endor Labs platform are encrypted, or you can pass them as environment variables during AI SAST scans so keys are never stored with us.
• Provider allowlist: requests go only to providers you've approved.
• Tenant isolation: your keys and requests are kept separate from every other tenant’s.

BYOK just decides whose account runs the model. What that model finds depends on what it's given to work with.

Why frontier models need security context

If you already have an approved provider, the obvious alternative is to hand the model your repository and ask it to find vulnerabilities. 

A frontier model reasons well about the code it reads, but it only reads a slice. A coding agent explores a codebase the way a developer greps through one: search, open a file, follow a hunch. Code is a graph, and the vulnerabilities that do the most damage live in its edges, like user input that crosses several files and layers before it reaches a query or sizes an allocation. On a large enterprise Java codebase, frontier models examined less than 10% of the security-relevant code.

Cost is the other problem. Using a general-purpose coding agent like Codex or Claude Code as a security scanner burns tokens in proportion to the size of your codebase. The agent greps, lists directories, and reads files to rebuild context it doesn't have, then re-sends that growing context at every reasoning step. That makes the bill hard to predict: it grows with every repository and every pull request, and one team running a per-PR security agent saw an $8,400 bill in its first month.

Deterministic context changes the math. In our token economics benchmark, we ran the same 34 security prompts (reachability, exploitability, prioritization, remediation) through the same model twice. The agent working from the raw repository used 79.5 million tokens. The agent given Endor Labs context used 6.6 million, 12x fewer. It also finished 2.8x faster.

What the benchmark shows

We benchmarked AI SAST against two frontier models (Claude Opus 4.7 and Codex GPT-5.5) and four traditional SAST tools, across eight real-world projects in Java, Python, JavaScript, TypeScript, C#, and Go. Our security research team hand-verified the ground truth. AI SAST found 192 real vulnerabilities, 2.6x the vulnerabilities of the strongest frontier model and 4x the high-severity findings of the strongest pattern-based SAST scanner.

The two usual approaches fail in opposite directions. Frontier models stay quiet but miss most of the code. Coverage explains most of the gap: AI SAST caught nearly twice as many weakness types as any other tool. Rule-based scanners read every file and reason about none of them. They flag what code resembles rather than what it does, and Semgrep OSS and OpenGrep each flagged more than 460 false positives.

The categories that separate AI SAST from pattern matching are the ones rules can't express: broken access control, IDOR, insecure design, and business logic flaws. Each depends on how a specific application handles authorization and trust, not on a fixed code shape. The benchmark post has the full methodology and per-tool results.

How AI SAST works

AI SAST builds an understanding of your application before it looks for flaws. Program analysis constructs a code context graph of the entire codebase, using the same call-graph and reachability engine behind Endor Labs SCA. A semantic index captures what the code is meant to do. AI SAST also reads Dockerfiles, Kubernetes manifests, Terraform, and the frameworks in use, so findings are scored against how the application actually runs. Specialized agents then work from that model:

• Detection agents trace user-controlled data from source to sink across files, functions, and even repositories, using the call graph and function summaries.
• Triage agents classify each finding as true positive, false positive, or unknown, with the reasoning recorded for audit. Confirmed findings carry an attack vector and exploit payload as evidence.
• Remediation agents propose a code fix written against the same context graph, so it targets the exact data flow the analysis traced.

The models reason over structured context instead of raw files, so each step sends the model what it needs rather than the whole repository. That gives AI SAST coverage a model alone can't reach, with less noise than pattern matching. It also keeps the LLM cost per scan low, which matters more once the bill is yours. The AI SAST whitepaper covers the architecture in depth.

A zero-day in a memory-safe language

To put AI SAST to the test, our security research team used it to review open source code across a variety of AI and infrastructure projects. One notable discovery was a vulnerability in buffa, a Rust library created and maintained by Anthropic and scanned using Claude Code Security. The vulnerability we discovered traced untrusted input into an unbounded heap allocation and found a zero-day, now CVE-2026-55407. Rust's memory safety rules out whole classes of bugs, and there was no dangerous pattern for a rule to match. Finding this one meant following data from where it enters the library to where it sizes an allocation, which is the source-to-sink reasoning AI SAST was built for.

What else has shipped

BYOK support isn’t the only feature we’ve shipped in the last few months. Other improvements include:

• Custom organizational context. Infrastructure as Code, repository files like AGENTS.md and CLAUDE.md, triage feedback, and uploaded threat models teach AI SAST how your application is deployed and what your team has already ruled on. See how AI SAST learns what matters to your organization.
• First-class C support. Buildless scans run in the IDE and on the PR, with no compiler to hook and no build to reproduce. See why AI SAST for C finds what other tools miss.

Because AI SAST sends the model structured context instead of whole files, scans stay fast and predictable enough to run on every pull request and in local developer scans, with no Endor-side cap on how much you scan.

Get started

BYOK is available now in private beta for Endor Labs customers. New to Endor Labs? Request a demo to see what AI SAST finds in your own codebase.