By Micky Irons, founder and CEO of Mickai.
Through the first half of 2026, the compliance calendar has sharpened a question that many organisations had been content to leave soft. The EU AI Act's Annex III high-risk obligations, once due on 2 August 2026 for systems that touch employment, credit, critical infrastructure, law enforcement and essential public services, now apply from 2 December 2027 after the Digital Omnibus deferral, and because the underlying proof requirements are unchanged, the sensible response is to build now rather than wait. DORA has governed operational resilience across EU financial entities since January 2025, NIS2 has widened the definition of an essential operator, and ISO/IEC 42001 has given boards a certifiable standard for AI management. Each of these regimes asks the same uncomfortable thing: show us who can touch the system, and prove it.
For any organisation running its intelligence on a third-party cloud, the honest answer is that it does not fully know. Data and models sit on infrastructure owned and administered by other people, in buildings the buyer will never enter, under legal jurisdictions the buyer did not choose. Security in that arrangement depends on trusting the provider's staff, the provider's controls and the provider's willingness to resist a lawful demand for access. That is not a criticism of any one company. It is a description of the architecture, and the architecture is the thing regulators now want examined.
The trust surface nobody puts in the diagram
Threat models tend to draw the attacker as an outsider: someone breaching a firewall, phishing a credential, exploiting a misconfiguration. The harder problem lives inside the perimeter. A privileged administrator at a cloud provider, a compromised support account, a subcontractor with maintenance access, or a compelled employee acting under legal instruction can all reach data that the customer believed was sealed. None of these actors needs to defeat encryption if they hold, or can be ordered to produce, the keys.
The OWASP work on AI risks has made this explicit for machine learning systems, naming sensitive information disclosure, supply-chain exposure and excessive agency as first-order concerns rather than footnotes. When the model, the prompts and the retrieval corpus all live on someone else's hardware, every one of those risks is amplified by a control boundary the customer cannot audit at the metal. The insider threat at the provider is simply the insider threat, relocated to a place where the buyer has no visibility and no veto.
Encryption at rest is not the same as custody
Providers rightly point to encryption at rest, encryption in transit and hardware security modules as evidence of diligence. These are real and valuable. They are also, on shared cloud infrastructure, defences whose keys are frequently managed within the same trust domain as the data. If the operator does not hold the only copy of the key, and cannot cryptographically prevent the provider from using it, then the protection reduces to a promise about process rather than a property of the system.
The distinction that matters is custody. Who physically possesses the key material, and can anyone outside the operator's building use it without the operator's participation? Where the answer involves any party beyond the operator, the security model contains a trusted third party by design, and that party becomes a target, a liability and a point of legal leverage all at once.
Jurisdiction travels with the data
Custody is not only a technical question. Under the US CLOUD Act, a provider subject to US jurisdiction can be compelled to produce data it controls regardless of where that data physically resides. A European operator whose intelligence sits with such a provider may therefore face a lawful foreign demand for access that it never sanctioned and may never be told about. For a public-sector buyer handling citizen records, or a regulated financial entity under DORA, that exposure is not hypothetical. It is a governance defect that no service-level agreement can fully close.
Data residency clauses help, but residency describes where bytes sit, not who can be ordered to reach them. The only arrangement that removes the foreign-demand problem is one where the operator holds the keys and the hardware, and no external party has the technical means to comply with such a demand even if served. Architecture, in this sense, becomes the strongest legal control an organisation owns.
Removing the outsider from the trust boundary
Mickai approaches this as a design problem rather than a policy one. A Sovereign Intelligence Operating System, a SIOS, runs offline on operator-owned hardware inside the operator's own building. The models are sovereign models held locally. The keys are generated and retained by the operator. There is no upstream tenancy, no shared administrative plane and no provider staff standing between the operator and its own intelligence. The set of people who must be trusted shrinks to the set of people the operator already employs and controls.
Identity in this arrangement is hardware-attested, so that a given action can be bound to a specific device and a specific authorised role rather than to a reusable credential that could be replayed elsewhere. The inbound perimeter is designed as zero-egress: the system is built to accept work without shipping the underlying data outward, so that sensitive material has no sanctioned path off the operator's hardware in the first place. When there is no egress, there is no provider to whom data could leak, and no external account whose compromise would matter.
Trust us is a request for faith, and faith is not a control a regulator can audit, a board can sign off, or an adversary can be prevented from exploiting.
Verifiability instead of assurance
A security claim that cannot be checked is a marketing claim. The design principle we hold to is that every consequential action should leave evidence the operator can inspect without asking anyone's permission. Actions are cryptographically sealed into a signed audit chain, and those signatures use post-quantum methods so that the record remains defensible against future cryptographic advances rather than only against today's attacker.
Because the chain is held by the operator, an auditor, a regulator or an internal investigator can verify what happened offline, from the operator's own copy, with no dependence on a provider's cooperation or honesty. This is the difference between assurance and verifiability. Assurance is a statement about the past that you are asked to believe. Verifiability is a property of the present that you can test. The compliance regimes now landing in Europe increasingly reward the second and are learning to distrust the first.
Consensus as a guard against a single point of failure
Concentrating intelligence in one model, on one provider, creates a single point of both failure and manipulation. If that one system is poisoned, misconfigured or quietly altered, everything downstream inherits the fault. The architecture uses cross-model consensus so that a high-stakes output is checked by more than one sovereign model before it is trusted, and disagreement is surfaced rather than hidden. This reduces the leverage any single compromised component holds over a decision.
None of this depends on believing that provider employees are ill-intentioned. Most are not. The point is that a serious security model should not require anyone to be trusted who does not need to be, and should not fail catastrophically if a trusted party is compromised or compelled. That discipline is reflected across the 104 filed UK patent applications and approximately 2,340 claims owned by Mickai LTD, which are patent pending and describe the sealing, attestation and consensus mechanisms as an integrated whole rather than as bolted-on features.
What the next audit will ask
The regulatory direction of travel is clear. Annex III of the EU AI Act, DORA, NIS2 and ISO/IEC 42001 are converging on a demand that operators demonstrate control, provenance and accountability over their AI systems, not merely attest to a supplier's good practice. An organisation that cannot name every party able to touch its data, and cannot prove it independently, is going to find that conversation harder each year.
The choice this frames is not cloud against on-premise as a matter of taste. It is a question of whether an organisation is willing to keep a stranger inside its trust boundary, and whether it can defend that decision to an auditor who now knows to ask. Operator-owned keys and on-premise hardware answer the question by removing it. When nothing and no one outside the building can reach the data, there is no insider at the provider to worry about, because there is no provider inside the model at all. That, rather than a promise, is what we build.
Written by Micky Irons. Originally published at https://mickai.co.uk/articles/the-insider-threat-at-the-provider-trust-us-is-not-a-security-model. More from Micky Irons and Mickai at mickai.co.uk.
Top comments (0)