FENRIR: AI Hunting for AI Zero-Days at Scale

FENRIR: AI Hunting for AI Zero-Days at Scale

Speakers: Peter Girnus (Senior Threat Researcher, TrendAI); Derek Chen (Vulnerability Researcher, TrendAI)

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 3–4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=c6_bRzHCf3U

Reading time: ~9 minutes

TL;DR

TrendAI's Zero Day Initiative team built FENRIR, an AI-powered vulnerability discovery engine that combines traditional static analysis with a cascade of LLM triage stages to find zero-day bugs at scale. In production, FENRIR has delivered a 2.5x increase in vulnerabilities discovered, 80% fewer false positives, 70% faster disclosure, and a 3x productivity increase — while submitting over 60 high or critical CVEs and with more than 100 in pre-disclosure.

Introduction

Finding zero-day vulnerabilities is expensive, slow, and deeply dependent on scarce human expertise. The traditional workflow — static analysis generating thousands of findings, a human researcher manually triaging each one, writing proof-of-concept exploits, and preparing disclosure packages — does not scale. And as the AI ecosystem itself expands into a massive, largely unaudited attack surface, the mismatch between the scale of the problem and the available human capacity has become acute.

Peter Girnus, Senior Threat Researcher on TrendAI's Zero Day Initiative, and Derek Chen, a vulnerability researcher on the same team, presented FENRIR at [un]prompted 2026. FENRIR is a production zero-day discovery engine that has been running for over a year. It doesn't replace human researchers — it's designed explicitly as a force multiplier, handling the volume and speed work so humans can focus on the judgment calls that matter.

▶ Watch: Introduction to FENRIR and the Unified Platform (00:00)

The Broader Platform: FENRIR and MIMIR

FENRIR exists inside a unified platform that includes both offensive and defensive components. The offensive side is FENRIR itself — zero-day discovery. The defensive side is a separate component called MIMIR, focused on n-day vulnerability research and threat tracking. The two form a bi-directional intelligence feedback loop.

The NVIDIA example Girnus gave at the start of the talk illustrated this loop concretely. FENRIR discovered a command injection vulnerability in NVIDIA's Isaac Group robotics framework. That finding was immediately tracked in MIMIR's repository. When NVIDIA released the patch, 23 autonomous LangGraph agents in MIMIR went out to the advisory page and the exact code commit, then re-scanned the repository. FENRIR was then handed the results — and found two more bugs NVIDIA had introduced in the patch, including a new vulnerability and a patch bypass.

This is the loop working as designed: zero-day discovery generates n-day tracking data, which feeds back into zero-day discovery for the next iteration.

▶ Watch: FENRIR + MIMIR Bi-Directional Feedback Loop (00:00)

Stage 1: Static Analysis — No Tokens Spent

FENRIR's pipeline is a cascade architecture: each stage is more expensive than the previous, and the goal at each level is to eliminate findings before they reach the costlier next stage.

Stage 1 is pure static analysis using four tools in sequence. No LLM tokens are spent at this stage — everything runs on traditional analysis.

• YARA-X: The fastest pre-filter. Scans millions of lines of code in seconds, generating initial signals at low cost. Used to find real vulnerabilities in the wild before. Well-suited for pattern matching at scale.
• Semgrep: More precise than YARA, especially effective with large rule sets. Narrows the candidate set further.
• CodeQL: Data flow and taint analysis. Heavier than the previous tools but produces high true-positive conversion rates on the findings it flags.
• SpotBugs / FindSecBugs: Java binary analysis when needed.

A critical property of using multiple tools is multi-scanner correlation: when YARA-X, Semgrep, and CodeQL independently flag the same CWE class at approximately the same code location (within about 15 lines), that convergence is treated as strong signal. It not only increases confidence but provides rich context for the downstream LLM stages.

▶ Watch: Stage 1 — Static Analysis Cascade (06:01)

Stage 2: L1 Triage — Fast LLM Filters Obvious False Positives

