The AI tool passed the safety check. We still said no.

In August we published a two-question check for setup prompts written for your AI assistant: does it write into the assistant's global configuration, and does it argue the assistant out of asking you first. The cautionary example then was a package that failed both. Two months later we evaluated a second tool in the same category, a reverse-engineering add-on for coding agents called REA, and it passes both questions as cleanly as anything we have read: the setup shows its plan before it writes, waits for approval, and ships instructions that tell the agent to ask rather than act.[1] We still did not adopt it. The reasons had nothing to do with safety, and they apply to any add-on someone proposes for your team's AI tools.

The six gates, in the order we run them: (1) install hygiene, does the tool gate its own writes; (2) lane fit, do you sell or use the work it does; (3) host fit, does it run on the machines your people use; (4) release velocity, can you pin a version and hold it; (5) footprint, does it load into every session or into one project; (6) use case and data, is the headline use lawful for you and where does the output go. The checklist version, written for an owner or operations lead, is at the end.

Gate one: the safety check, passed.

The two August questions were about install hygiene: what a tool does to your assistant's configuration when the assistant installs it for you.[3] REA's setup is the good pattern. Its installer offers the agents it has detected in a multi-select and leaves newly detected ones unselected; in the documentation's words, "detection gives setup context, not permission to add a new registration."[1] Before it writes anything it lists each configuration path it will touch, each place it will copy its skill, each external package, each network origin and the integrity evidence for it, and it writes nothing until that plan is approved. Installing the one native analysis engine it can fetch for you is a separate approval.

The skill it hands the agent is written in the same spirit. When the tool is not registered, the skill tells the agent to diagnose without changing files, show the dry-run plan with its exact paths and backups, and "obtain approval before setup writes configuration or installs Hopper".[1] (Hopper is the one analysis engine the installer can fetch for you.) It also tells the agent not to install unrelated software to repair a registration. That is the opposite of the August case, whose routing file told the agent to write itself into the global configuration and that a reply of "understood" was a failure.[2]

Two more things count in its favour. Its security policy states a boundary and the boundary's limit in one breath: per-session tokens over current-user sockets, isolated temporary projects for the analysis engine, and then "This is not a sandbox", with the plain statement that opening an untrusted binary runs the analysis engine with your user's permissions.[1] And a targeted search of the source for common analytics libraries and outbound calls found none beyond the engine download and the source-map fetches during website analysis. That was a grep, not an audit.

So gate one, passed. In August that gate was the whole note. Here it is where the evaluation starts.

What we evaluated, and what we did not do.

REA is one local MCP server (about fifty tools in its generated catalog, by our count on the captured commit) plus a bundled 14 KB agent skill with five reference files, and the same workflows as a command-line tool. MCP, the Model Context Protocol, is the plug standard that lets a coding agent call outside tools. A skill is a text file of instructions the agent loads and follows. An "add-on" in this note means an MCP server, a skill, or both. REA's pitch, verbatim from its README: "See a feature in an app that you want in your own product? Ask your agent to investigate it with REA."[1] Its targets run from native binaries through JavaScript and Electron apps, .NET assemblies and Android packages to firmware, saved network captures and live websites. It is written in TypeScript, tested against the real analysis engines in its CI, and it is popular. We leave the star count out: it moves, and popularity is not a gate.

We did not run it. We did not point it at a binary, a package or a website, ours or anyone else's. The capability claims are the project's. We also did not form a view on reverse engineering as a practice. The deep end of that work (binaries, firmware, crash dumps) is work our managed-IT arm refers to a specialist partner, and that is gate two.

Five more gates.

The August check does not tell you whether the tool belongs in your toolkit at all. A tool can be honest about what it writes and still be the wrong tool for your business, run badly on your machines, move faster than you can read, load into sessions that never needed it, and point at a use case your lawyer has not seen. Those are five separate questions, and we found we were asking them in a fixed order.

Lane fit: do you sell or use this work?

REA's centre of gravity is deep native, firmware and binary analysis. We do not do that work; when a client needs it, we refer it. Its other half, website analysis (page structure, scripts, network observations, screenshots), duplicates tools we already run for the work we do sell. So the part we would use is redundant and the part that is unique is out of our lane. For a different firm, a Linux security shop doing authorised engagements, this gate reads the other way. The question is yours to answer, not the tool's.

Host fit: does it run where your people work?

We work on Windows. Of REA's three native analysis engines, one does not run on Windows at all, one is documented there as an experimental read-only mode, and the third needs its own commercial licence. Process capture and firmware extraction are Linux or macOS only. What would work on our desks is the static half: JavaScript and Electron trees, .NET assemblies, Android packages (with a Java kit installed), and saved network captures.[1] A tool that runs on your laptops at a fraction of its advertised capability is a different tool from the one in the README, and the fraction is what you should evaluate.

Release velocity: can you hold a version?

Between 7 and 9 October 2026 the project published five releases, including two major-version bumps. Its README says so plainly: "REA changes quickly, and new releases include frequent bug fixes. Keep your installation up to date."[1] For a personal install that is a feature. For a tool your agent calls inside client work it is a question: can you pin a version (fix the installed version so updates arrive only when someone moves it) and hold it for a month? Here the honest answer is "yes, if you do it yourself." The skill's own repair commands fetch whatever is published that hour (the package name followed by latest), so a routine fix would move you to a version nobody on your team had read. That is a supply-chain question in plain form: the package your agent installs next week is not the package you read. The setup still shows its plan and waits, so this is a version-drift risk, not an injection one, which is why there are six gates and not one.

