Storage in the AI era (3/4): security

Contents

Data is the most valuable and most durable asset of an AI system. Models get retrained; weights get replaced; but training datasets, the customer data feeding RAG and the weights of a frontier model represent years of investment and, often, regulated information. In the two previous articles we discussed how to move that data fast. This third one is about how to protect it: encryption, integrity, access control, sovereignty and the threat that forces us to act today even though it looks distant, quantum computing.

Encryption at rest: SED, AES-XTS and the transition to FIPS 140-3

The first line of defence for any persistent data is encryption at rest. In enterprise storage the dominant pattern is the SED (Self-Encrypting Drive), a drive that implements the Trusted Computing Group’s Opal, Ruby and Enterprise standards and integrates a 256-bit AES-XTS encryption engine in the controller. The operational advantage is twofold: they encrypt at interface speed, with no perceptible performance penalty and without stealing CPU cycles, and they enable instant cryptographic erase.

The mechanism behind that erase is the two-tier key model of TCG Opal 2.0. Data is actually encrypted against a data encryption key (DEK) that never leaves the drive; that DEK, in turn, is protected by an authentication key derived from the user’s passphrase. Destroying or regenerating the DEK instantly renders terabytes of data unreadable without having to overwrite them: the cryptographic erase. For an organisation decommissioning 245 TB drives, this property is not a luxury, it is the only practical way to guarantee erasure.

SED hardware encryption and software encryption with AES-NI are not mutually exclusive, but they do have different profiles. Hardware acceleration keeps a measurable edge, on the order of 2 times on 4K random reads and writes compared with pure software, although the gap narrows on modern CPUs with AES-NI and ARMv8. The rule of thumb: SED for the baseline at no performance cost, and software encryption on top when you need key domain separation or end-to-end encryption.

The Achilles heel of encryption is never the algorithm, it is key management. Impeccable AES-256 protects nothing if the key is badly held. That is why serious storage encryption relies on an external key manager that speaks KMIP (Key Management Interoperability Protocol) to the arrays, separating custody of the key from the medium that encrypts. Keys are rotated periodically, backed up with their own availability guarantees (losing the key means losing the data as definitively as a fire would) and their access is audited. In regulated environments those keys live in certified hardware security modules (HSM). For an architect, the design decision is not “do we encrypt?”, the answer is always yes, but “who holds the keys and how are they governed?”, a question that, as we will see, sits at the heart of data sovereignty.

The point no architect should ignore in 2026 is the transition to FIPS 140-3. The CMVP stopped accepting new FIPS 140-2 validations in April 2022, and on 21 September 2026 it will move all remaining 140-2 certificates to the “historical” list. From that date, US federal agencies must not include historical modules in new procurements; existing systems can keep operating, but the compliance clock is running. And there is a logistical side effect: validation times have grown from 367 to 542 days, 42 % more, which strains vendor roadmaps. Anyone planning storage purchases on a multi-year horizon should verify 140-3 certification, not 140-2, for every cryptographic module. The reference framework for the overall design remains NIST SP 800-209, which covers encryption, isolation, authentication and authorisation for block, file and object storage.

Encryption in transit: the weak point of AI fabrics

Data is also exposed in motion, and here the high-performance fabrics of AI introduce specific tensions. For NVMe-oF over TCP there is in-band authentication, and for stronger protection the NVMe working group proposes IPsec over RoCEv2. Modern NICs (ConnectX-6 Dx, BlueField-2) secure NVMe-oF connections with hardware-accelerated IPsec and TLS, so encryption in transit does not throttle bandwidth.

The problem is InfiniBand. IPsec is not implemented over InfiniBand, since it is not an IP protocol, which leaves that fabric, ubiquitous in AI clusters, without one of the usual confidentiality tools. Nor does IPsec isolate well the RDMA connections of different users sharing the same interface. Academic research has documented attacks that exploit RDMA flaws in NVMe-oF storage applications. The conclusion for an architect is uncomfortable but important: in-transit security on an AI fabric is not inherited from the good habits of IP networks, and it demands explicit design of segmentation and isolation.

The threat arriving from the future: post-quantum cryptography

