In this post, we continue sharing the results of our ongoing testing of the DCODX.AI harness.

Over the past few months, we have been testing and refining the capabilities of our internal DCODX.AI platform. A significant part of this work involved refactoring the codebase to support multiple models and inference providers, reducing token usage (those are expensive !!) and improve the context used by the agents. Basically Context Engineering.

Before we dive into what changed we are happy to publish some CVEs obtained in the past couple of weeks.

The idea of only identifying a vulnerability did not really reason with us, but we wanted to go a little bit further and create a full exploitation chain of the issue. To do that we had to build our harness in a way that would be able to understand roles and permissions across multiple users. 
For example if we look at CVE-2026-22033, a simple vulnerability identification would have been a stored XSS. DCODX.AI went further to exploit the Stored XSS to fully compromise another account at login time. 

The same in GHSA-hvq7-hq9r-8gjr where DCODX.AI was able to create a working PoC on Immich (https://immich.app/) using two different company accounts with different roles to bypass authorization on personal assets.

More info about each vulnerability and their exploitaion can be found at https://dcodx.com/ai

The Architecture 

Previously, DCODX.AI only supported models hosted by OpenAI through their API. We have now shifted our focus toward making the platform model-agnostic, with particular attention to open-weight models hosted across different platforms, including Cloudflare.

One of the reasons behind this decision was the limitations we encountered when using frontier models for cybersecurity tasks.

During security analysis, agents frequently need to create proof of concepts code, reason about exploitation techniques, or analyze attack paths. When a model’s guardrails interrupted one of these tasks, we had to save the current state, resume the analysis with another prompt, reload the relevant context, and consume additional tokens in the process.

Supporting multiple models and especially open models, gives us considerably more flexibility. Different specialized agents can now use different models depending on the task, deployment environment, and security requirements.

Reducing Context and Token Usage

Another area we spent significant time improving was context management.

Our initial implementation was relatively simple: we essentially “splashed” everything we knew about the target into the user prompt, in whatever format was available.

It kind of worked, but it didn’t scale particularly well.

As the amount of information collected during an assessment increased, prompts became larger and noisier. Agents received information they didn’t necessarily need, token consumption increased, and larger assessments could eventually run into context-window or token-limit errors.

We spent roughly a month redesigning how context is constructed and passed between agents.

Instead of giving every agent everything we know, each specialized agent now receives a small, purpose-built context containing only the information relevant to its task. The goal is to keep prompts compact and focused while still providing enough evidence for the agent to make useful security decisions.

This has significantly reduced context bloat and unnecessary token consumption, while also making agent behavior more predictable.

GraphRAG

One of the more interesting parts of DCODX.AI is our use of a graph representation of the target application.

We currently build several graphs from the codebase, including graphs derived from AST parsing. However, the objective isn’t simply to create a graph of functions, classes, and files.

For security analysis, we are particularly interested in understanding relationships between:

external-facing assets and inputs (sources) → authorization and trust boundaries → application logic and dependencies → security-sensitive operations (sinks)

We already used this graph in earlier versions of DCODX.AI, but we weren’t using it effectively. Graph information was passed to the agents too broadly and without enough consideration for which parts of the graph were actually relevant to the task being performed.

This was particularly visible in our threat-modeling agent. The agent would receive graph sections and generate plausible security threats for each of them, but it didn’t always reason about whether those components were actually connected through a realistic attack path.

We changed how graph context is selected and presented to the agent.

Instead of passing arbitrary sections of the graph, we now focus the context around meaningful relationships: where attacker-controlled input originates, which authorization or trust boundaries it crosses, which components and dependencies are involved, and which sensitive operations it can eventually reach.

This allows the threat-modeling agent to reason about complete attack paths rather than isolated components.

The question therefore changes from:

• What threats could exist in this part of the application?

to something much more useful:

• Can an attacker-controlled source realistically reach this sensitive sink, and what security boundaries must be crossed along the way?

The important improvement is to make sure the agent receives the right part of the graph, in the right context, for the specific security question it is trying to answer.

This has made a significant difference in the quality of the generated threat models and has helped reduce generic, unrealistic, or impossible attack scenarios.

Future

As models and frameworks evolve we are also learning and making mistakes. Our next steps would be to work on coverage and visibility. This will allow us to improve the underlying infrastructure (especially the graph and the information on it)

Check our findings on https://dcodx.com/ai