Agentic SAST: Building an AI Pipeline for Rule Synthesis and Root-Cause Vulnerability Analysis

Danila Sashchenko at AI Engineer Melbourne 2026

This presentation is part of a premium event, 'AI Engineer Melbourne 2026' available exclusively for puchase. Learn more and

Speaker Introduction and Talk Overview

The speaker introduces himself as a security engineer at TikTok with a background in forensic security engineering and application security leadership. He outlines the structure of his talk on a product called 'Electrification,' promising to cover the problem it solves, its architecture, and what has worked versus what hasn't.

The Electron.js Security Problem at TikTok

The speaker explains that TikTok relies heavily on Electron.js-based desktop applications, which introduce serious vulnerabilities like remote code execution via simple link clicks. He reveals that for five years prior, no one had focused on securing these applications, and once he began pen testing, he realized the sheer volume of code made manual coverage impossible, prompting the need for an automated solution.

From SemGrep to LLM-Powered Vulnerability Detection

The speaker describes the evolution of their CI/CD pipeline, starting with basic SemGrep regex-based scanning that proved insufficient due to triage overhead. They then pivoted to using large language models to generate SemGrep rules, which worked well but created a new problem: a huge volume of findings requiring verification, leading to the development of a full agentic multi-agent system for finding, validating, and exploiting vulnerabilities.

Four-Node Agentic Architecture Overview

The speaker introduces the high-level architecture of the pipeline, consisting of four primary nodes: an orchestrator, scanner, validator, and exploit developer. He notes that the talk will focus mainly on the validator and overall pipeline flow.

Pipeline Walkthrough: Repository Intake to Scanning

The speaker details the initial pipeline steps, where users specify repository information, branch names, and access keys, and select whether to scan Electron.js applications or TypeScript/Node.js web servers. He explains how the repository intake node chunks files, analyzes git structure, and estimates the information needed for LLM context windows before pattern-based vulnerability searching begins.

SDK Interaction and Vulnerability Formatting Nodes

The speaker describes how the pipeline interacts with an SDK hosted in a separate Kubernetes cluster using LangChain and LangGraph to create dynamic vulnerability-scanning pipelines. He explains that a subsequent node reformats vulnerability data into a unique structure that helps the next model interpret findings more efficiently.

Confidence Scoring and Repository-Wide SemGrep Validation

This segment covers the verification node that assigns a mathematical confidence score to each finding, triggering security engineer notifications when scores exceed 65%. The speaker explains that validated findings generate SemGrep rules for fast, repository-wide scanning, avoiding the slower process of using LLMs repeatedly for the same vulnerability type.

Vulnerability Runner and Elastic Data Pipeline

The speaker explains the runner node's role in monitoring scanning jobs, fetching results, and converting findings into mathematical vectors to classify vulnerability types. This structured data is compacted into JSON and sent to Elastic, enabling downstream updates to the Electron.js SDK based on real vulnerability patterns.

The Role of the SDK in Preventing Insecure Code

The speaker emphasizes that the product isn't just a scanning pipeline but also includes an SDK designed to prevent developers from introducing insecure Electron.js code in the first place. He notes that since developers prioritize shipping features over security, the SDK acts as a guardrail against risky coding practices.

Deep Dive: Sink-Source Chain Building in Verification

The speaker details the verification pipeline's core mechanism, comparing it to a doubly linked list where vulnerabilities are traced from 'source' to 'sink.' He explains the challenge of determining which end is which and how the system attempts to build a complete chain to confirm a vulnerability's validity.

Generalization, Exploit Generation, and Final Judgment

The speaker walks through the later verification stages, where vulnerability chains are unified into prompts for exploit generation, checked for filters that might block exploitation, and ultimately mathematically evaluated by a 'final judge' node. He also highlights the importance of generating real-time harnesses to prevent agents from misclassifying vulnerability types, such as confusing server-side request forgery with open redirects.

Successes: Accurate Detection, SDK Remediation, and Rule Generation

The speaker shares what has worked well, including accurate sink/source detection that uncovered real remote code execution vulnerabilities across large codebases. He also highlights the SDK's effectiveness in blocking insecure features (illustrated by a developer's real-world encounter) and the reliability of LLM-driven SemGrep rule generation.