No storage security topic has changed its urgency as much as post-quantum cryptography (PQC), and the reason is an attack pattern that does not need a quantum computer to begin: "harvest now, decrypt later" (HNDL). Well-funded state actors are collecting encrypted data today with the intention of decrypting it once they have quantum capability. For any data whose confidentiality must last a decade, such as medical records, industrial secrets or proprietary training datasets, the threat is present, not future.

In August 2024 NIST finalised the first three PQC standards, and by mid-2026 they are the foundation on which the entire migration is built:

StandardAlgorithmFunctionOrigin
FIPS 203ML-KEMKey encapsulationCRYSTALS-Kyber
FIPS 204ML-DSADigital signature (default)CRYSTALS-Dilithium
FIPS 205SLH-DSABackup signature (hash-based)SPHINCS+

In March 2025 NIST additionally selected HQC, a code-based encapsulation mechanism, as a backup for ML-KEM with different mathematical assumptions. The NSA, for its part, set a demanding timetable in CNSA 2.0: by 2030 all software and firmware deployed in national security systems must use CNSA 2.0 signatures, with full enforcement expected around 2031-2033 and complete quantum resistance in 2035.

The pressure has intensified from the quantum hardware side. Between May 2025 and early 2026, several papers cut the estimates of qubits needed to break RSA-2048 from around 20 million to under a million, and even to figures on the order of 100,000 with new architectures. “Q-Day” around 2030 is increasingly cited by analysts, NIST and the NSA. It is not a certainty, but the safety margin has narrowed enough to make inaction imprudent.

The storage industry is already moving. NetApp announced PQC for data at rest in 2025, compliant with the NIST algorithms and integrated both at rest and in flight. Western Digital began integrating NIST-approved PQC into its Ultrastar drives in 2026, one of the first deployments in production infrastructure. Cohesity, Commvault and Quantum also have products along these lines. The dominant pattern in 2026 is not wholesale replacement but hybrid approaches that combine classical and post-quantum cryptography: they protect against a failure of the new algorithms and allow a gradual migration. For an architect, today’s concrete action is the cryptographic inventory, or crypto-agility: knowing which algorithms protect which data and planning their rotation.

Security specific to AI data: integrity and poisoning

Beyond classical encryption, AI brings a threat class of its own that falls directly on the data layer: data poisoning. An adversary manipulates training or fine-tuning data to corrupt what the model learns. Its distinctive trait is stealth: a poisoned model behaves normally for long periods before exhibiting the malicious behaviour, which makes it very hard to detect after the fact. The OWASP Top 10 for LLM applications of 2025 formally recognises “data and model poisoning” as an integrity attack category, with especially high risk when external sources are ingested.

The defence has moved towards provenance and lineage. Organisations are adopting rigorous documentation of every data source, a “digital chain of custody”, and the concept of the ML-BOM (Machine Learning Bill of Materials), analogous to the software SBOM. Frameworks such as the FINOS AI governance framework explicitly catalogue data poisoning among their risks. For storage, this means the system must be able to guarantee the integrity and immutability of training data and to record its lineage verifiably. Integrity stops being a desirable property and becomes a security control.

Model theft: when the asset to protect is the weights

There is one asset the traditional storage security conversation did not contemplate: model weights. Training a frontier model costs tens or hundreds of millions, and the result, a file of a few TB, concentrates all that value. Weight theft (model exfiltration) is consequently a first-order threat, and its attack surface is precisely the storage layer where checkpoints and final models live.

Protection combines several of the layers already described, applied with a specific focus. Encryption at rest with strict key control stops an attacker who reaches the drives from walking away with a usable model. Least-privilege access control limits who can read the weight directories, and auditing logs every access so anomalous exfiltration can be spotted; a process that suddenly reads 4 TB from a model directory is a signal. And confidential computing, which we will see further down, protects the weights even while they are being loaded into the GPU for inference. The lesson for the architect is that the trained model deserves, at minimum, the same defences as customer data, because its loss can be irreversible and its value greater.

Immutability and ransomware: the second phase of the attack

Ransomware remains the highest economic impact threat against storage, and its recent evolution points straight at backups. The reference defence is WORM immutability (Write-Once-Read-Many). In the object world, S3 Object Lock prevents modifying or deleting data even for an attacker with administrative credentials, neutralising the second phase of the attack, the encryption of the victim’s data. It has two modes: Governance, which can be overridden with specific permissions, and Compliance, which nobody can override, not even the root account. Object Lock creates a logical air gap that, for many use cases, makes tapes and physical air gaps redundant.

