How to Protect Your Software When AI Can Reverse Engineer Anything: A UK Guide for Owners

What has AI reverse engineering changed for software owners?

It has removed the practical barrier, not the legal one. Compiled code used to protect itself through cost: understanding a binary needed a specialist and weeks of work. Tools such as REA (Reverse Engineer Anything) connect AI coding agents to established decompilers like Ghidra and IDA Pro, so that analysis can now be started by anyone with a coding agent.

REA’s README lists native binaries, JavaScript and Electron apps, .NET assemblies, Android packages, firmware, and websites among its targets. Its intended uses are lawful research, interoperability, preservation, and software the user owns or is authorised to examine. Not everyone who uses it will stay within those limits.

The legal position for people using these tools against software they do not own is set out in our companion guide, is REA legal, and is SaaS reverse engineering lawful. This guide looks at it from the other side: if you own software, what protects you, and what should you do now?

What does UK law protect, and what does it leave open?

Copyright protects the expression of your software, not what it does. That has been the position in UK law for some time, and it means a competitor who builds the same features from scratch has not infringed anything. Your protection lies in a combination of rights, each covering something different.

The two leading cases show both sides. In Navitaire v easyJet (2004), the replacement booking system’s business logic did not infringe, but easyJet was found to have infringed by copying icons used in the interface. In SAS Institute v World Programming Ltd, building a compatible product did not infringe, but World Programming’s own manual was found to have reproduced parts of SAS’s manuals.

Those details matter for owners. The copying that tends to be actionable is copying of concrete expression: code, documentation, artwork, and data. Make sure you hold those rights and can prove it.

Can I ban reverse engineering in my licence?

Partly. Section 296A of the Copyright, Designs and Patents Act 1988 (CDPA) makes a contract term void to the extent it prohibits or restricts three acts by someone using your program under an agreement:

• Making a necessary back-up copy
• Decompiling for interoperability, where the conditions in section 50B are met
• Observing, studying, or testing how the program functions, under section 50BA

Everything else is a matter for your contract. That includes restrictions on decompiling for other purposes, on copying or adapting the program to correct errors, and on automated access to your service.

Draft the terms you can enforce

We would expect a well-drafted licence or SaaS agreement to cover the following points, each reviewed by your solicitor:

• Reverse engineering, prohibited except to the extent applicable law expressly permits it, so the clause does not fail by overreaching
• Automated access, including scraping, bulk extraction, and the use of AI agents against the service outside documented APIs
• Non-public documentation and API schemas, designated as confidential information
• Competing use, restricting use of the service or its documentation to build a competing product, drafted narrowly enough to survive a restraint of trade challenge
• Who is bound, with the customer responsible for its users, contractors, and affiliates
• Governing law and jurisdiction, chosen deliberately

Watch the drafting detail

In SAS Institute v World Programming, the licence restricted use of the software to a named ‘Customer’. The Court of Appeal read that ambiguous term against SAS, as the party that drafted it, and held that World Programming as a company was entitled to use it. A term that does not clearly say what you mean may not protect you when you need it.

Make sure the terms are actually accepted. Keep records of who accepted which version, and when, for click-through and online terms.

Does SaaS give me more protection than installed software?

In practice, yes. Most of a SaaS product’s logic runs on your servers, which no reverse engineering tool can reach. The statutory rights in sections 50B and 50BA belong to a lawful user of a copy of a program, and a SaaS customer may never hold a copy of your server software. We have not found UK authority on how those rights apply to hosted software, so treat this as an advantage of architecture rather than a settled legal point.

The parts of a SaaS product that are exposed are the ones you distribute:

• The JavaScript your users’ browsers download
• Desktop, Electron, and mobile clients
• The structure of your API responses and network traffic

How should we change our architecture?

Assume that anything you ship to a user’s device can be read and explained by an agent. Design on that basis.

Keep valuable logic on the server

Pricing rules, scoring and matching algorithms, risk models, and proprietary calculations belong behind your API. A thin client that presents results and collects input reveals little that a competitor could not see by using the product.

Remove secrets from distributed code

API keys, signing secrets, and internal endpoints sometimes end up embedded in front-end bundles and mobile apps. REA and similar tools will find them quickly. Move them server-side, rotate any that have been exposed, and scan your build output for them as part of continuous integration.

Make the API a controlled boundary

Authenticate every call, rate-limit per account, and monitor for access patterns that look automated. Return only the fields the client needs, because detailed responses can expose your data model.

