REA MCP Server: What Agent Reverse Engineering Changes in Your Setup

REA ("Reverse Engineer Anything", npm package rea-agents) is an MIT-licensed MCP server and CLI that hands coding agents reverse-engineering tools. Point Claude Code, Codex, Cursor, Gemini CLI or Grok Build at a binary, an Electron app, an APK or a website, and the agent can pull out strings, decompiled methods, routes and network observations. The repository has about 33,000 stars at the time of writing.

That is a useful capability and a larger permission surface than most MCP servers add. This post looks at REA through the lens of someone who runs agents: what npx rea-agents setup changes in your config, what runtime capture can touch, and what to review and approve. Everything about REA below comes from its public README, SECURITY.md and AGENTS.md; explainx.ai has not audited REA's code, and nothing here is a claim about vulnerabilities in it.

TL;DR: REA's footprint on an agent setup

What does REA let an agent do?

REA's README lists targets by type, each with its own requirements. Native binaries need Hopper, Ghidra or IDA as the analysis provider. JavaScript and Electron inspection covers modules, imports, source maps, routes and IPC. Android work needs headless JADX and a JDK. Websites need a Chrome-family browser. Firmware uses Binwalk or Unblob on Linux. Process capture needs Linux or macOS.

The common thread is that the agent no longer just reads your source. It reads other people's compiled artifacts, which are untrusted input by definition. Strings, symbols, decompiled output and web page content all come back as tool results, and tool results go into the model's context. That is the same prompt-injection surface covered in MCP security and indirect prompt injection, applied to a domain where the content is adversarial more often than usual.

What does npx rea-agents setup change?

Per the README, setup lets you choose agents, shows proposed changes, waits for your approval, and then adds "REA's MCP server and matching workflow instructions, with backups of existing configuration." You restart the agent afterward. REA's AGENTS.md separately states that rea setup must get approval before writing files, and SECURITY.md says setup "may update client configuration only after showing a plan and getting approval."

Two things get added, and both matter:

1. An MCP server entry in each selected agent's config. From then on, every session of that agent can launch REA and call its tools.
2. Workflow instructions or a skill. These are text the agent reads and follows. They shape how the agent approaches a target, so they deserve the same scrutiny as any SKILL.md.

The README does not list the exact files it edits, so do not rely on a path from a blog post. Instead, snapshot your config before you run setup and diff it after.

# Before: copy the agent config you expect setup to touch (path varies by agent)
cp ~/.claude.json ~/rea-before-claude.json

npx rea-agents setup

# After: see exactly what changed
diff ~/rea-before-claude.json ~/.claude.json

If you let setup optionally install Hopper, that is a separate approval. SECURITY.md describes the Linux path as HTTPS-only metadata, a restricted download origin, a size cap and a SHA-1 check against a published checksum, and it notes SHA-1 is a corruption check rather than a signature. On macOS, the README says a first-run dialog may ask you to pick demo mode or activate a license.

What can runtime capture touch?

This is the line that matters most. The README states: "Runtime capture runs or interacts with the selected target using your user permissions." Static JavaScript and .NET inspection read supplied files and do not run the application. Runtime capture, process comparison and website inspection do interact with something live.

If the target is an unknown binary or an installer, running it as you means it can read your home directory, your SSH keys, your cloud credentials and your agent's own config. REA's SECURITY.md is direct about this: "This is not a sandbox and does not protect against malicious processes already running as the same operating-system user," and opening an untrusted binary "delegates parsing and analysis to the selected local provider with that user's permissions."

SECURITY.md does describe hardening for Ghidra sessions (an isolated temporary project, private directories, size limits, CPU and heap caps, cleanup on close) and a capability token with a current-user Unix socket for the local provider bridge. Those reduce accidental persistence and resource use. The same document says they do not make Ghidra a sandbox.

In practice, the safe habit is to run runtime capture on untrusted targets inside a disposable VM or container, not on the machine that holds your credentials. That is a recommendation from us, not a feature of REA.

What should you review before approving?

A short checklist, in the order it is cheapest to check:

• The proposed config diff. Confirm which agents are touched and what command the MCP entry launches. Prefer a pinned package version over an unpinned npx call, since an unpinned entry resolves to whatever is published at launch time. REA recommends rea update to stay current, so decide deliberately when to move versions.
• The workflow instructions. Read them as you would a skill. Look for anything that tells the agent to skip confirmation or run commands without asking.
• Which agents get it. An agent with broad permissions and auto-approval deserves REA less than one that asks before running tools.
• Runtime tools. Decide per session whether the agent may use capture on a target, and where.
• Where results go. Per REA's FAQ, results reach the agent's model provider. Do not feed it proprietary binaries or captures with customer data unless that provider's policy allows it.

Our MCP security guide walks through the same pre-connect review for any server, and the MCP primer and Claude Code MCP setup guide cover how the config entries work.

What to do before and after you run it

Before you run it. Snapshot and diff your agent config as shown above. Then read any skill or instruction file setup installed the way you would read a SKILL.md: line by line, looking for instructions to skip confirmation. Check whether the MCP entry pins a package version, since an unpinned npx entry resolves to whatever is published at launch time.

While it runs. Keep a record of what the agent actually launches. If your agent uses REA to start a process capture, the resulting shell and tool activity is the evidence you want afterward to answer "what did the agent actually run?" Most agent harnesses expose hooks or logs for this; see what an agent harness is. AgentBeam is an agent security platform from the explainx.ai team that stops AI agents before they take dangerous actions, and is one option for the monitoring and blocking layer.

Where all of this stops. Be clear about the limits:

• No config scanner analyzes REA's code, and a clean scan is one input, not clearance. Pattern scanners catch known shapes, not novel ones.
• Agent-level monitoring sees what the agent asked for, not what a target process does once REA runs it.
• Hook-based enforcement is not a kernel sandbox, and it depends on the agent honoring its hooks.
• Nothing at the agent layer contains a malicious binary. A VM or container does that.

Is an AI-assisted repo a concern?

REA's repository includes an AGENTS.md written largely for AI coding agents. It covers architecture rules, strict TypeScript, validation of external input, small composable MCP tools and Conventional Commits. It also notes that Turborepo writes a managed guidance block into the repo when it detects an agent. Having an AGENTS.md says the maintainers use agents in development. It tells you nothing about code quality either way, so judge REA the way you judge any dependency: pin it, read what it asks to change, and watch what it does.

Frequently asked questions

What is REA?

REA ("Reverse Engineer Anything") is an MIT-licensed MCP server and CLI, published on npm as rea-agents, that lets coding agents inspect native binaries, Electron and JavaScript apps, .NET assemblies, APKs, firmware, websites and saved network captures, and compare process runs. Its README describes it as letting an agent inspect a target, trace relevant code and return findings with evidence.

What does npx rea-agents setup change?

Per the README, setup adds REA's MCP server and matching workflow instructions to the agents you choose, with backups of existing configuration. You review and approve the proposed changes first, and restart the agent afterward. The README does not list exact file paths, so diff your agent config before and after.

Does REA run the program it analyzes?

Static inspection of JavaScript and .NET reads supplied files without running the application. Runtime capture is different: the README says it "runs or interacts with the selected target using your user permissions." Treat runtime capture as executing the target.

Does my data stay on my machine when I use REA?

Analysis runs locally, but your agent receives the tool results and its model provider has its own data policy, per REA's FAQ. Anything REA extracts from a target and returns to the agent can leave your machine through the agent's model provider.

Can a scanner tell me whether REA is safe?

No. A config scanner is a heuristic text check of an MCP config or skill file, and it does not run or audit REA's code. You can scan the config entry setup writes and record the tool calls your agent makes afterward, but a clean scan is not clearance.

Related reading

• MCP security guide 2026
• What is indirect prompt injection
• What is MCP (Model Context Protocol)
• Connect MCP servers to Claude Code
• What is an agent harness
• AI agent security platforms 2026

Details about REA reflect its public README, SECURITY.md and AGENTS.md as read on October 9, 2026, and may change between releases.

Update, October 9, 2026: New companion post on what REA's published case studies prove and where they stop: Reverse engineering is now a prompt.