REA. AI has learned to take software apart. Your secrets cannot be inside it.

This month, an open source project called REA, Reverse Engineer Anything, reached the top of GitHub's trending list. The pitch fits in one line. Give AI agents the tools of reverse engineering. Decompile, understand, recreate. The agent opens the software, explains how it works, shows the evidence and builds a version for your project.

Read that again. Builds a version.

I want to talk about it without alarmism and without naivety. Because most companies still treat their own code as a vault. And code was never a vault. Now it is a shop window with an AI agent outside, reading everything.

What REA is, without the mystery

REA is an MCP server, the Model Context Protocol, plus a command line tool, open source under the MIT licence. It connects coding agents such as Claude Code, Cursor, Codex and Gemini CLI to classic reverse engineering tools. Ghidra, IDA and Hopper for native binaries. JADX for Android apps. Chrome DevTools for web and Electron applications.

The agent does not need to know how to operate each tool. It asks, and REA routes the request to the right one. The reach is wide. Native binaries, APKs, JavaScript applications with their source maps, .NET assemblies, websites, WASM, EVM contracts, Go binaries, firmware.

In practice, what used to require a specialist now requires a well phrased question. “How does this app do that?” And the agent goes looking for the answer inside the software.

The project makes clear it was built for lawful use. Research, education, interoperability, software preservation, analysis of what you own or are authorised to examine. And that is true. Reverse engineering is a legitimate discipline. Researchers use it to find flaws. Companies use it to guarantee interoperability. I myself, as a designer, spent my life taking products apart to understand why they worked.

But a tool does not choose who uses it. What the researcher does in an afternoon, the bad actor does too. And now both do it with a tireless agent working for them.

The barrier has fallen

This is the point I want to nail down. Reverse engineering was always possible. What protected against it was cost. Time, knowledge, tools. Plenty of companies counted on that cost, without admitting it, as a security layer.

REA, and everything that will come after it, turns that cost into almost zero. An Android app, a web front end, a desktop installer, a firmware image. All of it can be read, explained and rebuilt by an agent in a fraction of the time.

And the problem begins when the dismantled product reveals what should never have been there. A password. An API key. A cloud access token. The entire licensing logic. The internal endpoint nobody documented. An agent does not get tired of looking. It will find it.

The real dangers

The first danger is the obvious one. Cloning. Whoever understands how your product works inside can reproduce it, modify it and redistribute it. With an agent doing the heavy lifting, years of building turn into an afternoon of copying.

The second is quieter and more expensive. Access. A credential forgotten inside the code does not expose only the app. It exposes the database, the storage, the cloud account, your customers' data. The attacker does not need to break in. They use the key you left in the door.

The third is the attack on trust. Modified versions of your app circulating with your name, your brand, your face, but with malicious code inside. The user cannot tell the difference. And you are the one who pays the reputational bill.

Software that has already been opened, copied and cloned

This is not theory. Recent history is a catalogue of expensive lessons.

WhatsApp has lived for years with modified versions such as GB WhatsApp, built from reverse engineering the original app. They promise extra features and deliver extra risk. WhatsApp itself started banning accounts that use these clones, because there is no way to guarantee the security of code nobody audits.

Snapchat learned in 2014. Researchers reverse engineered the app's private API, published the documentation and warned about a flaw. Shortly afterwards, millions of usernames and phone numbers were extracted and published. The API was private in name only.

Pokémon GO, in 2016, saw its communication taken apart within weeks. Maps, bots and third party tools appeared, fed directly by Niantic's servers, which had to respond by hardening the protection of its API.

And in 2026, the case that made me think the most. Anthropic mistakenly published, inside an npm package, a source map file for Claude Code. It was the map to rebuild the original source code. Around 512 thousand lines were exposed, mirrored and studied by the whole world within hours. One of the most sophisticated AI companies on the planet, brought down by a forgotten packaging configuration file. If it happened there, it happens anywhere.

The most expensive mistake: secrets inside the code

Now the central point of this article. The biggest vulnerability is not reverse engineering. It is what reverse engineering finds.