Ongoing Challenges: IPC Exposure, Sink Brute-Forcing, and Context Windows

The speaker outlines three unresolved challenges: mapping exposed IPC sockets in Electron.js apps, the need to brute-force potential sinks and sources when relationships are unclear, and managing limited context windows for scanning massive or minified codebases. He mentions experimenting with Google's vectorization and quantization algorithms to improve context handling, noting promising but still-in-testing results.

Closing Remarks and Contact Information

The speaker wraps up the presentation by sharing a QR code for LinkedIn connections and inviting audience members to ask questions after the talk, thanking everyone for attending.

Hello. Hello. Nice. Really glad to see everyone here. Yeah. As mentioned today, I'm gonna tell you about the product which we built for TikTok, which we utilized for basically some of the business lines already. Yeah. So a little bit more about me. Actually, before I worked as a forensic security engineer, and now I work as a security engineer in TikTok.

And before this, I also worked as application security lead in a Russian startup. And little bit about what we're going to talk today. So today, we're going to talk about the big product I built for the last half of the year, I would say. This product called electrification, very fancy name.

So what basically I'm going to tell today, I will divide my talk into three topics. First one is a problem. I will try to describe why and what's the reason why we built the product. After this, I'll come up with architecture, how it all works on the back end, and I will try to introduce you to the different parts of the product itself.

And after this, the last but not least, I will try to show you what actually works and what doesn't work. Okay. The problem scope is that in TikTok, we're using lots of Electron. Js based applications. Electron. Js, it's for your information. It's a framework which allows you to use Chromium or basically Chrome browser to create desktop applications.

What does it mean? It introduces lots of vulnerabilities. For example, sometimes you can just click a link, and it will allow someone to execute code on your host, which is pretty bad. And because of this, we just needed to create something. And this is not the primary reason. For the five years in TikTok previously, nobody really paid attention for the security of electronic JS applications.

So when I transferred to the security engineering, one of my primary focuses was desktop applications. And after this, I started to do a pen test, discover vulnerabilities. I understood that it's not possible to cover such amount of code lane code lines because it's just too huge. The volume is just unreal. And because of this, I basically started creating the product.

It all began from the CICD pipeline, very basic CICD pipeline. In TikTok, we utilize one thing called SemGrep. SemGrep is an engine which allows you to scan for vulnerabilities by basically providing regex patterns. It was very basic. We understood that it's not going to work, not going to help us a lot because you need to triage a lot and also write lots of rules, lots of patterns.

So we switched to something else. We tried utilizing large language models to basically generate SemgraP rules for us. And we understood that actually it works. It works pretty good, but at the same time, there is one huge problem, a very big volume of findings, and we need to verify them. At this point of time, it was already a v one, as they call it.

And now we basically created the full pipeline and the full product, which is, as described here, is a full agentic multi agent system which finds vulnerabilities, validates them, create exploits, and currently working on something else basically dynamically validate vulnerabilities, but not about this today.

Architecture of the entire pipeline based on the four nodes. One of the nodes is a primary node, is a orchestrator. After this, there is a scanner, validator, and exploit developer. Today, we're going to, you know, focus only on a validator and on a own overall pipeline, but most of the details are basically here already. So let's begin with a full pipeline architecture.

First things first. It's basically when user specified some necessary information. Next three information is a branch name, repository name, and such information like access keys. And there is very, very interesting thing, which allows you to specify which products will be scanned.

For now, we only support electron JS applications and web servers, which are based on TypeScript and Node. Js. Just because of the harnesses and everything what was introduced for the Electron. Js, it is applicable for the web servers, which are written in a TypeScript as well. After this, all of this information is applied to the node number two, which is called, yeah, repository intake and scanning, and node number two itself responsible for the entry point of engine.

This entry point of the engine, it tries to chunk all of the information provided from the repository. For example, we're just trying to understand how much files is specified by the pattern. We're also trying to find the pattern because the git itself wait. It's utilizing git. Git itself has a structure which allows us to see which directories a user trying to scan.

And And we're trying to understand how much files it will produce, how much information it will require from LLM because, as we all know, the context window and everything is not infinite. So the yeah, from here on, we're just trying to find the vulnerabilities by pattern, and we're trying to understand if vulnerabilities really exist in the next few steps.

