Defending Against Model Extraction Attacks

Every trained model carries a reflection of itself in its answers. Ask it enough questions, watch enough of its outputs, and a patient adversary can begin to reconstruct the thing itself: a shadow copy of weights that took months and considerable capital to train. This is model extraction, and it is one of the quietest thefts in modern computing, because nothing is broken into and nothing obvious goes missing. The model simply answers, as it was built to do, and each answer leaks a little more of its inner shape.

For any organisation whose advantage lives inside its own models, this is an existential risk rather than an academic one. At Mickai we treat owned model weights the way the ancients treated the face of Medusa: a thing so potent that no attacker should ever be permitted to look upon it directly. In this piece we set out what model extraction actually is, why the usual defences fail at the regulated boundary, and how our Sovereign Intelligence Operating System, a SIOS that is built and live, protects your reflection so it can never be turned into stone against you.

What a model extraction attack really is

Model extraction, sometimes called model stealing, is the reconstruction of a proprietary model without ever holding its files. The attacker interacts with the model through its ordinary interface, submits carefully chosen inputs, records the outputs, and trains a substitute model that behaves almost identically. The stolen copy need not be perfect. It only needs to be good enough to compete with you, to skip the training cost you paid, or to become a testbed for finding weaknesses to exploit later.

There are several flavours. Functional extraction clones the input-to-output behaviour. Parameter extraction goes further and attempts to recover the actual weights of smaller or exposed models. Architecture and hyperparameter probing works out how the model was built. Each variant feeds the next, and each becomes cheaper as query costs fall and as attackers automate the questioning. The uncomfortable truth is that a model which answers freely is a model that teaches, and it will teach a thief as readily as a customer.

Why your weights are your reflection

Trained weights are not merely a file. They are the compressed record of your data, your domain expertise, your labelling decisions, and the countless training runs that shaped them. In the myth, Medusa could not be approached head on, because her gaze turned onlookers to stone. Perseus prevailed only by refusing to look at her directly and studying her reflection in a polished shield. Model extraction inverts that story in a way that should worry every model owner: here it is the attacker who studies the reflection, gathering fragments of the true form until they can forge a copy.

So the defensive question is precise. How do you let legitimate users benefit from a model while denying an adversary the sustained, structured, high-volume reflection they need to reconstruct it? Answer that and you have closed the extraction surface. Fail to answer it and every query you serve is a small donation to whoever is patient enough to collect them.

Why cloud-era defences fall short at the boundary

The common playbook is rate limiting, output rounding, watermarking, and anomaly detection on query patterns. These help, and we use them, but they share a fatal assumption: that your model runs somewhere you do not fully control, exposed through an interface you can only partly instrument. In a regulated environment, a defence expressed to a distant application programming interface (API) provider is a promise you cannot audit and cannot prove. When a regulator under the European Union Artificial Intelligence Act (EU AI Act), the Digital Operational Resilience Act (DORA), or the General Data Protection Regulation (GDPR) asks you to demonstrate exactly who queried your model, how often, and with what intent, a screenshot of someone else's dashboard is not evidence.

The public cloud giants are allies, and they operate a different layer of the stack extremely well. But there is a boundary they cannot cross on your terms: the point at which your weights, your queries, and your audit trail must remain provably under your own control, on hardware you own, with zero data egress. That boundary is exactly where model extraction is won or lost, and it is exactly where we built Mickai to live.

How Mickai seals the extraction surface

We start by making the model something an attacker cannot simply hammer with queries in the dark. In Mickai, the model weights are owned assets that run on your own hardware, air-gapped or on-premise, never shipped to a third party. Every request that reaches a brain, our term for a governed model, is mediated by an Operation Attestation Record (OAR), which signs the intended action before it executes. Nothing runs unsigned. That single primitive turns an anonymous flood of extraction queries into a stream of individually attested, individually accountable operations.

On top of attestation we layer behavioural governance. Brains are revocable, so a client, key, or workload that begins to exhibit the tell-tale rhythm of an extraction campaign can be suspended instantly and provably. High-stakes actions, including any bulk export or any access pattern that resembles systematic probing, require multi-brain agreement plus voice-biometric approval before they proceed. The reflection an attacker needs is a sustained, high-volume, structured interrogation. We make that interrogation impossible to conduct anonymously and impossible to sustain unnoticed.

Because everything runs inside your own perimeter, we can also do what a distant API never can: instrument the model end to end, correlate query patterns against attested identities, and cut the connection between an extraction attempt and any useful signal long before a substitute model could ever be trained. The weights stay behind the shield. The attacker is left studying noise.

Proving the defence held: the tamper-evident ledger

Prevention is only half of trust. The other half is proof. Every OAR in Mickai is written into a tamper-evident, cryptographically-signed audit ledger built on SHA-3-512 hash-linked chains, so each record is bound to the one before it and no entry can be altered or removed after the fact without breaking the chain. When you need to demonstrate to a board, an auditor, or a regulator that no extraction campaign succeeded, you are not offering assurances. You are offering a signed, ordered, offline-verifiable record of every query your model ever answered and every decision made about it.

Those signatures are post-quantum by design. We sign with the FIPS 204 Module-Lattice Digital Signature Algorithm (ML-DSA-65), so the evidence remains sound even against an adversary with a future quantum computer. A stolen model is a permanent loss, and the proof that yours was never stolen must last as long as the model's value does. Signatures that a quantum machine could forge tomorrow are no protection for weights you intend to defend for a decade. This is one capability among the 104 filed United Kingdom patent applications, covering 2,340 claims and owned by Mickai LTD, that describe how we defend the sovereign boundary.

The bottom line

Model extraction does not kick down a door. It asks polite questions and walks away with your reflection, one answer at a time. Rate limits and watermarks slow it a little, but the only durable defence is to keep the weights, the queries, and the proof on hardware you own, with every action attested before it runs and every record sealed in a chain no one can quietly rewrite.

That is the boundary Mickai was built to hold. Your model is your reflection, and like the face of Medusa it is far too powerful to leave exposed to any gaze that means it harm. We give you the polished shield: the attestation, the revocable brains, the post-quantum ledger, and the sovereign perimeter that together make certain no attacker ever looks upon your weights directly, let alone carries them away. Micky Irons, founder and CEO of Mickai.