The numbers justify the investment. Ransom payments reached a record USD 1.1 billion in 2023; the average total cost of a ransomware attack was around USD 5.13 million in 2024, with an average recovery cost, excluding the ransom, of 1.53 million in 2025. Two out of three organisations suffered ransomware in the past year according to Sophos.

For an inference factory, ransomware has an angle of its own: the most valuable target is not only customer data but the model repository. Encrypting or deleting the weights the factory serves leaves it inoperative immediately, with a direct business impact, the service goes down, on top of the recovery cost. The defence is the same as for any critical asset, applied as a priority: immutable WORM copies of the model repository and of the vector indexes, so that a clean version of each model can always be restored even if the hot copy is compromised. A model that took months and millions to produce, or whose weights cannot be regenerated, deserves the strictest immutability protection available.

The storage-side response has been to integrate detection into the array itself. Dell PowerProtect Cyber Recovery offers an isolated, immutable vault with an automated air gap, and its CyberSense component uses AI and full content analysis, not just metadata, to detect ransomware corruption, with very high accuracy figures announced by the vendor. NetApp integrates Autonomous Ransomware Protection into the storage, creating immutable snapshots in real time by analysing data patterns at the storage layer. It is wise to treat the accuracy figures (99 % and above) as vendor claims rather than independent benchmarks, but the underlying trend is real: the storage array has stopped being a passive component and become an actor in the defence.

A useful framework for prioritising these investments is the annualised loss expectancy, which relates the impact of an incident to its frequency:

$$\text{ALE} = \text{SLE} \times \text{ARO}$$

where \( \text{SLE} \) is the expected loss per incident and \( \text{ARO} \) the expected annual frequency. Immutability and fast recovery act by reducing \( \text{SLE} \): even if the attack happens, the loss and the recovery time are bounded.

Access control and the cost of a breach

Encryption protects the data; access control decides who touches it. IBM’s Cost of a Data Breach 2025 report supplies the reference figure: the global average cost of a breach fell to USD 4.44 million, 9 % less and the first drop in five years, driven by faster containment thanks to AI-powered defences, with the average time to identify and contain falling to 241 days, the lowest in nine years. The United States, by contrast, set a record of 10.22 million. The largest cost component is still detection and escalation.

Mature architectures combine Zero Trust with RBAC as the base, ABAC attributes for fine grain and microsegmentation to prevent lateral movement inside the network. In an AI environment, where training data moves between data lake, pipeline and GPU cluster, microsegmentation and continuous contextual authorisation stop being optional.

Data sovereignty: the regulatory dimension

For a European company, AI storage security is inseparable from data sovereignty. The EU Data Act, applicable since 12 September 2025, mandates data portability and interoperability to eliminate vendor lock-in, and in its Chapter VII requires cloud providers operating in the EU to put in place technical, legal and organisational measures to prevent non-EU government access to non-personal data stored in the EU where such access would be unlawful under European law. This creates a documented tension with the US CLOUD Act, which empowers US authorities to claim data from providers under their jurisdiction regardless of where it is stored.

The technical answer gaining traction in 2026 is client-side encryption with full key ownership: whoever controls the keys controls the data, regardless of where it physically resides. “Whoever allows plaintext in the cloud cedes control” has become the motto of real sovereignty. For a European AI architect, data residency and key ownership are design decisions as important as performance.

The EU AI Act, furthermore, applies in phases that touch data governance: prohibited practices are enforceable since February 2025, obligations for general-purpose models since August 2025, and sanctioning powers since August 2026, although the provisional Digital Omnibus agreement of May 2026 postponed the deadline for Annex III high-risk systems to December 2027, a point worth re-checking given how recent it is.

Confidential computing: protecting data in use

Encryption at rest and in transit leaves a gap: data in use, decrypted in memory while it is processed. Confidential computing closes it with trusted execution environments (TEE). On the CPU, Intel TDX and AMD SEV-SNP launch confidential virtual machines with encrypted memory. The novelty for AI is on the GPU.