Treat obfuscation as a speed bump

Obfuscating and minifying distributed code raises the effort for a casual attempt. It will not stop a determined agent connected to a decompiler, and it should not be the protection you rely on.

What evidence should we keep in case we need to enforce?

Enough to prove three things: that you own the rights, what the original looked like at a given date, and that the other side’s product copied it.

Rights. Know whether you own the copyright in your code or hold it under licence. Employees’ work is ordinarily owned by the employer, but copyright in commissioned software stays with the developer unless it is assigned. That matters for enforcement: under the CDPA an exclusive licensee can bring infringement proceedings, but a non-exclusive licensee can do so only if a signed licence expressly grants that right. Otherwise you rely on the copyright owner to act. Our founder ownership checklist sets out what to collect.

Dated originals. Your version control history, design files, and documentation releases show what existed and when. Keep them complete and unaltered.

Human authorship. Copyright needs an original work. The position under UK law for code generated with little human creative input is unsettled. Recording the human design, review, and direction behind your codebase helps you show authorship if you ever need to. Our blog on AI code ownership for UK CTOs covers this in more detail.

Detectable markers. Distinctive identifiers in your documentation, sample data, or reference content can show copying if they reappear elsewhere. They work best for content and data, which are also where copying is easiest to prove.

Should we register our interface as a design?

Where your interface or icons are distinctive, registration is worth considering. The UK Intellectual Property Office accepts registered design applications for graphical user interfaces, icons, and animated designs. It issued updated practice guidance (Designs Practice Notice DPN 01/26) in April 2026, and further reform of design law is under consultation.

A registered design protects appearance, not function. It will not stop a competitor building a product that works the same way with a different look. Standard layouts, tables, and forms are unlikely to qualify.

What should we do if we think someone has cloned our product?

Start with evidence, not a letter. Similar features are not infringement, so the question is whether they have taken your code, documentation, design, or data.

1. Preserve evidence. Capture the other product, its distributed code, its documentation, and its marketing, with dates.
2. Compare expression. Look for reproduced code, structure, comments, error messages, help text, icons, and data. Identical mistakes and your detectable markers are strong evidence.
3. Check your own rights. Confirm you hold the copyright, design, or database right you intend to rely on, and that the other party accepted your terms.
4. Take advice before writing. The Intellectual Property (Unjustified Threats) Act 2017 applies to threats of proceedings for patent, trade mark, and design infringement. An unjustified threat can expose you to a claim, so involve a solicitor before any letter mentions those rights.

Where is your real advantage?

In the things a reverse engineering tool cannot extract. If a competitor or a customer can reproduce your features in weeks, the features were never the moat. The durable advantages are:

• The data your product accumulates, and the insight you derive from it
• Integrations that customers depend on and would have to rebuild
• Service, support, and domain expertise
• The pace at which you improve the product

There is a commercial lesson in this too. We write about why organisations replace SaaS with custom software, and the triggers tend to be cost that outruns value, workarounds, and lock-in. Owners who address those in their pricing and product give customers less reason to try.

A checklist for software and IP owners

1. Confirm what rights you hold in your code, whether by assignment or licence, and who can enforce them.
2. Review your licence and SaaS terms against the points above, with a solicitor.
3. Audit what you distribute. Identify the logic and secrets in browser bundles, desktop clients, and mobile apps.
4. Move valuable logic server-side where it is currently in the client.
5. Harden the API with authentication, per-account rate limits, and monitoring for automated access.
6. Keep dated records of code, design, documentation, and human authorship.
7. Consider registering distinctive interfaces, icons, and product names.
8. Plan your response to suspected copying, so you act on evidence and advice.

Where to go from here

The legal protection for software has always been narrower than many owners assumed, and AI tools have made that visible. The owners in the strongest position combine clear ownership, careful terms, sensible architecture, and a product that keeps earning its place.

If you want to review how exposed your product is, or move valuable logic out of distributed clients, book a consultation. For the other side of the question, read is REA legal? AI reverse engineering, SaaS, and UK law.

This guide provides general information about UK intellectual property and contract law as it applies to protecting software. It is not legal advice, and it reflects the position as at October 2026. Several of the questions it raises, particularly around hosted software and AI-generated code, have not been decided by UK courts. Talk Think Do is a software development consultancy, not a law firm, and nothing in this guide creates a solicitor-client relationship. Consult a solicitor qualified in intellectual property law for advice specific to your circumstances.