In 2016, Uber suffered a breach that reached the data of 57 million riders and drivers. The attackers' path ran through a code repository holding the company's cloud access credentials. The key was in the code. The code was accessed. The rest is history.

Toyota revealed in 2022 that part of the source code of a connected service had been public on GitHub for about five years. Inside it, an access key to a data server. Almost 300 thousand customer email addresses were exposed.

In the same year, Symantec analysed mobile apps and found 1,859 of them with AWS credentials written directly in the code. In one case, the access opened the way to the fingerprints of hundreds of thousands of people. Biometrics cannot be changed like a password.

And the problem keeps growing. GitGuardian's State of Secrets Sprawl 2025 report counted around 23.8 million new secrets exposed in public GitHub repositories in a single year. And most leaked secrets remain valid long afterwards. Nobody rotated them. Nobody noticed.

Notice the pattern. None of these cases required a criminal genius. All it took was someone looking carefully at something that should have been private and was not.

The rule that is not negotiable

So let me state the rule. Password, API key, token, certificate, connection string, signing secret. None of it lives in the code. Ever. Not in the app, not in the front end, not in the private repository, not in the test commit you were going to delete later.

A secret lives on the server. In a secrets vault, a cloud credentials manager. It is injected at runtime, in the environment you control, with access restricted to whoever needs it. The code asks. The server decides whether to hand it over.

The app running in the customer's hands must be treated as public territory. It does not keep secrets. It does not make sensitive decisions. It does not talk directly to the database or to the paid API. It talks to your back end, and the back end talks to everything else, authenticating, limiting, logging. If the business rule matters, it runs on the server. If the validation matters, it runs on the server. Whatever sits on the client can and will be read.

Security is architecture, not a patch

Obfuscating the code helps. It slows the curious. It does not stop the determined. Obfuscation is a curtain, not a wall.

Real protection is designed in layers. Secrets centralised in a vault and never in the repository. Short lived credentials that expire on their own, instead of eternal keys. Periodic rotation, so an old leak becomes a useless key. Least privilege, so each key opens only the door it needs to open. Automatic secret scanning before every commit and in every pipeline, because human error will happen and the machine needs to catch it before the world does. App attestation, so the server knows whether it is talking to the legitimate app or to a clone. Monitoring, to spot anomalous use before it becomes a headline.

And a point I see few people discuss. AI squeezes both sides of the equation at once. On one side, tools like REA make reading your software cheap for anyone. On the other, entire teams generate code with assistants at unprecedented speed. Prototypes become production in days. And it is exactly in that rush that the language model API key ends up in the front end, in plain sight, running up a bill nobody predicted. AI agents, in turn, operate with credentials and access real systems. An agent with an exposed key is not an assistant. It is an open door with autonomy.

Speed without governance is just accelerated risk.

The view of the people who build

I come from design. And I learned early that a good experience hides complexity from the user without hiding the responsibility of the people who build it. Security is the same. It does not show up on screen. Nobody praises the secret that did not leak. But it is part of the experience as much as a well designed button.

At Mars we treat this as a foundation. The biggest barrier to enterprise AI is trust, not technology. And trust is not born from promises. It is born from architecture. From knowing exactly where each secret lives, who accesses it, for how long and with what trail. Privacy by design starts there, long before the first piece of personal data enters the system.

Governance is not bureaucracy. It is what lets you grow without fear of opening your own product to the world. Because you will open it. Every time you publish.

The invitation

Try a simple exercise this week. Ask your team to look for passwords, keys and tokens in the code, in the repository history and in the published apps. Not to find culprits. To find open doors.

If the answer is “we have nothing like that”, be kindly suspicious and ask for an automated scan. If the answer is “we have a few”, congratulations. You just found out before the attacker did.

Assume your code will be read. Not by a person. By an agent, with infinite patience. Build as if it already has been. And leave secrets where they belong. On the server. Under control. Never in the code.

The best way to predict the future is to create it. And no digital future stands on top of a forgotten key. How much of your product do you still treat as a vault, when it is already a shop window?