NVIDIA introduced confidential computing on the H100 (Hopper) with a CC mode and a root of trust in silicon: the CPU’s confidential VM exchanges encrypted data with an enclave in the GPU, extending the chain of trust from CPU to GPU. The Blackwell architecture (B200, GB200) has made the qualitative leap: it is the industry’s first GPU with TEE-I/O capability, with inline protection over NVLink and NVSwitch that removes the PCIe I/O bottlenecks of earlier generations. And what matters most for performance: thanks to AI-specific encryption engines and hardware-accelerated encrypted HBM access, the HGX B200 keeps its roughly 2 times advantage in training and 2.5 times in inference over the HGX H200 even with confidential computing fully enabled. This enables confidential training, inference and federated learning without the prohibitive penalty that previously made encrypting data in use unworkable, protecting both sensitive data and the model weights themselves from theft.

Security in a multi-tenant inference factory

Confidential computing takes on special meaning in an inference factory, above all if it serves several customers or teams on the same infrastructure. Here the attack surface is not only the disk at rest but the data in use of each request: the prompts, the context documents, the responses and, crucially, the KV cache. And the KV cache introduces a risk specific to inference that is worth naming: if a cache layer is shared between tenants to save compute, reusing prefixes as we saw in the performance article, badly isolated reuse can leak one customer’s content to another. The design rule is that prefix caching should only be shared within a single trust domain; between different tenants, KV cache isolation, whether in memory, in CXL or on NVMe, is a security control, not an optional optimisation.

The same principle extends to the factory’s other planes. The model repository must apply per-tenant access control so that nobody loads or extracts someone else’s model. The RAG vector database must segment indexes per customer, because an embedding retrieved from the wrong corpus is both a quality failure and a data leak. And telemetry, which records prompts and responses, is one of the most sensitive repositories in the whole installation, subject to the same encryption, retention and residency requirements as customer data. A well-designed inference factory treats each of these planes as an isolation domain, not as a resource shared for convenience.

An important technical nuance of confidential computing is attestation. A secure enclave is worthless if you cannot prove the data is really executing inside it and not in a compromised environment pretending to be one. Attestation is the cryptographic mechanism by which the hardware, the root of trust in the silicon of the GPU or the CPU, issues a verifiable proof of its state and identity before keys or data are entrusted to it. In a confidential AI architecture, the chain of trust extends from the CPU’s confidential VM to the GPU enclave, and every link is attested. For the architect, the operational question is who verifies those attestations and where the keys that are only released after a valid attestation are held: that is where confidential computing connects back to the key management from the start of the article.

A checklist for the architect

Gathering all of the above into actionable practice helps avoid leaving layers uncovered. At rest: SED with AES-XTS-256 as the baseline, external key management via KMIP with HSM, and verification of FIPS 140-3 certification on every module, anticipating September 2026. In transit: TLS 1.3 and IPsec wherever possible, with particular attention to isolation on InfiniBand fabrics, where the IP tools do not apply. Against the quantum threat: cryptographic inventory, crypto-agility and adoption of hybrid classical-PQC schemes for long-lived data, without waiting for Q-Day. Against ransomware: WORM immutability with S3 Object Lock in Compliance mode for critical copies, detection built into the array and tested recovery. On integrity: verifiable lineage and ML-BOM for training data, with reinforced protection of model weights. In the inference factory, additionally: isolation of the KV cache and of prefix caching between tenants, per-customer segmentation of the model repository and of the RAG vector indexes, and treatment of prompt and response telemetry as sensitive data. On governance: Zero Trust access control, microsegmentation and auditing. And on sovereignty: key ownership and data residency aligned with the EU Data Act and the EU AI Act. None of these layers substitutes for another; real security emerges from their combination.

Takeaways

AI storage security is a layered system that has to be designed all at once: encryption at rest with SED and migration to FIPS 140-3; encryption in transit with particular care on InfiniBand fabrics; crypto-agility and hybrid approaches to get ahead of quantum risk and harvest now, decrypt later; data integrity and lineage against poisoning; WORM immutability against ransomware; Zero Trust access control; data sovereignty through key ownership; and confidential computing to protect data and models in use. The good news is that the array is no longer passive: it defends. The bad news is that the most serious threat, the quantum one, demands action before it becomes visible.

The last article in the series closes with the property without which none of the previous ones matter: availability.

See also

Sources