The L1 triage stage uses a fast but capable LLM — Sonnet — with a pre-allocated static context window of 50 lines of code per finding. Its only job is filtering out obvious false positives. It is making no verification decisions.

The prompting approach matters significantly here. Instead of asking "is this a false positive?" the model is asked "could this possibly be CWE-79?" That CWE-specific framing performs substantially better than generic prompts. The stage is deliberately biased toward recall: it's acceptable for some false positives to pass through, but dropping a true positive is not acceptable.

The impact is substantial. Over 60% of findings are eliminated by a single Sonnet call, preventing them from flowing into the much more expensive L2 stage. The team's evaluation harness has confirmed that L1 has not dropped a single finding that would have been classified as a true positive by L2.

Model sizing matters. The team tried models in the 0.3–0.6B range — they dropped true positives consistently and were unusable. Opus works, but it's slower than Sonnet and limits throughput without providing enough additional benefit at this stage. Girnus quantified the operational impact: "50 lines of code instead of 12 turns of Opus — that is really a no-brainer."

▶ Watch: L1 Triage — Architecture and Lessons (08:01)

Stage 3: L2 Deep Agentic Triage — Where the Serious Work Happens

L2 is the most expensive stage and the one that actually produces confirmed vulnerabilities. An Opus agent is deployed into an isolated, secure sandbox environment with full execution and write privileges. It can write Python scripts, run them with Bash, build call graphs, trace data flows across multiple files, and explore the codebase autonomously.

The agent has full code context provided, along with proof-of-concept generation capability. Two key design decisions define the stage:

Reachability-first triage. Code that isn't reachable — documentation, test cases, dead code paths — is filtered out immediately. It has no security impact regardless of what patterns it contains.

Built-in reflection. The agent is required to argue against its own conclusions. Without this, models tend to do shallow reasoning and call a finding resolved without truly verifying it. The reflection mechanism forces the model to fight itself on whether a finding is a false positive. "Sometimes what we are observing is the model kind of cheats," Chen noted. "They do really shallow reasoning and just call it a day. But this built-in reflection really reduces that."

The cost at L2: a median of 61 cents per finding, around 100,000 tokens. Complex cases with multi-file data flow in large repositories can scale to over 1 million tokens. Accounting for false positives that get filtered out, the cost per confirmed true positive works out to approximately $8.80. Girnus acknowledged that's not cheap — but substantially more affordable than the traditional manual approach.

▶ Watch: L2 Deep Agentic Triage — Architecture (10:01)

Production Results: Numbers That Matter

Since FENRIR reached production, the team has measured:

• 2.5x more vulnerabilities discovered
• 80% reduction in false positive rates
• 70% faster disclosure rate
• 3x overall increase in team productivity

The pipeline compression: 500 raw static analysis findings → ~250 post-L1 → 10–25 high-confidence true positives per run. Each true positive comes with an auto-generated vulnerability report including root cause, impact assessment, and a crafted proof-of-concept. The human's job at the end: validate exploitability, review severity, submit to the vendor.

From those true positives, the team has submitted over 60 CVEs — all high or critical severity. The team explicitly doesn't pursue medium-severity findings ("we can use the Script Kiddies to find those"). Over 100 CVEs are currently in ZDI pre-disclosure, and approximately 3,000 are pending review.

During the presentation itself, the team received an alert that a LangChain CVE they had found had just been patched. "As we're talking, Fenrir is doing work for us."

▶ Watch: Production Metrics — CVEs and Productivity Results (14:01)

What Makes FENRIR Distinctive

Several architectural choices set FENRIR apart from simpler AI-assisted triage approaches:

Multi-scanner correlation algorithm. Tool convergence produces confidence scores. When multiple scanners independently identify the same CWE at the same location, that's high-confidence signal that gets surfaced earlier.

Kill-chain analysis system. Exploit path modeling identifies the riskiest attack surface first, rather than treating all findings equally.

Weighted context generation. An algorithm dynamically allocates tokens to different parts of the analysis — rather than spreading context uniformly across the codebase. This is critical for efficient operation on large repositories.

