The Agent Needs a Disassembler, Not More Context

Oct 10, 2026 6 min read

A coding agent can read a repository because the repository is already speaking its language. A native binary does not offer that courtesy.

That is why the interesting part of REA, the open source Reverse Engineer Anything project, is not that it connects an agent to another tool. It connects the agent to the evidence layer that exists when source code is missing.

The project exposes reverse engineering workflows through an agent-facing bridge. Its supported analysis surface includes native binaries, JavaScript and Electron applications, .NET assemblies, Android packages, firmware, websites, and selected browser or process activity. The project describes itself as a way to let an agent inspect a program and explain what it does, using tools such as Ghidra, IDA Pro, and Hopper where appropriate.

That is a more important architectural move than giving an agent a larger context window.

The model is not the reverse engineer

The normal agent story starts with a model and adds tools around it. Give the model a shell, a browser, or an MCP server, then ask it to investigate.

Reverse engineering makes the missing boundary obvious. The model does not directly know what a binary does. It needs disassembly, decompilation, strings, references, call relationships, runtime observations, and a way to associate each conclusion with the artifact that produced it.

REA’s public examples make that sequence concrete. In one example, an agent investigates why Windows Calculator evaluates 200 + 10% as 220. The workflow is not a guess from general knowledge. It selects instructions, recovers a branch, connects the branch to operator identifiers in Microsoft’s source, and then explains the behavior in ordinary language.

In another example, the agent inspects the running JavaScript for the Chrome dinosaur game. The recovered settings include an initial speed of 6, an acceleration of 0.001, and a maximum speed of 13. The point is not that an agent can repeat those numbers. The point is that the numbers came from the program being inspected, rather than from a plausible answer generated about it.

That is the pattern security tooling needs:

agent question
    -> scoped inspection tool
    -> raw program evidence
    -> model interpretation
    -> replayable explanation

The model is valuable in the last two steps. It can choose a useful next question, compress a long disassembly, compare paths, and explain a result. It should not be allowed to silently replace the first step with invention.

The bridge is the product

REA is presented as a bridge between coding agents and analysis tools, not as a replacement for a disassembler. That distinction matters.

A disassembler has authority over a narrow artifact. An agent has authority to decide what to ask next. Those are different responsibilities. Combining them without a boundary produces the familiar failure mode of agent security: a fluent conclusion with no durable evidence path.

The bridge creates a place to put that boundary. A tool can return the selected instructions, the decompiled function, the call path, the loaded script, or the digest of the observed artifact. The agent can then reason over those results while the operator retains something that can be checked independently.

The project repository is unusually explicit about this direction. Its recent changes include contracts that require analysis outputs to carry provider and observation metadata rather than quietly filling unknown fields with defaults. That is a small implementation detail with a large consequence. Unknown is data. It should not become a confident value merely because a model wants a complete answer.

The same rule applies to agent investigations. If a provider cannot recover a parameter flow, the result should say so. If the target changed between two observations, the evidence should record that. If browser activity was captured through a local debugging connection, the connection and target should be part of the record.

This is also an MCP trust-boundary problem

An agent-facing reverse engineering tool is powerful because it can inspect software that was never designed to be queried by an agent. That power creates a second boundary around the tool itself.

The safe design is not to hand the agent an unrestricted terminal and hope that a prompt keeps it focused. It is to scope the target, scope the provider, scope the filesystem, and record every observation that becomes part of the conclusion.

A practical deployment should answer these questions before the first investigation:

Which files or processes may the agent inspect?
Can the analysis provider execute the target, or only read it?
Can the agent reach the network while an artifact is loaded?
Where are extracted files written?
Which results are raw observations, and which are model summaries?
Can another operator rerun the same inspection against the same artifact?

REA’s setup page instructs the user to run npx rea-agents@latest setup, show the setup plan for approval, and verify the installation before restarting the agent. That approval step is not ceremony. An agent integration that installs skills, configures providers, or connects local analysis tools is changing the control plane.

The operator should inspect the plan before granting that authority. The same applies to any MCP server that can open a binary, launch a browser, attach to a process, or write a reconstructed project.

What common intuition gets wrong

The common intuition is that reverse engineering becomes easier when the model gets more context. Context helps, but only after the system has collected the right facts.

A million tokens of disassembly is still not a verifier. A model can summarize a wrong function with perfect grammar. It can also confuse a decompiler’s guess with a property of the original binary, especially when symbols are missing or control flow is indirect.

The useful question is not how much analysis the model can remember. It is whether the operator can trace an important sentence back to the bytes, instructions, source location, or runtime observation that supports it.

That is why the evidence-producing tool loop beats the bigger prompt. The loop can expose uncertainty. The prompt usually hides it.

What builders should copy

Builders working on security agents should copy the separation of duties, even if they never use REA.

Keep raw observations separate from model explanations. Put a digest and version on every target. Make tool output structured enough to replay. Preserve unsupported fields as explicit unknowns. Require approval for installation and capability changes. Give execution, network access, and write access separate policy decisions.

Most importantly, make the verifier independent from the model that proposed the explanation. If an agent says a branch controls authentication, the system should be able to show the branch, the call path, and the test that distinguishes that explanation from a nearby alternative.

REA does not make reverse engineering autonomous by itself. It makes a credible control loop possible: the agent asks, specialized tooling observes, and the evidence constrains the answer.

The next useful agent will not be the one that claims it understands every binary. It will be the one that can show exactly which bytes earned that claim.

Sources

REA GitHub repository, accessed October 10, 2026. Project scope, supported integrations, repository structure, and analysis-output metadata were checked against the public repository.
REA official website, accessed October 10, 2026. Setup command, browser and native analysis examples, and the Calculator and dinosaur-game evidence workflows.
Cyber Security News summary, October 10, 2026. Radar discovery source for the public announcement and supported analysis categories.
Cyber Security News announcement post, October 10, 2026. Radar post used as the discovery signal, not as the sole technical source.