Global footprint: what sits in every session?

The standard setup registers the server at user scope, meaning for your whole account rather than one project, and copies the skill into the agent's personal skills folder. That means roughly fifty tool definitions and a 14 KB instruction file load into every session your agent opens, including every session with no reverse-engineering need, which for us would be nearly all of them.[1] Every tool definition your agent carries is text it reads before it reads your task, and that cost compounds across a toolkit. REA does allow a narrower shape: skip its installer and register the server by hand, pinned to one version, inside one project's configuration. Of the five gates beyond install hygiene, that is the one it cleared cleanly for us, and only because the project leaves that door open.

Use-case legality and data egress: what does the headline use do, and where does the output go?

The headline use case, rebuild a feature you saw in someone else's app, runs into that app's licence terms, which commonly prohibit decompilation. The project's disclaimer puts the burden where it belongs, on the user: "You are responsible for obtaining any required authorization and complying with applicable laws."[1] We have no counsel on retainer, so for us that use case stays closed until a lawyer has read a specific target's terms, and nothing in this note should be read as endorsing it.

The data question is separate and quieter. The analysis runs locally, and the README says so, but the README also says the results go to your agent, whose "model provider has its own data policy."[1] Decompiled output from a client's own legacy application is client-confidential material, and under our data-handling rule it does not reach a hosted model without that client's written consent. For a Quebec business that is a Law 25 cross-border question.

The six gates, two tools.

Read side by side with the August case, the two evaluations give a table you can reuse. The first row is the only one a safety check covers.

Five releases in three days.

We put the velocity row in a figure because it is the gate that gets mistaken for a compliment. A fast-moving project looks alive. The operational question is different: your agent calls this server inside work you bill for, and five versions in three days means the tool you tested on Tuesday is not the tool running on Friday unless someone pinned it.

What a reasoned no looks like.

Not adopted is a verdict, not a ban, and the difference matters when a real need arrives. Our standing decision has three parts.

Nothing global. No user-scope registration, no skill in the personal folder.

Project-scoped and pinned if an engagement needs it. A version-pinned registration in that one project's configuration, never the installer, so it loads for that work and nowhere else, and we re-read the release notes before the pin moves.

One trigger we would act on. A client's own legacy application whose source code is lost, where recovering the business logic is the client's request and the client's data, with written consent for the analysis output to reach a hosted model. The headline use case, someone else's app, is not on the list.

The six-gate checklist for your next AI add-on.

Someone on your team will propose an MCP server or an agent skill this quarter, probably a good one. These are the six questions, in the order we ask them, written for the owner or operations lead of a small business rather than a developer. The first two take a minute; the other four take a conversation.

1. Does it gate its own writes?

   The August questions. Does it show its plan and wait for approval? Does it stay out of global configuration you did not choose? Is there language built to stop the agent from asking you? If it fails here, stop; nothing below matters.

   → red flag: writes before approval, or argues the agent out of asking
2. Do you sell or use this work?

   Name the service line or internal job it serves. If the unique part is work you refer out and the familiar part duplicates a tool you already have, it is a personal install, not a team tool.

   → target: one named workflow it improves
3. Does it run where your people work?

   Read the platform table against the laptops you actually own, feature by feature, and write down which features survive. Evaluate that list, not the README's.

   → target: the surviving feature list
4. Can you hold a version?

   Look at the release cadence and check whether the tool's own update or repair paths fetch latest. Decide who reads the changelog and when the pin is allowed to move. Note who publishes the releases; a one-person project is a one-person pin.

   → target: a pinned version and a named owner of the pin
5. What loads in every session?

   Prefer a project-scoped registration over a global one. If the tool only offers global, count the tool definitions it adds to the sessions that will never use them, because the agent reads them all before it reads your task.

   → target: project scope, pinned
6. What does the headline use do, and where does the output go?

   Read the tool's own licence first (REA is MIT; a source-available tool is a different conversation, see the n8n note), then the project's disclaimer and, for any target that is not yours, its licence terms, before the first run. Then trace the output: local analysis still ends in a hosted model unless you run the model yourself. Client material needs the client's consent first.

   → target: terms read, consent on file, output path traced

Write the answers down with the date and the version. Six months from now someone will ask why you said no, and a dated table answers faster than a memory.

What this does not claim.

This is not a review of REA's quality. We did not run it. The capability claims are the project's, and the engineering we did read (approval-gated setup, a security boundary stated with its limits, tests against the real engines) reads as careful work.

It is not a claim that REA is unsafe. It passed the one gate that is about safety. The no came from the five that are about us.

It is a dated snapshot. Read on 10 October 2026 at version 6.3.0. The velocity gate says it will have changed by the time you read this; re-check before you rely on any row.

The no is ours. A Linux security firm with counsel on file and authorised engagements fills the right-hand column differently. The rows are reusable; the verdict is not.

This is not legal advice. Licence terms and Law 25 obligations depend on the target and the data. We name the questions and who should answer them.

If someone has proposed an MCP server or an agent skill for your team and you want the six gates run on it, send the repository through the contact form. We will write back, free, with the dated table. Tool admission decisions like this are part of our automation audit.