The vulnerability of proprietary AI models tends to be underestimated, but for companies and start-ups, it is a matter of protecting their assets

In the debate on the risks of artificial intelligence, the focus is mainly on hallucinations, bias, deepfakes, the unauthorized use of personal data and the impact on the world of work. Far less attention is paid to a risk that directly affects businesses: the theft of proprietary models.

For a start-up or a company, an artificial intelligence model can represent months or years of work, expertise and considerable investment. When the starting point is an open-source model, the competitive advantage stems from the work carried out to adapt it to a specific context: from proprietary data to fine-tuning, right through to any changes to the architecture. Stealing a model therefore means appropriating a significant part of the intellectual property of the organization that developed it.

AI models as corporate assets

Let’s imagine a start-up that has trained a system to detect anomalies in an industrial plant at an early stage. To build it, it may have collected data for years, worked with technicians and industry experts, analyzed thousands of faults and gradually refined the model’s ability to distinguish a real problem from a false alarm. The same applies to a system that analyses medical images, forecasts demand for a product, identifies suspicious financial transactions or supports the design of new materials.

The value of the model stems from the way in which it has incorporated data, experience and specific knowledge. Information that was previously scattered across databases, documents, processes and people can now be channeled into the behavior of a single system. The more effectively the model synthesizes an organization’s knowledge, the more valuable and attractive it becomes to a competitor or an attacker.

OWASP, one of the leading international organizations in the field of application security, defines ‘model theft’ as the unauthorized access, copying or extraction of a proprietary model, its weights or its parameters, to the extent of creating a functionally equivalent system. The consequences include financial losses and a reduction in competitive advantage.

Two ways to steal a design

The theft of an AI model can occur in two main ways.

The first is direct exfiltration. An attacker gains access to the files containing the model and copies them. They may do this by exploiting a misconfigured cloud storage service, compromising a server, stealing an employee’s credentials, or taking advantage of the legitimate access of someone within the organization. The model may also be exposed after deployment, that is, once it has been installed on a server or within a cloud infrastructure. At this stage, its parameters must be loaded into the system’s memory and made available to the processor or GPU performing the calculations.

The second type of attack is more subtle: the model is not copied directly, but replicated by observing its behavior. Many AI systems are accessible via APIs, which allow requests to be sent and responses to be received without knowing the model’s internal details. An attacker can, however, query the system on a large scale and use the responses collected to train a new model that replicates its capabilities. These are known as model extraction attacks. There is no need to reconstruct every parameter exactly: a substitute system capable of delivering similar performance may suffice, without incurring the costs involved in developing the original.

The issue has also recently come to light in the competition between the major tech giants developing AI models: in February 2026, Anthropic accused DeepSeek, Moonshot AI (the company behind Kimi) and MiniMax of using around 24,000 fraudulent accounts to generate over 16 million interactions with Claude and extract data useful for training their own models. According to Anthropic, this was a ‘distillation attack’ aimed at transferring capabilities such as reasoning, programming and the use of tools.

Why traditional security isn’t enough

Among the most common security and confidentiality measures adopted by companies are the encryption of stored data, the protection of communications and access control.

A model can therefore be encrypted when stored on disk, on company servers or in the cloud, and protected whilst in transit. The problem arises when it needs to be used. During inference – that is, the stage at which the model receives an input and produces an output – its parameters must be processed. In traditional solutions, these are first decrypted and loaded into memory. It is therefore precisely at the moment of use that the model, which appears to be protected, becomes available in plain text and vulnerable.

Firewalls, authentication systems and access controls remain necessary, but they do not prevent the model’s weights from being read from memory during execution.

Protecting the model during execution

The most complex challenge is to prevent the model’s parameters from becoming accessible whilst they are being processed. The available solutions take different approaches: some isolate the computing environment, others keep the processed information encrypted, whilst others distribute the computation across multiple entities.

Isolating computations: confidential computing

Confidential computing tackles this problem by isolating the environment in which the computation takes place. It is based on trusted execution environments (TEEs), which are secure areas of the processor where code and data can be processed whilst restricting access by the operating system, the cloud provider and other processes. These technologies are useful when a company needs to run its own model on infrastructure managed by third parties. Within the TEE, the model is made available to the processor within a hardware perimeter deemed trustworthy. Security therefore depends on the hardware, the firmware, the mechanisms that verify the integrity of the environment, and its correct configuration. Confidential computing protects the location where the computation takes place, but does not guarantee that the model remains encrypted throughout all operations.

Calculating on encrypted data: homomorphic encryption

A different approach is fully homomorphic encryption, or FHE, which allows calculations to be performed on encrypted data without first having to decrypt it. The result also remains encrypted and can only be read by those who possess the key. In architectures designed to protect the model, its weights can remain encrypted on the server during execution. In this case, protection is not based on isolating a specific area of hardware, but on the properties of the cryptographic scheme used and on key management.

Building trust: the MPC

In secure multi-party computation, or MPC, information is divided amongst several participants, who jointly perform the computation without any of them having access to the entire content. In this case, security does not depend on a single hardware environment or a single entity, but on the distribution of trust amongst the participants and the guarantees provided by the protocol.

Confidential computing, FHE and MPC can also be combined within the same architecture. The choice depends primarily on who manages the system, who holds the keys, and which parties must not be allowed to access the model or the user’s data. FHE and MPC generally require greater computational power and take longer to process than plaintext processing. However, performance depends on the scheme used, the type of operations required by the model, software optimisations and the available hardware. Practical solutions based on these technologies are already available on the market, applicable to specific models and use cases. Advances in algorithms, software and hardware are gradually expanding their scope of application.

A benefit for those who use AI, too

Model protection and the confidentiality of prompts and responses are two distinct requirements. When we use an AI service, the prompt is sent to the provider so that it can be processed. The connection is generally encrypted, but the request must still be made available in plain text within the infrastructure running the model. The user must therefore trust the security measures and data processing practices adopted by the service provider.

Some architectures based on homomorphic encryption allow both the model and the user’s data to be protected simultaneously. During server-side processing, the model weights, the prompt and the response can remain encrypted. The server or cloud platform thus performs the calculations without accessing either the proprietary model or the user’s confidential information in plain text. The response is decrypted only by the authorized recipient.

Security must be built in from the outset

Model security should not be addressed only after the model has been developed. A start-up that bases its service on a proprietary model should ask itself certain questions right from the start. Where will the weights be stored, and who will have access to them? In what form will they be loaded into memory? What would happen if the server hosting them were compromised? Access via APIs must also be considered: what information about the model’s behavior can be gleaned from the responses, and what indicators would allow an extraction attempt to be detected?

It is not enough to regard the model as a software component protected by the same security perimeter that safeguards the rest of the application. In many cases, the model is the product itself, or at least the part of the product in which the greatest competitive advantage lies.

Deploying a model in the cloud, at a client’s premises or on an external device increases the number of people and systems that could access it. The model must therefore be protected as an asset in its own right. Encrypting it whilst it is stored and securing the server are necessary measures, but they are not enough: protection must also continue whilst the model is running. 

ALL RIGHTS RESERVED ©