How NVIDIA Inception and a pair of NVIDIA RTX PRO Blackwell GPUs made it possible for us to build an AI code scanner that never sends a line of source code to a third-party provider.
Every AI-powered SAST tool built on a cloud model API, including most of the new entrants in this category, sends proprietary source code to a third-party AI provider. That is the exact data exposure risk a security tool is supposed to prevent. The answer to that paradox required us to build on local NVIDIA hardware from day one, and it led us to a fundamentally different philosophy about how AI security tools should work.
Local-first: not a feature, but a prerequisite
The paradox at the center of AI-powered security. Traditional static analysis (SAST) tools are built around pattern matching. They’re fast and deterministic, but fundamentally blind to context. They cannot tell you whether an unsafe function call is catastrophically exploitable or safely sandboxed. They cannot trace user input through three function calls and recognize it arrives unsanitized at a sensitive operation. They see syntax. They don’t understand semantics.
Large language models can close that gap, but every major LLM runs as a cloud API, and sending your source code to a cloud API is itself a security vulnerability.
The moment you send source code to an external AI API, your security tool becomes a security risk. We weren't willing to build that.
NVIDIA Inception made the alternative viable. Before writing a single line of Helix’s analysis engine, we made one architectural commitment: all AI inference runs on SafeHill’s own hardware, with no connections to third-party AI providers. When a customer submits code to the SecureIQ platform, it is analyzed entirely within our infrastructure, never forwarded to OpenAI, Anthropic, or any other external model provider.
Running a large-scale language model locally at production throughput demands hardware most companies don’t have in a rack. NVIDIA Inception gave us early access to the hardware, tooling, and reference architectures that turned that commitment into a production platform. Two RTX PRO Blackwell GPUs, the NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition and the NVIDIA RTX PRO 4000 Blackwell, now run the entire inference and training pipeline inside SafeHill’s infrastructure, with no external model calls at any stage.
The hardware that makes it real: Helix runs on two NVIDIA RTX PRO GPUs in SafeHill’s infrastructure. Together they power the entire pipeline, from vulnerability analysis to security enrichment to model fine-tuning, without a single call to an external AI provider.
Primary · GPU 0
NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition
Enrichment · GPU 1
NVIDIA RTX PRO 4000 Blackwell
Throughput that changes the workflow: The 96 GB of VRAM on the RTX PRO 6000 Max-Q Blackwell is not a luxury; it’s what makes the architecture viable. Running our primary inference model with FP8 quantization takes roughly 35 GB. That remaining headroom is doing real work: it supports the key-value cache for concurrent requests, serves the NVIDIA Nemotron embedding model that powers cross-function taint analysis, and leaves enough room to run fine-tuning on the same machine without pausing inference.
Three distinct AI workloads, one GPU, no external API calls at any stage. Scans that previously took 34 minutes on identical hardware now complete in 10.5 minutes. That 3.2x throughput improvement, achieved on the RTX PRO 6000 Blackwell Max-Q with FP8 quantization via vLLM, is the difference between a tool developers tolerate and one they actually use.
The promise is simple: when you trust SafeHill with your source code, it stays with SafeHill. It isn’t forwarded to a third-party provider to run inference. It isn’t stored by an AI vendor. It is analyzed by models we built and operate, on hardware we control, and the results come back to you.
The Philosophy: Introducing the Adversarial Intelligence Loop
Local-first infrastructure solves the trust problem. It doesn’t, on its own, solve the detection problem. The security industry has converged on a fragmented approach: SAST tools find potential issues, DAST tools attempt to confirm them, and humans review the output. Each stage is typically a separate product, a separate team, and a separate process. The outputs rarely feed back into the inputs. The tools don’t get smarter from what they find.
We think that’s the wrong architecture. The model that finds a vulnerability should learn from how that vulnerability was confirmed. The analyst who triages a false positive should feed that judgment directly back into the detection engine. Every finding, whether true or false, confirmed or dismissed, should make the next scan better. We call this the Adversarial Intelligence Loop.
Adversarial Intelligence Loop: AIL · SafeHill Inc., 2026 A closed security pipeline in which AI-powered static analysis, dynamic validation, and human expert review operate as a single integrated workflow, with every signal from every stage flowing back as labeled training data to improve the models that power the next iteration. The loop doesn’t just find vulnerabilities. It learns from them. |
The AIL is not a product feature. It is the architectural philosophy behind SecureIQ. Every component, Helix SAST, Sentinel DAST, the human validation workflow, and the training flywheel, is designed around the principle that security intelligence compounds when the loop is closed.
How the Adversarial Intelligence Loop works
The AIL has four stages. Each stage generates a signal. All signals feed the next training cycle. Nothing is discarded.
1. Helix SAST: AI-powered static analysis
Helix ingests the repository and runs an eight-stage analysis pipeline. Tree-sitter AST extraction across eight languages feeds 200+ pattern-based rules and a heuristic risk ranker, surfacing the highest-risk functions for LLM review.
The primary inference model on GPU 0 evaluates each function with CWE-specific prompts, reasoning about whether vulnerabilities are genuine, sandboxed, or guarded. A second adversarial LLM pass challenges every finding before it advances: is this actually exploitable, or is it a false positive?
Cross-function taint analysis using NVIDIA Nemotron embedding and reranking models traces data flow across file boundaries, surfacing multi-step vulnerabilities that span multiple files. The output is a deduplicated, confidence-scored, CVSS-enriched findings report.
2. Sentinel DAST: Dynamic validation
Sentinel takes Helix’s findings and attempts to prove them. Playwright-based dynamic test execution sends targeted proof-of-concept payloads against isolated instances of the target application, attempting to trigger the vulnerability under controlled conditions.
A finding that Sentinel can confirm is no longer theoretical. It is evidenced, with a working exploit, a response demonstrating exploitation, and a severity assessment grounded in actual behavior rather than code analysis alone. Findings that Sentinel cannot confirm remain in the report but are flagged for human review rather than being dismissed.
Every Sentinel attempt, successful or not, generates a labeled record: what payload was tried, what response was observed, and what verdict was reached.
3. Human validation: Expert review in the loop
Security findings that matter require human judgment. The AIL treats human review not as the end of the pipeline but as a signal-generating stage within it. When an analyst confirms a finding as a true positive, dismisses it as a false positive, or reclassifies its severity, that decision is captured as a labeled training record attached to the original Helix prompt and response.
This is the highest-quality label in the system: a verified human expert judgment, anchored to the exact code pattern and LLM output that produced it. The analyst’s decision feeds directly into the training corpus. The loop is closed.
4. The training flywheel: Every signal improves the next scan
Every LLM call in the Helix pipeline writes a training record: the system prompt, the function under analysis, the full model response, and the parsed findings. A labeling pipeline applies ground truth from three sources: true positives anchored to confirmed vulnerability discoveries and human analyst validation, false positives identified through Sentinel failure signals and analyst dismissals, and true negatives from clean-code examples.
The labeled dataset feeds QLoRA fine-tuning on our RTX PRO 6000 Max-Q, a training run of roughly five hours that produces a LoRA adapter which loads into vLLM at runtime with no restart and no downtime. The improved model runs the next scan. The loop tightens.
Why this is different from a feedback loop
A feedback loop improves a single process. The AIL improves three simultaneously. Every Sentinel confirmation makes Helix’s static analysis labels more accurate. Every analyst dismissal teaches the model what safe-by-context code looks like. Every training cycle produces a model that generates fewer false positives and misses fewer real vulnerabilities, which means analysts spend less time on noise, which means their remaining reviews are higher quality, which means the next training cycle learns from better signal. The loop compounds.
The role of the third model
The AIL does not use one AI model. It uses three. Helix is the first: a static analysis engine that reasons about vulnerability patterns in context, surfacing findings no pattern-matching tool could produce. Sentinel is the second: a dynamic validation engine that takes Helix’s findings and attempts to prove them with working exploits against isolated environments.
The third is different in kind. It is a large general inference model, trained continuously on everything the first two have ever done: every function Helix analyzed, every finding Sentinel confirmed or failed to confirm, every judgment a human analyst applied. That corpus feeds a fine-tuning cycle on the same RTX PRO 6000 Max-Q that powers production inference, and the resulting adapter reshapes how Helix reasons about the next scan. None of these three models calls an external API. All three run on NVIDIA hardware inside our infrastructure. The third model is what makes the AIL self-improving.
What the loop has found
22 vulnerabilities, under coordinated disclosure. Across four scanning campaigns covering approximately 200 open source repositories, including widely deployed AI agent frameworks, enterprise applications, and developer tooling used by millions, Helix has reported 22 previously undisclosed vulnerabilities under coordinated disclosure with affected maintainers. Of these, several have been validated by Sentinel with working proof-of-concept exploits. Findings span injection, deserialization, authentication bypass, and path traversal classes, with several targeting AI infrastructure that has become critical to modern application stacks.
Responsible disclosure, by the book. All disclosures follow SafeHill’s published Vulnerability Disclosure Policy, benchmarked against Google Project Zero, Rapid7, and CERT/CC guidance. Full technical details will be published once the 90-day embargo elapses.
The findings are the training data. The 22 confirmed discoveries serve as the highest-confidence training anchors in the flywheel. Each has a proof-of-concept script, a verification log, and precise file/function/CWE identification, enabling exact matching against Helix prompt logs to label those examples as verified true positives. These anchors are significantly upsampled in each training run to ensure the model retains its ability to recognize real vulnerabilities as it learns to suppress false positives.
A model that gets better at the job with every job it runs
43,000+ training records and growing. Across four scanning campaigns, continuous production scans, a focused AI framework campaign, an enterprise application campaign, and a language gap-filling campaign, we have accumulated more than 43,000 training records across approximately 200 repositories and seven programming languages.
| Campaign | Focus | Records |
|---|---|---|
| V3 Continuous | Ongoing production scans, mixed client repos | 17,486 |
| V4 AI-Focused | Agent frameworks, RAG systems, AI tooling | 13,137 |
| V5 Enterprise | Auth systems, ERP, CMS, data platforms | 2,700 |
| V6 Gap-Filling | Go, Java, PHP, Ruby, Rust coverage | 10,394 |
| Total | ~200 repositories · 7 languages · 25+ CWE categories | 43,717 |
What the first training run taught us. Our first fine-tuning run demonstrated that the approach works, but also surfaced a critical lesson: class balance matters as much as volume. With 92% of training examples being true negatives, that first model learned to suppress output too aggressively, creating blind spots in some codebases while dramatically reducing false positive rates in others.
How the second run is different. Our second training run, completed in April 2026, corrects this. The training set was rebalanced: roughly 68% corrected false positive examples (code that looks dangerous but isn’t), 25% true negatives, and 7% verified true positives with significant upsampling. This balance teaches the model the nuance that separates a real vulnerability from a safe-by-context pattern, exactly the judgment a senior security engineer applies when triaging a report.
The progressive fine-tuning roadmap
Each scanning campaign builds the dataset that unlocks the next stage of training. The 96 GB VRAM on the RTX PRO 6000 Max-Q makes this progression possible on a single machine, without migrating to cloud compute and without routing any customer data through a third-party provider.
NOW
QLoRA
~6 MONTHS
Full LoRA
~12 MONTHS
Partial Fine-Tuning
LONG TERM
Continued Pre-Training
The argument: why the loop matters more than any individual scan
Point-in-time tools don’t compound. Most security tools produce a report. The report is reviewed. Some findings are fixed. The tool runs again next quarter and produces another report. Nothing the tool learned from the last run makes the next run smarter. The tool is as capable on day one as it is on day one thousand.
The AIL is different by design. Every scan the SecureIQ platform runs makes the next scan more accurate. Every false positive dismissed by an analyst narrows the noise floor. Every Sentinel confirmation anchors a new true positive in the training corpus. Every training cycle produces a model that has seen more of the vulnerability landscape, not just in code samples, but in real production codebases, confirmed by real exploits, reviewed by real security engineers. The system gets harder to fool. Adversaries don’t.
This is only possible because the loop is closed. If any stage of the AIL sent data to an external provider, the loop would be open. Training data would flow to a third party. Human analyst decisions would inform someone else’s model. The compound intelligence would accrue to a vendor, not to our customers. The local-first architecture isn’t a constraint on the AIL. It’s what makes the AIL possible.
The NVIDIA Inception program gave us the hardware to close the loop at production scale. The RTX PRO 6000 Max-Q runs the inference. The RTX PRO 4000 runs the enrichment. vLLM makes it fast enough to be practical. NVIDIA NeMo Retriever provides semantic search without an API key. The training flywheel runs on the same GPU that serves the production model. Every component of the AIL lives on NVIDIA hardware inside our infrastructure, and every scan makes all of them better.
The research is just beginning. The 22 vulnerabilities we have reported are the opening output of the Adversarial Intelligence Loop, not its ceiling. As embargoes elapse over the coming months, we will publish detailed write-ups, proof-of-concept code where appropriate, and post-mortem analysis of what Helix and Sentinel caught that existing tools missed. Follow our research blog or sign up for updates to be notified when those findings go public.
Source code that stays with you. Detection that compounds over time.
About the Author
Trevor Baines is Director of AI Engineering at SafeHill, a cybersecurity AI company building local-first SAST, DAST, and CTEM-driven products powered by owned GPU infrastructure. With a background in offensive security and application penetration testing, he focuses on the intersection of cybersecurity, AI, and operations, and has led the company's AI R&D efforts including its Helix engine and NVIDIA Inception partnership.