Inspired by a feature you like in another company's app? A new generation of AI reverse engineering tools are enabling developers to use an AI agent to investigate it without the source code, explain how it works, and "build a version for your project." REA ("Reverse Engineer Anything"), an open-source project that passed 100,000 GitHub stars in a single week this October, is the most visible example. It will not be the last.
In a companion article in this series on AI-enabled reverse engineering, I argue that these tools change the patents-versus-trade-secrets calculus for companies whose innovations any competitor can see or use. This second article in the series looks at the same AI tools from the other side. If your engineering team uses an AI tool to study a competitor's product and then builds something similar, which of the classic legal safe harbours for reverse engineering still protect you?
Fewer than your developers may think. The traditional defence was always qualified: "we reverse engineered it properly or for a permitted purpose." The workflow these AI tools make so easy undercuts both parts of that statement. Running analysis and implementation in one agent session breaches the wall that keeps a traditional "clean room" clean, and the use case the AI tools advertise, building your own version of a competitor's feature, falls outside the interoperability purpose the statutory exceptions protect.
What a clean room actually is
"Clean room" reverse engineering is an evidentiary technique, developed in the early 1980s when companies such as Compaq and Phoenix Technologies set out to build IBM-compatible BIOS software without infringing IBM's copyright.
The method involves carefully orchestrating two teams separated by a wall:
A "dirty" team studies the original product, including its code if necessary, and writes a functional specification describing what the software must do, with no expressive detail about how the original does it.
A lawyer reviews the specification and strips anything that looks like copied expression.
A "clean" team that has never seen the original writes new code from the specification alone.
Everything is documented, so that the company can later prove who saw what.
The purpose is to defeat the usual inference of copying. In copyright litigation in both Canada and the US, copying is often proven circumstantially: the defendant had access to the work, and the two works are similar. A properly run clean room breaks the chain. The people who wrote the new code demonstrably had no access, so similarity must come from shared function, industry standards or coincidence, rather than copying.
That is why clean rooms are expensive and slow. The cost is the point: the separation, and the paper trail proving it, is what makes the defence credible.
Where the AI agent workflow breaks the wall
AI coding agents can be used to run a clean room. However, used in the obvious way, they may break it in four different ways:
One context reads and writes. In the default workflow, the same agent session decompiles the target, reads its pseudocode and assembly, and then writes the new implementation. The dirty team and the clean team are the same entity, separated by nothing. The developer directing the session usually sees both sides as well.
The AI tool documents the access. These AI tools are built to show their work. REA, for example, returns the evidence and limitations behind each conclusion and can export evidence bundles. That is excellent practice for something like security research, but in a copyright dispute, it turns into a quite unhelpful record proving that the people and systems that wrote the new code had detailed access to the original.
The goal is a faithful copy. Reconstruction quality is measured by how closely the new code matches the old. One of REA's own published showcases describes reconstructing a function from a 1990s game in the C programming language that reproduces all 63 bytes of the original compiled function. That is mildly impressive, but not helpful as evidence of independent creation.
The model may already know the original. A clean room assumes the implementer starts with no knowledge of the original. A large language model starts with a great deal, and telling it to forget what it knows works about as well as telling a jury to disregard what it just heard. It was trained on vast amounts of public code, which for any open-source or widely published target almost certainly includes the original, its forks and discussions of how it works. Even a perfectly separated and prompted implementing AI coding agent may reproduce what it absorbed in training, and no log can prove that it did not. For those targets, a clean room run on a general-purpose model may never be clean. For proprietary, closed-source software the risk is lower, but not zero, because decompiled snippets, leaked code and look-alike projects circulate publicly.
In March 2026, the maintainer of the Python library chardet used an AI agent to rewrite it and changed its licence from the "copyleft" LGPL to permissive MIT, describing the result as a clean room implementation. Critics asked who had seen the original, and whether an AI that may have been trained on it can ever be "clean."
What about statutory permissions or exceptions?
What happens when the clean room fails? Developers may hope that certain reverse engineering permissions or exceptions in the law will cover them anyway.
Those permissions exist, but they are narrow. Canada's Copyright Act allows a lawful user to reproduce a program to obtain the information needed for interoperability, and to circumvent technological protection measures for the same purpose; the EU and UK decompilation rules are similar. In the US, courts have accepted disassembly as fair use where it was the only way to reach unprotected functional elements.
None of these helps a developer whose clean room has failed. In the US cases, the courts protected the copying done during analysis, and the products that shipped contained no copied code. Neither the courts nor the statutes have extended that protection to a product that carries over the original’s expression.
Hoist by their own logs
Patents are simpler and, for the copier, far worse.
Patent law has no reverse engineering exception, and independent creation is generally no defence. As ever, a perfect clean room protects against a copyright claim; it does nothing against a patent claim. If the feature your AI coding agent studied is covered by a valid patent, building your own version now infringes whether you read the original's code, watched a demo, or invented it alone in the dark.
What the AI agent workflow does add is a record. A session log showing that your team pointed an AI tool at the patentee's product, traced the patented feature and then implemented it is close to the ideal evidence of deliberate copying. In the US, deliberate copying is central to a finding of willful infringement, which can support enhanced damages of up to three times the actual damages. In Canada, there is no statutory enhancement, but deliberate copying can bear on punitive damages and on the court's view of the remedy as a whole.
The same AI tools that make it cheap to copy a competitor's feature also make it cheap for that competitor to detect the copy.
And you may not be able to own the resulting IP
Suppose the clean room holds and nothing infringes. The code the AI agent wrote may still belong to no one. Copyright generally protects only the work of human authors. In the United States that is now settled: in March 2026 the Supreme Court declined to hear Thaler v. Perlmutter, leaving in place the rule that copyright requires a human author, and the Copyright Office refuses protection for material an AI generates without sufficient human control. In Canada the question is open but leaning in a similar direction. The Federal Court is considering CIPPIC's challenge to a registration that named an AI tool as co-author, and Canadian law has long required the exercise of (human) skill and judgment.
A company that rebuilds a competitor's feature largely through an AI coding agent may take on real legal risk to produce code it cannot stop others from copying. It is the IP equivalent of paying full price for a public waterpark. That said, copyright still protects the parts a person meaningfully wrote, selected or arranged, so the extent of human contribution matters and is worth recording as the work happens.
As for patents, only a natural person can be an inventor. So, a team that hopes to patent improvements built on top of a reverse engineered feature will need to show that a person conceived the inventive step.
A clean room protocol for the AI agent era
Engineering teams can still use AI reverse engineering tools. Security analysis, interoperability work, debugging and analysis of your own software are legitimate and valuable use cases. Competitive analysis simply needs the same discipline it always did, now reconsidered with AI agents in mind.
Decide the purpose first, in writing. Is this security research, interoperability, analysis of your own code, or competitive feature work? The answer determines which safe harbour, if any, is available. If it is competitive feature work, involve counsel before anyone runs a tool.
Check the licence. Read the target's licence for reverse engineering and AI analysis restrictions before analysis begins. To be on the safe side, always assume such a clause will be enforced.
Separate the AI agents as well as the people. Run analysis in one AI agent environment and implementation in a completely separate one, with different staff, sessions, workspaces and repositories. The implementing agent must never have the target binary, its decompiled output or the analysis logs in its context.
Pass only a filtered specification across the wall. The analysis side produces a functional description of what the software does. IP legal counsel reviews it and removes code, pseudocode, data structures, naming and anything else that carries the original's expression.
Write the rules down for the AI agent. Give the implementing agent a written instruction, in its project rules or system prompt, that it must not read, disassemble or reproduce the target's code and may work only from the approved specification and public documentation.
Keep the logs, on both sides. The analysis logs show what was learned; the implementation logs show that it never crossed over. A clean room you cannot prove is not a clean room.
Run a freedom-to-operate check before shipping. The clean room addresses copyright. Only a patent search addresses patents, and the feature you are copying is precisely the kind of thing its owner may have patented.
This protocol cannot solve the training problem described above. Nor can it fix the ownership problem: code written largely by an AI agent may not be protected by copyright, however clean the room. If the target is open source or widely published, ask whether a clean room is credible at all, or whether taking a licence, or building on a different design entirely, is the safer route.
The bottom line
A properly run clean room is still a lawful way to build a competing product. What has changed is how easy it is to run one badly. The AI agent that studies a competitor’s product may be tainted from the word “go,” and, as with the jury, by then it is too late to ask it to forget. Even if it isn’t, someone has to make sure the wall is never breached. The best solution is to resist the temptation to build fast, and bring IP legal counsel in before the agent ever starts.
| This is the second of two companion articles in a series on AI-enabled reverse engineering. The first, The Secret Is Out: AI Reverse Engineering and the Patent vs. Trade Secret Decision, looks at what these AI tools mean for companies deciding how to protect their own innovations. |
This article provides general information only and is not legal advice. For advice on your specific situation, please contact Paul Horbal or a member of Marks & Clerk's Patents team.
Subscribe to receive more articles like this here.
/Passle/6130aaa9400fb30e400b709a/SearchServiceImages/2026-10-28-17-14-00-588-6ae22d58e61ce31b6e33b35c.jpg)
/Passle/6130aaa9400fb30e400b709a/MediaLibrary/Images/2026-10-29-10-38-48-615-6ae32238051015d5ddddcf62.png)
/Passle/6130aaa9400fb30e400b709a/SearchServiceImages/2026-10-28-16-21-42-746-6ae22116e61ce31b6e337d2c.jpg)