So the step number three, it's basically interaction with our SDK, which is hosted in another Kubernetes cluster. And what it allows us to do is basically allows us to provide prompts. And we're utilizing langchaining langgraph to communicate with the models and to create dynamic pipelines for the vulnerability scanning. After this, we're going into node number four.

Node number four allows us to take information which was provided from the node number two, basically about vulnerabilities, and put them into the very unique format, which will allow the next model to interpret the vulnerability information in a better way. In a better way because the model will just understand it and will work in a more efficient way.

Next, we're going to the node number five, which is responsible for the verification and pattern search. I'm going to tell about this node on the next slide. But long story short, because of the volume of the findings, we need to understand how to verify vulnerabilities. And this node is basically responsible for the verification for every vulnerability.

From what what are we getting from this node is we're getting a confidence score, which is based on the some mathematical equations. And if the confidence score is basically more than 65%, what we're trying to do is we're trying to notify security engineers because probably something valid was found.

And after this, we're trying to generate semgrub rules and initiate the scanning of the entire repository. Why we're doing this? It's because when using LLM, first of all, it's not very fast. And when you're trying to scan the entire repository for the vulnerability, especially for the same vulnerability, it may require a little bit more time than you think.

And semgrub works in a pretty fast way because it's just a grep and it runs the grep for entire repository and generates reports for you. So basically, no need to, you know, LLM utilization. After this, there is a node number seven, which is runner, vulnerability runner, which is a very important part of pipeline because it's a runner which monitors the basically every job.

And when the job finished, what happens next is a runner tries to fetch information about the job. It tries to create vectors, mathematical vectors from the every found vulnerability to understand which type of vulnerability was found. And after this, it basically compacts everything into the JSON and sends it to the Elastic.

And from the Elastic perspective, we basically receive information like vulnerability type, vulnerability name, file name, everything what is important for us. And from now on, we can basically modify our SDK for the ElectronJS. A very important part about this product is that it's not only the pipeline, but also SDK.

So one of the ways to not have any issues with electron j JS based applications is just not to not allow developers to do some creepy, creepy stuff. You know? Because developers, they are not security experts. They just need to ship new features. Business requires new features. There is nothing to do with security.

But if you introduce SDK, yeah, you're basically not allowing them to do any creepy stuff. Second part is a verification began pipeline. There is lots of magic going on here. And yeah, let's just start from the very beginning of this pipeline. As I told before, in the beginning, we're trying to scan the vulnerabilities. And how it works is there is a file, let's say file A, and what goes on there is we're just going for the entire file and trying to find vulnerabilities by the patterns.

And these patterns, they are determined using skills, using prompts, and, of course, fine tuning because we're trying to fine tune models based on the vulnerability and patterns, new patterns, old patterns, everything. So when vulnerability is found, what happens next is it's submitted to the verification pipeline, and here we can see the number two.

It's a start of the verification pipeline. If you guys familiar with the type called double linked list, it will be very easier to under well, will be very easy to understand what's going on here. So here, we're trying to find out what is sync, what is source of the vulnerability. And by determining what is sync and what is source, we can understand and create a double linked list structure.

Sync and source is basically where the vulnerability is found and what it can cause. Sometimes the tricky thing is that we don't really know if we are the sync or we are the source. This is why we need to kind of build or try to build double linked list.

And if it's a build, that's good. We have the entire chain. If it's not built, we can try to understand the reason behind it. But, yeah, after this, when we try to build the entire chain from the sink to source, we try to put it to entire the entire chain to the next pipeline, to the next pipe or to the next node, which is called unify and generalize.

What we're doing here is we take information about the vulnerability, about the chain, and trying to transform it to the very, very easy prompt for the next model so the next model will understand what is required, what was the issue. And from now on, it can create some sort of a filter by bus exploit and also the exploit itself.

So after the generalization and after creating a prompt, dynamic prompt, we are submitting information to the node number six number five. Sorry. Resolution is node number five, where information from the about the vulnerability, information about the general finding is submitted to the model, and model tries to understand if there are any filters in the chain.

So filter basically can prevent your exploit from, you know, being exploited. And after this, if there is no filters, everything should work, we're generating exploit, and we're submitting the entire chain, entire information to the final judge. Final judge is a basically it's literally judge. It gets information about the chain sourcing, about the exploits, about the filters, if they exist or not.

