If an AI agent can study an application and recreate its functionality without access to its source code, has it infringed intellectual property rights?

Not necessarily. And that distinction is becoming more important as AI-assisted software development evolves.

A tool called REA ("Reverse Engineer Anything") has drawn wide attention since it appeared on GitHub in April 2026. Its documentation describes a single Model Context Protocol (MCP) server that connects AI coding agents to tools for inspecting native binaries, JavaScript and Electron applications, .NET assemblies and websites, using an existing Hopper, Ghidra, IDA or Kuna installation for native analysis (REA). Its proposition, in its own words: "See a feature in an app that you want in your own product? Ask your agent to investigate it with REA. It can inspect the app without its source code, explain how the feature works, show the evidence, and build a version for your project."

The project also states that it "is for lawful research, education, interoperability, software preservation, and analysis of software you own or are authorized to examine."

These techniques are not new. Reverse engineering has long been used in software development, security research, interoperability work and competitive analysis. What is changing is how accessible those capabilities become when an AI agent can examine software artefacts, interpret the technical findings and generate implementation code in one workflow.

That raises a legal and governance question: where does legitimate reverse engineering end and unlawful appropriation of intellectual property begin?

1. Reverse engineering is not inherently unlawful

Whether reverse engineering is lawful depends on the software examined, the rights of the person examining it, the techniques used and the purpose of the activity.

In the EU, Directive 2009/24/EC on the legal protection of computer programs protects "the expression in any form of a computer program", while "ideas and principles which underlie any element of a computer program, including those which underlie its interfaces, are not protected by copyright" (Article 1(2)). Reproducing, translating or adapting the program are acts the rightholder controls (Article 4(1)), subject to two exceptions that matter here.

Article 5(3) entitles a person having a right to use a copy of a program, without the rightholder's authorisation, to observe, study or test its functioning in order to determine the ideas and principles underlying any element of it, provided this is done while loading, displaying, running, transmitting or storing the program in ways that person is entitled to.

Article 6 separately permits decompilation, the reproduction and translation of code, where it is indispensable to obtain the information necessary for the interoperability of an independently created program. It applies only if the acts are performed by a licensee or another person with a right to use a copy (or on their behalf), the information was not already readily available to them, and the acts are confined to the parts of the program necessary for interoperability.

Two provisions set the boundaries of these exceptions, and both bear directly on an agent asked to "build a version" of what it found.

First, information obtained by decompilation may not be used "for the development, production or marketing of a computer program substantially similar in its expression, or for any other act which infringes copyright" (Article 6(2)(c)). Decompiling for interoperability does not license building a lookalike.

Second, the exceptions cannot be contracted away. "Any contractual provisions contrary to Article 6 or to the exceptions provided for in Article 5(2) and (3) shall be null and void" (Article 8). A licence term forbidding a licensee to observe, study or test how the software works does not, as a matter of EU copyright law, stop that observation.

These provisions recognise that copyright should not prevent all examination of how software works. They do not create a general right to decompile, reproduce or commercialise protected code. A lawful opportunity to observe software behaviour does not authorise every technique an AI agent might go on to use.

2. Can someone lawfully recreate another application?

The leading European judgment is SAS Institute Inc. v World Programming Ltd (Case C-406/10). World Programming had built software that reproduced the functionality of SAS Institute's system. On 2 May 2012 the Court of Justice, interpreting Directive 91/250/EEC (since codified as Directive 2009/24/EC), held that neither the functionality of a computer program nor the programming language and the format of data files used in it to exploit certain of its functions constitute a form of expression of that program, and so are not protected by copyright in computer programs as such (C-406/10).

The Court also held that a person who has obtained a copy of a program under a licence may observe, study or test its functioning to determine its underlying ideas and principles while carrying out acts covered by that licence, on condition that the person does not infringe the copyright owner's exclusive rights.

The facts matter. The Court recorded that World Programming did not have access to SAS's source code and did not decompile its object code; it reproduced the functionality by observing, studying and testing the program's behaviour. The judgment is therefore not permission to decompile a competitor's application or copy its implementation.

Nor is everything visible in a product free to reproduce. In the same judgment the Court held that reproducing, in a program or its user manual, elements described in another program's user manual can infringe the copyright in that manual where the reproduction expresses the intellectual creation of the manual's author, a matter for the national court to decide. Original code, graphics, text and documentation can remain protected.

