AI can reverse-engineer your software. What protects your model?

What REA is

REA, short for Reverse Engineer Anything, describes itself as reverse engineering with your coding agent. You install it, connect it to an agent and ask a question about an app, a game or a website. REA gives the agent tools to read the program, decode instructions, trace calls and observe what the software does while it runs. The agent then explains a feature or helps rebuild it.

The public example on the REA site walks through why Windows Calculator returns 220 for 200 + 10%. The agent reads selected x64 instructions from the installed library, follows the calls and recovers the rule. The project is open on GitHub.

What it is not

This is reverse engineering with a language model, not reverse engineering of a language model. REA is tooling for application, binary and runtime analysis. Nothing in its material claims to decompile model weights in general or to clone a trained model automatically, and it does not claim to break encryption.

The distinction matters. The point is not that one tool steals models. The point is that the skill barrier to inspecting a shipped program is falling, and a trained model shipped with that program is usually a file and a runtime away from anyone who looks.

Why this is a commercial risk

A vision model for defect detection or a classifier inside an OEM machine is often the one part of the product a competitor cannot rebuild from a teardown. Mechanics can be copied. Years of labelled data and tuning cannot, unless the result can be lifted from the box.

Today, most deployed models are decrypted into memory to run. Licence checks and dongles control who may run the model. They do not stop someone with access to the machine from reading the weights once they are in the clear. As inspection gets easier, contracts and good faith carry more of the load.

Where encrypted model deployment fits

Wodan's approach is to keep the weights encrypted while the model runs. Dropnir uses fully homomorphic encryption so supported computer vision, classification and time-series models can run inference on encrypted weights. The weights are not decrypted on the host, so a memory dump or a copied file yields ciphertext. The owner keeps the key that controls decrypted outputs.

The scope is specific. Today that means computer vision, classification and time-series models at per-study, per-batch and per-event cadence. It does not cover LLMs or line-speed video. Encryption alone also does not stop someone with plaintext outputs from cloning a narrow model by querying it many times, which is why output control sits with the owner.

If your model ships inside someone else's machine, the useful question is simple: what does an engineer with an agent and a weekend find when they open the box? An architecture review maps that for one model and one target.