It goes through the every file. It goes through every finding, every node in the doublink list. And from now on, it tries to mathematically prove if the vulnerability really exists, if exploit should work, if exploit really synced to the vulnerability, and if filters will prohibit this exploit from running. The interesting thing about this pipeline is that for every step, we're generating harness in real time.

Because if you don't do this, agent can not understand you in some cases. For example, there are two different types of vulnerabilities when you can make requests from the server side. And agent most likely will think that it is not the server side request for durability. It will think that it's some sort of open redirect or something else. And to basically restrict agents from doing something like this, we're creating harness in real time.

Okay. I want to tell now what works brilliantly and what doesn't work, as we thought it would work. So first things first is accurate syncs. We can generate very accurate syncs and sources. And we discovered remote code execution vulnerabilities in internal and external products with a huge code basis.

Because harnesses, we need to basically get them from different types of products, not only TikTok based products. The second one is remediation. SDK works brilliantly. Yesterday, I think I literally received report from the one of the developers. He was like, well, now our new feature doesn't really work.

Why is it? I was like, because SDK is blocking it because it's not secure. And at least we just worked out and understood how to fix it using SDK. And the second one is workflows. Basically, rule generation works brilliantly. LLM can be used in a very, very easy way to generate SEMGRAP rules, especially when everything is verified already.

And now let's talk about what doesn't really work. So for Electron. Js based applications, there is a thing called IPC. IPC is some sort of a socket, which basically connects connects I don't know, your back end and front end kind of, but it's all running in the same binary. And these sockets, sometimes they are exposed.

And the problem with that is that it's really hard to understand in which particular part of the application is exposed, so you can't really map them. And this is one of the issues we are currently working on. The second issue is a sync brute forcing. What does it mean is sometimes we can't really understand if we are syncing or not, and we need to basically start bruteforcing different sources and syncs to create the double linked list to produce better results. And the last one, it's a context windows.

We've been trying different different things to understand how to improve context windows because when you scan repository or even one file which contains more than 1,000,000 lines of code, for example, if the product is minified, it becomes very challenging. So what we're doing now for the context windows, we are trying different approaches, for example, which were introduced by Google, by their vectorization quantum vectorization algorithms to understand if it works or not.

And we're storing the context for every scan for every file on the back end and trying to use the algorithm. And, yeah, now it produces pretty good results but still in the testing. And that's about it. So this is a QR code you can scan to add me on LinkedIn. And you can also find me after the end of presentations to ask any questions if you have.

And yeah, thank you very much for listening.

/WHOAMI

riven@macbook ~ % id
uid=1000(riven) gid=1000(rd) groups=1000(rd),2000(Security Engineer),2001(LLM Researcher),3000(ex offsec),3001(ex appsec-lead)