A business may therefore lawfully develop software that performs similar functions to a competitor's product and still infringe rights if it reproduces protected expression along the way. Functional similarity is not, by itself, proof of infringement. Independent implementation is not a defence to every form of copying.

3. Reverse engineering and trade secrets

Copyright is only part of the picture. Reverse engineering can also engage trade secret protection under Directive (EU) 2016/943.

Information is a trade secret only if it meets three requirements: it is secret, in the sense of not being generally known among or readily accessible to people who normally deal with that kind of information; it has commercial value because it is secret; and the person lawfully in control of it has taken reasonable steps in the circumstances to keep it secret (Article 2(1)).

Article 3(1) treats acquisition as lawful when it comes from independent discovery or creation, or from "observation, study, disassembly or testing of a product or object that has been made available to the public or that is lawfully in the possession of the acquirer of the information who is free from any legally valid duty to limit the acquisition of the trade secret."

That final condition is where the two regimes part ways. Under the Software Directive, a contract term that forbids a licensee to observe, study or test a program is void (Article 8). Under the Trade Secrets Directive, reverse engineering is a lawful route to a trade secret only for someone free from a legally valid duty to limit that acquisition. The same "no reverse engineering" clause may therefore have no effect on the copyright exceptions and still matter to whether a trade secret was lawfully acquired. Whether a given clause is a legally valid duty is a question for national law.

For software companies, the reasonable steps that keep information secret may include access restrictions, confidentiality agreements, secure development practices and protection of sensitive technical documentation. AI-assisted reverse engineering does not remove these protections. It makes it more important to know which parts of a technology can be independently discovered and which depend on confidential information that the law protects.

4. The governance problem: when an AI agent performs the investigation

Consider a developer who instructs an agent: "Analyse how this competing application implements its search function and build something similar for our product."

The instruction may look commercially ordinary. The agent might then observe publicly accessible behaviour, examine browser-delivered JavaScript, analyse a locally installed application or inspect compiled code, and then generate code that implements what it found.

The legal position depends on what the agent accessed, which acts were permitted, what information it extracted and whether the new implementation reproduces protected material. The organisation may have limited visibility into how an AI-generated implementation was produced. Several questions follow:

  • Was the original software accessed lawfully, and under what licence or terms?
  • Did the analysis stay within what Article 5(3) or Article 6 permits?
  • Was decompilation indispensable for interoperability, and is its output being used only for that purpose?
  • Did the analysis work around a technical protection measure? Directive 2009/24/EC requires remedies against putting into circulation, or possessing for commercial purposes, any means whose sole intended purpose is to facilitate the unauthorised removal or circumvention of a technical device protecting a program (Article 7(1)(c)).
  • Are there confidentiality or other contractual duties that bear on trade secret acquisition, even where a clause cannot override the copyright exceptions?
  • Did the agent reproduce protected code, documentation or graphical assets?
  • Can the organisation show independent implementation?
  • Was proprietary or personal information sent to an external model provider?

A developer's intention to create something similar is not necessarily unlawful. That intention does not excuse infringing acts performed along the way. An AI agent is not a way around legal limits that would apply if the same work were done by hand.

5. Why provenance becomes an IP governance issue

AI-assisted development introduces an evidential problem. If an organisation is challenged over the origin of a software feature, can it explain how the implementation was produced?

Evidence of independent development has traditionally included design specifications, source-control history, technical documentation and records of development decisions. With AI agents, further records become relevant: the instructions given to the agent, the sources it was authorised to examine, its analytical outputs, the generated code, human review and any similarities to third-party material that were identified.

The objective is not to retain every token. It is to keep enough evidence to establish the provenance of material decisions and development artefacts. A governance framework can distinguish four stages:

  • Observation: understanding the behaviour of software the organisation is entitled to examine.
  • Analysis: investigating relevant technical information by legally permitted methods.
  • Implementation: building an independently created solution without reproducing protected material.
  • Verification: reviewing outputs for intellectual property, contractual, confidentiality and security concerns before release.

These need not be separate technical processes. The organisation should be able to show that the legal boundaries were respected at each one.