Dynamic priority scoring engine. The most severe and exploitable findings surface for immediate disclosure, rather than requiring a human to sort through everything.

Adversarial interrogation. One LLM asks another to try to disprove that a finding is a real vulnerability. "Kind of like at a bug bounty program where the triage team is skeptical of what you're submitting," Chen described. This two-agent check reduces false positives at the human review stage.

▶ Watch: Distinctive Architecture Features (14:01)

FENRIR Pointed at the AI Ecosystem

The team made a deliberate choice to turn FENRIR against the AI ecosystem itself. "The attack surface for AI components is absolutely massive," Girnus noted. AI frameworks, tooling, and infrastructure have grown rapidly with limited security scrutiny — and FENRIR's ability to scan at scale makes it well-suited to this target class.

With the more advanced reasoning capabilities of recent models, the team has started tackling memory corruption bugs — an area that was impractical to address earlier when context windows were smaller. The next frontier: vulnerability discovery across organizational codebases rather than individual open-source repositories, surfacing security boundaries and architectural quirks unique to how specific organizations have structured their code.

▶ Watch: AI Ecosystem as Target and Future Directions (16:01)

Live Demo: Aeon UI Scan Results

The team started a live scan at the beginning of the talk and checked back on it during the Q&A section. The target was Aeon UI, an open-source project. Results from the console:

• Static analysis found 122 findings
• L1 filtered out 37 of them
• L2 produced 21 true positives

One example finding shown (with identifying details redacted): a path traversal vulnerability, presented with specific line numbers, reasoning from the agent, the counterargument it considered, its recommendation, and impact assessment. The console also included a chat interface allowing human analysts to talk directly with the LLM triager — treating it as a security researcher colleague to bounce ideas off.

▶ Watch: Live Demo Results — Aeon UI Scan (18:01)

Notable Quotes

"Fenrir is designed to not replace human researchers, but to be a force multiplier." — Peter Girnus (02:00)

"50 lines of code instead of 12 turns of Opus — that is really a no-brainer." — Peter Girnus, on L1 triage economics (10:01)

"Sometimes what we are observing is the model kind of cheats. They do really shallow reasoning and just call it a day. But this built-in reflection really reduces that." — Derek Chen (12:01)

"As we're talking, Fenrir is doing work for us." — Peter Girnus, after receiving a live CVE patch alert mid-presentation (16:01)

"Everyone has experience giving an entire repo to an LLM and trying to say 'just find vulnerabilities.' That doesn't work." — Derek Chen (06:01)

Key Takeaways

• Cascade architecture is essential. The most expensive analysis (Opus agents in sandboxes) must only see pre-filtered candidates. YARA-X → Semgrep → CodeQL → L1 Sonnet → L2 Opus is a deliberate cost management strategy, not just a quality stack.
• CWE-specific prompting outperforms generic prompting. Asking "could this be CWE-79?" performs significantly better than asking "is this a false positive?" at the L1 stage.
• Forced reflection catches lazy reasoning. Without a mechanism forcing the agent to argue against its own conclusions, models do shallow triage and call findings resolved prematurely.
• Multi-scanner correlation provides confidence and context. When independent tools agree on the same location and vulnerability class, that convergence is strong signal for both confidence scoring and downstream LLM context.
• The AI ecosystem itself is a target. AI frameworks and infrastructure have grown rapidly without proportional security scrutiny — they're an underexamined attack surface that static analysis can help cover at scale.

Slides Reference

Slides are available as 2026-04-04-D1-S1-13-57-FENRIR-AI-Hunting-for-AI-Zero-Days-at-.pdf. Key slide topics include: the FENRIR + MIMIR unified platform architecture, the bi-directional intelligence feedback loop, the four-stage cascade pipeline (static analysis → L1 → L2 → human), the multi-scanner correlation algorithm, production metrics (2.5x discoveries, 80% fewer false positives, 70% faster disclosure, 3x team productivity), CVE submission statistics (60+ submitted, 100+ in pre-disclosure, 3,000+ pending), and the live Aeon UI demo console output.