riven@macbook ~ % cat ./profile.json
{ "role": "Security Engineer", "focus": [ "AppSec", "LLM
  Integration", "Agentic Workflows" ], "Ex": [ "Offsec", "AppSec Lead" ],
  "mission": "Automate the boring stuff." }

AGENDA

The Problem

Why traditional SAST is noisy and how LLMs provide deep contextual analysis.

Architecture

Building a multi-agent system to find, validate, and remediate vulnerabilities.

Reality Check

What works brilliantly today and where current models still fall short.

An alert icon (exclamation mark in a triangle) is positioned next to "The Problem".

A network or connected nodes icon is positioned next to "Architecture".

A double checkmark icon is positioned next to "Reality Check".

THE PROBLEM SPACE

1 M+

Lines of Code

Standard tools struggle to trace cross-module taint chains in massive monorepos.

We need a system that thinks across file boundaries and maintains state over complex code paths.

PIPELINE EVOLUTION

v0.1: Basic CI/CD

Integration of open-source SAST.
Resulted in high false-positive rates requiring manual triage.

v1.0: LLM POC

Initial research around Semgrep rules generation.
Tested boundaries of what works and what fails.

Current State

Full agentic multi-agent system handling verification, synthesis, exploit generation, and reporting.

PIPELINE ARCHITECTURE

Orchestrator

Manages workflow state and agent handoffs.

Scanner

Discovers vulnerabilities by using fine-tuning, skills, prompts and dynamic harnesses

Validator

Eliminates false positives via deep analysis.

Exploit developer

Generates context-aware, verifiable exploits.

A diagram illustrating a pipeline architecture composed of four distinct stages. Each stage is represented by a card containing an icon and descriptive text. The stages are Orchestrator (represented by a user icon with a cog), Scanner (represented by a magnifying glass icon), Validator (represented by a shield icon), and Exploit developer (represented by crossed wrench and screwdriver icons).

Full Pipeline Architecture

Diagram of the multi-agent SAST pipeline workflow from scanning to remediation.

A. Repository Intake & Scanning

1. User Input
2. Intake & Scan Orchestrator Backend
- Receives repository inputs
- Checks whether the repository is cached
- If cached, uses internal optimization for faster retrieval
- Matches files by the current user prefix in the git tree
- Splits matching files into LLM-safe chunks
3. Prompt Scanning Service
- Uses LangChain + LangGraph
- Prompts stored locally
- Scans the repository offset by offset
- Returns asynchronous results
4. Response Validation Backend
- Receives asynchronous scanning results
- Validates that the response is correctly formatted
- Prepares the payload for the next backend and agent

B. Verification & Pattern Search

5. Vulnerability Verification Backend
- Receives a vulnerability verification request in a prepared format
- Connected to Redis Cluster via shared platform services
- Verification flow is described in
6. Pattern Search Backend
- Generates and executes Semgrep rules
- Searches for similar patterns across the whole repository, not only one file
- Reduces token usage and accelerates large-scale pattern search

Decision point: Confirmed and confidence > 65%

Kubernetes Cluster

1. User Input

Branch
Repository name
Prompt type (ElectronJS, Web Server, etc.)
Access tokens

A. Repository Intake & Scanning

2. Intake & Scan Orchestrator Backend

Receives repository inputs
Checks whether the repository is cached
If cached, uses internal optimization for faster retrieval
Matches files by the current user prefix in the git tree
Splits matching files into LLM-safe chunks
Offset scan rule: 2 files per chunk, offset = 2
Initializes SDK and starts asynchronous scanning

3. Prompt Scanning Service

Uses LangChain + LangGraph
Prompts stored locally
Scans the repository offset by offset
Returns asynchronous results

4. Response Validation Backend

Receives asynchronous scanning results
Validates that the response is correctly formatted
Prepares the payload for the next backend and agent

B. Verification & Pattern Search

5. Vulnerability Verification Backend

Receives a vulnerability verification request in a prepared format
Connected to Redis Cluster via shared platform services
Verification flow is described in more detail on the next slide

6. Pattern Search Backend

Generates and executes Semgrep rules
Searches for similar patterns across the whole repository, not only one file
Reduces token usage and accelerates large-scale pattern search

Confirmed and confidence > 65%

Work Chats Notifications

C. Shared Platform Services

All backend microservices use shared platform services

MCP Proxy

Load balancer + proxy for MCP traffic

AWS S3 / Lambda

Actual MCP logic handlers

Redis Cluster

Shared cache / state

Consul

Service discovery / configuration

D. Results & Human Review

7. Vulnerability Runner & Analysis

Collects results
Analyzes vector representations of vulnerabilities
Determines vulnerability type
Builds an ELK request and sends data for analytics and triggers

ELK Stack

Elasticsearch
Logstash
Kibana

Critical findings can trigger alerts

8. Security Engineers

Verify findings
Investigate root cause
Modify SDK to improve coverage

A detailed architecture diagram for a Kubernetes Cluster, illustrating a security scanning and verification pipeline. The diagram is divided into four main sections: A. Repository Intake & Scanning, B. Verification & Pattern Search, C. Shared Platform Services, and D. Results & Human Review. It begins with "1. User Input" flowing into the repository intake. Various components are shown with connecting arrows to depict data flow and interactions. Key technologies and services depicted include LangChain, LangGraph, AWS (S3/Lambda), Redis Cluster, Consul, Elasticsearch, Logstash, Kibana, and Semgrep. The diagram shows the process from user input and repository scanning, through vulnerability verification and pattern searching, utilizing shared platform services, and culminating in analysis and review by security engineers with alerts for critical findings.

Verification Backend Pipeline

Diagram of the verification and taint analysis pipeline engine.

1 FILE SCAN (INDEPENDENT)

Go through every file independently and look for dangerous patterns.

INPUT

Codebase / Repository

file_1.py
file_2.js
...
file_n.go

DANGEROUS PATTERN DETECTION

Skills
Prompts
Fine-tune

Output: Findings per file (patterns, locations, context)

2 SOURCE IDENTIFICATION (LEFT)

Go to the possible left side called SOURCE to potentially identify source chain.

Use same approach (skills/prompts/fine-tune) to trace backwards

Output: Source chain candidates with evidence & confidence

3 SINK IDENTIFICATION (RIGHT)

Use the same approach to try to identify SINK, based on the source.

Trace forward from source to potential sinks.

Output: Sink chain candidates with evidence & confidence

4 UNIFY & GENERALISE

Generalise and unify chain and information received from sink/source agents for the further processing.

Unify:

Source Chains
Sink Chains
Traces
Evidences
Metadata
Confidence Scores

Output: Normalized exploration chains (ready for analysis)

Main Filters

Detect potential filters, validators, WAFs, sanitizers, guards, etc.

Filter Analysis

Analyze behavior, rules, signatures, thresholds

Bypass Generation

Generate bypass payloads/techniques (prompting, encoding, logic, polyglot, etc.)

Bypass Execution

Test bypasses across the full chain in a controlled manner

Bypass Result

Evaluate effectiveness, side-effects, and stability

Report as Not Exploitable

Filters are effective and cannot be bypassed (with given techniques).

CHAIN & EVIDENCE STORE

All chains, traces, payloads, responses, bypass attempts, filters, scores, metadata

6 FINAL JUDGE

Now we have all chains, all traces and evidences in sick judge to go through the entire pipeline, exploit and everything to determine 'exploitability' of the whole chain to work, taking into consideration the exploits and filters. Everything should be mathematically proven.

Mathematical Evaluation

Probability Model
Confidence Scores
Risk Scoring
Proof Obligations

Output: Likelihood Score (0 to 1) + Mathematical Proof + Detailed Justification

7 REAL-TIME HARNESS & BACKEND HOOK

Every chain of pipeline is supported by real-time harness generation

Harness Generator

Generate dynamic harness for current chain/step (inputs, payloads, hooks).

Backend Hook

Hook into the real backend APIs, services, DB, filters, LLM endpoints, etc.

LLM (Agent)

LLM reasons over real responses, not assumptions (reduces hallucination)

Backend Response

Real-time responses, errors, headers, logs, behavior, side-effects

Guardrails & Rules

Inject additional rules based on situation (e.g., rate-limit, auth, context, business logic).

Goals:

Prevent hallucination
Enforce correctness
Improve tracing accuracy
Provide additional situational rules
Ensure real exploitability assessment

LEGEND

Main Flow
Positive Path
Negative Path
Data/Artifacts
Feedback Loop

A detailed flowchart illustrating a "Verification Backend Pipeline" for security and taint analysis. The pipeline begins with "FILE SCAN" (1) for dangerous patterns in code files, followed by "SOURCE IDENTIFICATION" (2) and "SINK IDENTIFICATION" (3) to trace data flow. These findings are then processed by "UNIFY & GENERALISE" (4). A central section details "Bypass" analysis, including filter detection, bypass generation, execution, and evaluation. All collected data is stored in a "CHAIN & EVIDENCE STORE." The final stage is "FINAL JUDGE" (6), which performs "Mathematical Evaluation" to determine a "Likelihood Score." Supporting components are outlined under "REAL-TIME HARNESS & BACKEND HOOK" (7), including a Harness Generator, Backend Hook, LLM (Agent), Backend Response, and Guardrails & Rules, with associated goals. A legend defines the different arrow and line types representing Main Flow, Positive Path, Negative Path, Data/Artifacts, and Feedback Loop.

Pipeline for Vulnerability Detection and Exploitation

1 FILE SCAN (INDEPENDENT)

Go through every file independently and look for dangerous patterns.

DANGEROUS PATTERN DETECTION

Skills
Prompts
Fine-tune

Input: Codebase / Repository, file_1.py, file_2.js, file_n.go

Output: Findings per file (patterns, locations, context)

Decision: Dangerous Pattern Found?

NO: No issues in this file
YES: Proceed to Source Identification

2 SOURCE IDENTIFICATION (LEFT)

Go to the possible left side called SOURCE to potentially identify source chain.
Use same approach (skills/prompts/fine-tune) to trace backwards

Output: Source chain candidates with evidence & confidence

3 SINK IDENTIFICATION (RIGHT)

Use the same approach to try to identify SINK, based on the source.
Trace forward from source to potential sinks.

Output: Sink chain candidates with evidence & confidence

4 UNIFY & GENERALISE

Generalise and unify chain and information received from sink/source agents for the further processing.

Unify:

Source Chains
Sink Chains
Traces
Evidences
Metadata
Confidence Scores

Decisions:

Are we a dangerous sink?
Are we the most right sink node?

Action for "No" to both: Dig Deeper (Explore deeper to find further right sinks)

Output: Normalized exploitation chains (ready for analysis)

5 FILTER-BYPASSER AGENT

Inject filter-bypasser agent to go through the entire chain to check if there are any potential filters in place -> try to bypass them.

Map Filters: Detect potential filters, validators, WAFs, sanitizers, guards, etc.
Filter Analysis: Analyze behavior, rules, signatures, thresholds
Bypass Generation: Generate bypass payloads/techniques (prompting, encoding, logic, polyglot, etc.)
Bypass Execution: Test bypasses across the full chain in a controlled manner
Bypass Result: Evaluate effectiveness, side-effects, and stability

Decision: Bypass Successful?

YES: Proceed to Final Judge
NO: Report as Not Exploitable (Filters are effective and cannot be bypassed (with given techniques).)

6 FINAL JUDGE

Now we have all chains, all traces and evidences -> ask judge to go through the entire pipeline/exploit and everything to determine likelihood of the whole chain to work, taking into consideration the exploit and filters.
Everything should be mathematically proven.

Mathematical Evaluation:

Probability Model
Confidence Scores
Risk Scoring
Proof Obligations

CHAIN & EVIDENCE STORE: All chains, traces, payloads, responses, bypass attempts, filters, scores, metadata

Output: Likelihood Score (0 to 1) + Mathematical Proof + Detailed Justification

7 REAL-TIME HARNESS & BACKEND HOOK

Every chain of pipeline is supported by real-time harness generation

Harness Generator: Generate dynamic harness for current chain/step (inputs, payloads, hooks)
Backend Hook: Hook into the real backend APIs, services, DB, filters, LLM endpoints, etc.
LLM (Agent): LLM reasons over real responses, not assumptions (reduces hallucination)
Backend Response: Real-time responses, errors, headers, logs, behavior, side-effects
Guardrails & Rules: Inject additional rules based on situation (e.g., rate-limit, auth, context, business logic).

Goals: Prevent hallucination, Enforce correctness, Improve tracing accuracy, Provide additional situational rules, Ensure real exploitability assessment.

LEGEND

Main Flow
Positive Path
Negative Path
Data/Artifacts
Feedback Loop

A complex flow diagram illustrates a multi-stage security analysis pipeline. It features seven numbered steps, each with an icon and descriptive text, representing different agents or processes. Arrows indicate the flow of data and decision points, including conditional branching and feedback loops. Boxes represent data inputs, outputs, or storage. The legend clarifies the meaning of different arrow types.

WHAT WORKS BRILLIANTLY

Accurate Sinks
Discovered RCE in multiple internal apps and third-party apps with huge influence
Remediation
SDK integration allows devs to solve issues immediately without manual triage.
Workflows
Automatic rule generation and MR scanning without blocking engineering velocity.

WHERE MODELS BREAK

IPC Blindspots: Hard to map where issues truly exist across process boundaries.
Sink Bruteforcing: Models waste compute cycles trying to force alignments where none exist.
Context Windows: Backtracking protocol for large repos remains in active testing.

sys.exit(0)

https://www.linkedin.com/in/dmitry-makarychev-947b7156/

A QR code.

ЭЛЕКТРОНЬ Къ 409Д

МВ ДМВ

1 6 21

5 12 60

настройка

A vintage portable CRT television set, white and black. Its screen displays a pixelated grey symbol resembling two right-pointing arrows or a fast-forward icon on a white background.