6. AI does not remove other legal obligations

Reverse engineering can also engage cybersecurity, data protection and contractual obligations. Testing that exceeds authorised access raises legal issues beyond copyright. Analysing an application can expose personal data, credentials, configuration information or proprietary business information.

REA itself shows how close these questions sit. It can turn recorded API requests and responses into tools an agent can call, to build environments for training and testing agents. Recordings of real traffic can contain personal data. Where personal data is processed, the GDPR applies, including the principles of lawfulness, purpose limitation and data minimisation (Article 5(1)), a lawful basis for the processing (Article 6) and security of processing (Article 32) (GDPR).

External AI services add a further question: what information is transmitted to, stored by or used by the provider. REA states that it analyses targets locally, and that the agent receives the tool results while "its model provider has its own data policy."

Popularity brings a supply-chain risk of its own. Copies of the repository circulate under other names, and the project warns that "A similar repository name or copied README does not establish that a download is official." A developer who installs an analysis tool with broad local access from the wrong source has created a security problem before any analysis begins. For how quickly a weakness in shared software can reach many organisations, see When AI Finds the Flaw Before the Attack.

An organisation may therefore face several overlapping assessments: whether the reverse-engineering activity is lawful, whether what is accessed or copied is protected, whether personal or confidential information is involved, whether appropriate security safeguards are in place, and whether the resulting software can be released without infringing third-party rights. None of these is answered by checking whether the generated code looks different from the original.

7. Five governance controls for AI-assisted reverse engineering

  1. Define permitted use cases. Set out when reverse engineering is authorised: security testing, interoperability research, analysis of software the organisation owns, and appropriately governed competitive research.
  2. Apply access and scope restrictions. Require approval for sensitive targets, for decompilation and for any testing that may affect third-party services or systems.
  3. Protect confidential information. Control which source files, binaries, network captures, credentials and personal data may be processed by AI services, and install tools only from their official sources.
  4. Preserve development provenance. Keep records of sources, analysis methods, generated artefacts, human review and significant implementation decisions.
  5. Introduce intellectual property and security review gates. Review higher-risk generated implementations before they reach production, particularly where the agent analysed proprietary third-party software.

These controls do not make every reverse-engineering activity lawful. They help an organisation assess, document and manage the risks before those activities have operational or commercial consequences.

8. What this means for software owners

For businesses protecting their own technology, technical complexity alone is becoming a weaker barrier to competitors studying application behaviour or independently building similar features.

Software owners can distinguish the features customers can observe, the protected expression in their software, and the confidential know-how that gives them a competitive advantage. Protection may combine copyright, trade secrets, patents where available, contractual measures and information security controls. No single mechanism protects every aspect of a digital product, and contract terms cannot remove the copyright exceptions that Article 8 preserves.

Equally, the fact that another business can recreate a feature does not by itself establish that the original developer's rights were infringed. Both innovators and competitors need to understand that distinction.

Conclusion: easier to understand is not free to copy

REA illustrates how AI agents are changing the practical accessibility of reverse engineering. The legal principles governing software copyright, interoperability and trade secrets still apply. What changes is the speed and scale at which software can be examined, its behaviour interpreted and similar functionality built.

The right response is neither to assume that all reverse engineering is unlawful nor to assume that AI-generated implementations are automatically independent and safe. It is governance that permits legitimate research and innovation while respecting intellectual property, confidentiality, contractual duties and information security.

AI may make software easier to reverse engineer. It does not make intellectual property rights disappear.

How Priventia approaches it

Priventia's governing principle is that every compliance conclusion should be explainable. Its method links the legal requirements that apply to an organisation to the controls that address them, the evidence behind those controls and the monitoring that keeps them current, with every step traceable to the provision it comes from.

Intellectual property is one of Priventia's regulatory domains, with copyright as its first family, and its coverage will be built on the same discipline. The objective is not to automate legal judgment. It is to make the governance surrounding that judgment visible, repeatable and auditable.

Analysis current as of 29 October 2026. This article provides general regulatory analysis from an EU law perspective. Specific activities must be assessed under the applicable national law, contractual arrangements and the circumstances of access and use.

Primary sources

Priventia Regulatory Insight. Regulatory intelligence you can act on.