When a European law firm shares confidential documents with a partner's or cross-industry AI system running in another data center, who can access those files? The answer may surprise you.
As organizations accelerate their AI adoption, a critical question emerges: who truly controls your data? The convergence of increasingly strict data sovereignty regulations in Europe, growing AI-specific security threats, and the fundamental limitations of traditional encryption solutions demands a new approach. Organisations need the ability to control their data beyond their perimeter — knowing who accesses each file, where it is processed, and retaining the power to revoke access at any time. In this article, we explore how AltaStata — an encrypted multi-cloud storage layer for AI — integrated with IBM Crypto Express Hardware Security Module (IBM CEX HSM) and running on IBM LinuxONE with IBM Confidential Computing. This solution stack delivers end-to-end data sovereignty for AI workloads as Confidential Computing provides a technical separation between the operational and workload layer enforced by the underlying hardware.
Data Sovereignty: Why It Matters Now
The Regulatory Landscape
Data sovereignty — the principle that data is subject to the laws and governance structures of the country where it is collected or processed — has become one of the most pressing concerns for enterprises operating across borders.
Several forces are driving this urgency:
- The EU AI Act (effective August 2025) introduces mandatory requirements for AI systems including data governance, transparency, and human oversight. High-risk AI systems must demonstrate robust data quality and security throughout their lifecycle. Article 15 mandates cybersecurity measures including resilience against unauthorized access and data manipulation.
- GDPR continues to enforce strict rules on cross-border data transfers, with penalties reaching €20M or 4% of global annual turnover.
- The EU Data Act (effective September 2025) establishes new rules on data access and use, giving businesses and consumers more control over their data.
- National sovereignty initiatives — France's SecNumCloud, Germany's Gaia-X, and similar programs across Europe all mandate that sensitive data remain under local jurisdiction and control.
Why Traditional Data Encryption Falls Short
Organizations face a fundamental dilemma: third party managed computing, like public cloud, provides the scale needed for AI, but traditional security approaches cannot guarantee data sovereignty:
|
Challenge
|
Impact
|
|
(Cloud or Service) Provider lock-in
|
Data and keys controlled by a third party or vendor
|
|
AI outsourcing
|
Sensitive data sent to external AI providers leaves the organization's control entirely
|
|
Encryption performance
|
Traditional encryption degrades processing speed
|
|
AI tool compatibility
|
Standard encryption solutions cannot work with AI frameworks
|
AltaStata, IBM and Red Hat address these challenges through a joint solution that delivers:
- Encryption for any cloud storage (AltaStata) — per-file, end-to-end, with no vendor lock-in
- Data security in use (IBM Confidential Computing) — hardware-level memory protection on LinuxONE via IBM Secure Execution and a confidential computing enabled container experience
- Data owner's hardware security module (IBM Crypto Express) — FIPS 140-2 Level 4 certified HSM
- Container platform (Red Hat OpenShift) — with OpenShift Data Foundation and sandbox containers operator
- Access control beyond the organization’s perimeter (AltaStata) — per-file visibility into who accesses data, real-time monitoring of sharing events, and the ability to revoke access at any time
- 3x faster with lower costs — AltaStata's data compression reduces storage costs up to 63% and boosts the speed
- Integrated with AI tools — seamless support for PyTorch, TensorFlow, LangChain, Spark, and more
IBM Crypto Services: Hardware-Rooted Key Protection
Why HSM-Based Key Management Matters
In AltaStata's encryption model, every file is protected with its own AES-GCM-256 data encryption key (DEK). These DEKs are wrapped (encrypted) with the user's RSA or PQC public key. The corresponding private key is the crown jewel — whoever holds it can decrypt any file shared with that user.
Traditional approaches store the private key as a PEM file on disk, protected by a password. This introduces risks:
- If the host is compromised, the private key can be extracted from memory
- Administrators with access to the filesystem can copy the key
- In cloud environments, the infrastructure provider could theoretically access the key
An IBM Crypto Express based Key Management or IBM Crypto Service eliminates these risks by keeping the private key inside a FIPS 140-2 Level 4 certified Hardware Security Module (HSM). The private key never leaves the HSM — all cryptographic operations (decryption, signing) happen inside the hardware boundary.
How AltaStata Integrates with IBM Crypto Express
AltaStata integrates with IBM Crypto Express through the Enterprise PKCS #11 over gRPC (GREP11) protocol, which allows applications to perform cryptographic operations remotely on the HSM without exposing key material.
The integration works at two levels:
1. Key Generation — When an administrator provisions a new AltaStata user with IBM Crypto Express protection, the system:
- Generates an RSA key pair inside the HSM via the GREP11 GenerateKeyPair API
- Exports only the public key (as PEM) for use in encryption and verification
- Stores an opaque key blob — the private key rooted by the master key only present in a given domain of the IBM Crypto Express HSM, but contains no extractable key material
2. Runtime Operations — When the user needs to decrypt data or sign a request:
- The application sends the encrypted data and the key blob to IBM Crypto Express HSM via GREP11
- The HSM uses the wrapped private key to perform the operation inside the hardware boundary
- Only the result (decrypted DEK or signature) is returned to the application
- The private key material is never transmitted over the network
The following diagram illustrates the HSM protected key flow:

Figure 1: AltaStata + IBM CEX Key Flow — The private key never leaves the HSM. Encryption and verification use the public key locally; decryption and signing are performed inside the HSM via GREP11.
Key Blob: A wrapped Key Blob, Not a Key
AltaStata stores an opaque key blob alongside the user configuration. This blob can only be decrypted inside a given HSM domain with the matching master key, but it contains no extractable key material — even if an attacker obtains the blob, they cannot reconstruct the private key without access to the specific CEX instance or domain. The GREP11 connection (endpoint, instance ID, authentication) is configured separately, and TLS secures all communication between the application and the HSM.
Security Comparison: Local Keys vs. HPCS
|
Aspect
|
Local Private Key
|
CEX-Secure Key
|
|
Key storage
|
PEM file on disk
|
Wrapped key blob outside HSM Protected by FIPS 140-2 Level 4 HSM
|
|
Key extraction risk
|
Possible if host and password compromised
|
Not possible — key never leaves HSM
|
|
Cryptographic operations
|
In application memory
|
Inside hardware boundary of HSM
|
|
Certification
|
Depends on deployment
|
FIPS 140-2 Level 4
|
|
Admin access risk
|
Admin can copy key file
|
Admin cannot access key material
|
|
Compliance
|
Manual audit required
|
Built-in tamper-evident logging
|
In the examples in this article, we use RSA key pairs for CEX integration. AltaStata and IBM also support post-quantum cryptography (PQC) algorithms — including Kyber for encryption and Dilithium for digital signatures. This is critical for sovereign data with long-term sensitivity: nation-states may collect encrypted data today to decrypt with quantum computers later (the "harvest now, decrypt later" threat).
IBM CEX HSM are available as part of the the IBM Crypto Service (HPCS) in multiple IBM Cloud regions, enabling organizations to choose key locations that satisfy data residency requirements — for example, eu-de (Frankfurt) for German data sovereignty or eu-gb (London) for UK compliance.
Why AltaStata + IBM Confidential Computing Is End-to-End
AltaStata encrypts data before it leaves the data owner's machine and keeps it encrypted in storage and in transit. The critical question is: where does decryption happen?
With AltaStata, decryption occurs only at the final endpoint — the application that actually processes the data. When that application runs inside an IBM Confidential Computing Container, the decrypted data exists only in memory protected by IBM Secure Execution — inaccessible to the infrastructure operator, host OS, or administrators. There is no single point of vulnerability:
- In storage — data is encrypted by AltaStata (per-file AES-GCM-256); storage administrators see only ciphertext
- In transit — data remains encrypted; AltaStata's end-to-end encryption is independent of TLS
- In use — data is decrypted only inside the TEE (Trusted Execution Environment), where IBM Secure Execution protects the memory from the infrastructure operator
- Key operations — private keys never leave the IBM CEX HSM; even the application itself never sees the private key material
Neither technology alone provides complete protection. IBM Confidential Computing secures data in use inside the TEE. AltaStata secures data at rest and in transit across any storage backend, and controls who can access what. Together, they close the loop — creating true end-to-end security with no gaps.
Performance and Cost Advantages
A common concern with encryption is that it degrades performance. AltaStata's patented data structure turns this assumption on its head — encryption with AltaStata is actually faster and cheaper than working with unencrypted text data.
Built-in data compression is applied before encryption, typically reducing text file sizes by up to 63%. This has a cascading effect:
- Storage costs drop — storing compressed-then-encrypted data requires significantly less capacity, translating to substantial savings on cloud storage bills
- Data transfer throughput increases up to 3x — compressed files move across the network more quickly. For large text files, AltaStata outperforms even unencrypted data (Figure 2).
- Processing is faster — the combination of smaller data transfers and selective decryption means the application spends less time waiting for data

Figure 2: AltaStata downloads large encrypted files 3x faster than cloud SDK handles unencrypted ones
Selective decryption means AltaStata decrypts only the partitions of a file that are currently being processed — not the entire file. For large files, this avoids memory spikes and enables streaming-style processing without needing to load everything into memory first.
Zero duplication further reduces costs. When files are shared between organizations, the data is not copied — the recipient receives access to the same encrypted bytes, eliminating storage multiplication.
|
Benefit
|
Impact
|
|
Data compression
|
Up to 63% storage cost reduction
|
|
Faster transfers
|
Compressed data moves faster over the network
|
|
Selective decryption
|
Streaming, arbitrary access and parallel processing of encrypted data
|
|
Zero duplication
|
Shared data is not copied; one copy serves all authorized users
|
|
AI/ML native
|
Seamless integration with PyTorch, TensorFlow, LangChain, Spark — no code changes needed
|
In practice, a PyTorch DataLoader can stream through a large encrypted training dataset, and a RAG pipeline can retrieve and decrypt only the specific chunks needed for the current query. Adopting AltaStata for data sovereignty delivers a net improvement in both speed and cost compared to working with unencrypted data on traditional cloud storage.
Deployment Architecture on IBM LinuxONE
We demonstrate AltaStata with IBM Confidential Computing on IBM LinuxONE5 through two examples — both running inside IBM Confidential Computing Containers: model training using a Jupyter notebook and RAG with an AI model in production. Both examples provide end-to-end protection — from data ingestion through model training to inference — using the combination of AltaStata encryption and IBM Confidential Computing.
The architecture runs on IBM LinuxONE5 with IBM Secure Execution — the on-chip technology that encrypts memory and enforces workload isolation — and IBM Crypto Express (Hardware Security Module). On top of this hardware foundation, Red Hat OpenShift Container Platform provides the container orchestration layer, with OpenShift Data Foundation for storage and the OpenShift sandbox containers operator for confidential container execution. IBM Crypto Service (powered by IBM CEX) provides the data owners a scalable key store and reduces the threat vectors significantly as only key blobs are stored and private keys are protected by a master key only present in a given IBM CEX domain. Together, this creates a tamper-proof environment where neither the infrastructure operator nor the third-party administrator can access the workload or its data.
IBM Confidential Computing Containers provides a tailored and hardened container environment for Red Hat environments like the Red Hat OpenShift Container Platform. It enables deployment of any Open Container Initiative (OCI) image in an IBM Secure Execution protected enclave. See this product documentation for further details: IBM Confidential Computing Containers for Red Hat Ecosystem
For more details on Red Hat OpenShift Confidential Containers (CoCo) with AltaStata, see our companion blog post: End-to-end security for AI: Integrating AltaStata Storage with Red Hat OpenShift confidential containers.
Development: Secure Model Training with Jupyter Notebook
In the development scenario, a Data Scientist (Bob) trains machine learning models using data provided by a Data Owner (Alice), with an Auditor verifying the integrity of the environment.

Figure 3: Development Architecture — AltaStata with IBM Confidential Computing on IBM LinuxONE5
Production: Secure AI Inference with RAG
In the production scenario, the trained model runs as an automated service, with a machine identity (ServiceID) replacing the human data scientist.

Figure 4: Production Architecture — AltaStata with IBM Confidential Computing on IBM LinuxONE5
Key Architectural Properties
Both examples share important security properties:
|
Property
|
How It's Achieved
|
|
Data at rest
|
AltaStata per-file AES-GCM-256 encryption
|
|
Data in transit
|
TLS + AltaStata end-to-end encryption
|
|
Data in use
|
IBM Confidential Computing (Secure Execution on LinuxONE)
|
|
Key protection
|
IBM Crypto Service / HPCS (FIPS 140-2 Level 4 HSM)
|
|
Access control
|
Per-file sharing via AltaStata
|
|
Integrity
|
Immutable file versions, data verification and encrypted multi-persona contract
|
|
Attestation
|
IBM Confidential Computing attestation records
|
|
Multi-cloud or Solution provider storage
|
AltaStata supports AWS, Azure, GCP, IBM COS, MinIO, POSIX file systems and more.
|
Real-World Example: Secure RAG on IBM LinuxONE
To demonstrate the production architecture in practice, we built a Retrieval-Augmented Generation (RAG) application that runs on IBM LinuxONE with CEX-protected keys. This example shows how partner organizations can securely collaborate on AI-powered question answering — with end-to-end encryption protecting every document, chunk, and embedding.
Cross-Organization RAG Vector DB
The legal firm uses an IBM Confidential Computing Container on LinuxONE — automating document preparation, encryption, and sharing with the insurance company. The downstream insurance company's RAG embedding application — also running in an IBM Confidential Computing Container — receives event notifications and processes the shared documents to build the RAG Vector DB.
Upstream (Legal firm — IBM LinuxONE):
The legal firm's RAG data preparation application running in the confidential container gets documents from its data source
Via the AltaStata SDK, the application compresses and encrypts each file with its own AES-GCM-256 key
Encrypted bytes are stored in AWS backend
Via the AltaStata SDK, the application shares access to the documents with the insurance company
Downstream (Insurance company — IBM LinuxONE):
The insurance company's RAG Embedding application running in the IBM Confidential Computing Container receives an event notification about a new shared file
It downloads and decrypts the file from AWS via the AltaStata SDK
Documents are chunked and embedded into a vector database; AltaStata keeps the encrypted file chunks for inference
AI Inference (Insurance company — IBM LinuxONE):
When a user queries the RAG chatbot, the system retrieves relevant chunks from AltaStata, decrypts them, and passes them as context to the AI Model to answer the user prompts

Figure 5: Building the RAG embedding
Both organizations run on IBM LinuxONE with IBM Confidential Computing, and all data in storage (IBM Fusion) is encrypted by AltaStata — neither the storage administrator nor the infrastructure operator can read the documents. The private keys never leave the IBM CEX HSM on either side.
From a sovereignty perspective, the legal firm retains complete control: it can see exactly which files the insurance company has access to, monitor when each file is accessed, and revoke access to any individual file at any time — even after sharing.
The RAG application is packaged as a container image optimized for IBM’s s390x architecture available on IBM Z or IBM LinuxONE, built on IBM's PyTorch base image with zDNN acceleration. It supports multiple LLM backends — a local model (such as SmolLM2 or TinyLlama via Transformers) keeps all inference inside the IBM Confidential Computing Container.
Data Clean Room: Collaborative AI Without Sharing Data
The same architecture enables a powerful pattern for multi-party collaboration: a data clean room where multiple organizations contribute data to a shared AI application — such as model training — without ever exposing their raw data to each other.
Consider a hospital, a pharmaceutical company, and a research university training a medical AI model on their combined datasets. Each holds sensitive data they cannot share directly — due to GDPR, contractual obligations, or competitive concerns.
With AltaStata and IBM Confidential Computing:
- Each partner encrypts their data with AltaStata and shares access only with the application's ServiceID — not with the other partners
- The AI application runs inside an IBM Confidential Computing Container on LinuxONE, accessing data from all partners through the AltaStata SDK
- No partner can see another partner's raw data — AltaStata's per-file access control ensures each organization's files are accessible only to the application
- Each partner monitors access to their files and can revoke access at any time
- Each partner can independently verify — through IBM Confidential Computing attestation records — that the container is running the agreed-upon code
- The trained model is stored encrypted in AltaStata and shared back with the contributing partners

Figure 6: AI Model Training in the Data Clean Room
The result is application-level collaboration without data-level sharing. Each partner maintains full sovereignty and can withdraw their data at any point. This pattern applies to joint fraud detection across banks, supply chain optimization across manufacturers, or collaborative drug discovery — all without any partner surrendering control over their data.
End-to-End Security: How the Pieces Fit Together
The following table summarizes how each layer contributes to the overall security posture:
|
Security Layer
|
Technology
|
What It Protects
|
|
Data at rest
|
AltaStata per-file AES-GCM-256
|
Files in cloud storage (any provider)
|
|
Data in transit
|
AltaStata end-to-end encryption + TLS
|
Network communications
|
|
Data in use
|
IBM Confidential Computing (Secure Execution on LinuxONE)
|
Memory and processor state during processing
|
|
Key protection
|
IBM Crypto Express HSM (FIPS 140-2 Level 4)
|
Private keys and key operations
|
|
Access control
|
AltaStata per-file sharing IBM CEX domain
|
Who can read which files Who can perform cryptographic operations Who can access key material
|
|
Data integrity
|
AltaStata immutable versions + AES-GCM authentication
|
Tamper detection and prevention
|
|
Compliance
|
AltaStata event logging + IBM Confidential Computing attestation
|
GDPR, AI Act, NIST RMF audit trails
|
|
Storage sovereignty
|
AltaStata multicloud + HPCS regional endpoints
|
Data residency per jurisdiction
|
Together, these layers ensure that:
- No single party — not the cloud provider, not the infrastructure operator, not even the system administrator — can access the data without authorization
- Data integrity is cryptographically guaranteed through immutable versions and AES-GCM authentication tags
- Compliance is automatic — IBM Confidential Computing attestation records and AltaStata event logging provide the auditability that the EU AI Act, GDPR, and NIST RMF demand
- Sovereignty is maintained, with data encrypted before it leaves the organization and keys protected by jurisdiction-appropriate HSMs
Conclusion
Data sovereignty is no longer optional — it is a regulatory requirement and a business necessity for organizations operating in Europe and beyond. The combination of AltaStata's patented encryption and IBM Confidential Computing on IBM LinuxONE delivers a comprehensive solution that addresses every layer of the data security stack.
Unlike traditional approaches that force a choice between security, ease-of-use and performance, AltaStata's architecture — with per-file encryption, selective decryption, and data compression — actually improves performance while providing stronger security. The IBM CEX integration ensures that cryptographic keys never leave the hardware boundary of a FIPS 140-2 Level 4 certified HSM, providing the highest level of key protection available. The IBM Confidential Containers offer an ease-of-use integration stack allowing confidential computing protected workloads to participate seamlessly as part of the container experience and taking advantage of the built-in AI and crypto accelerators on IBM LinuxONE.
For AI workloads, this means organizations can:
- Train models on sensitive data without exposing it to infrastructure providers
- Deploy inference applications with hardware-attested integrity
- Share data across organizational boundaries with per-file access control
- Comply with GDPR, the EU AI Act, and national sovereignty requirements — automatically
Ready to secure your AI data pipeline with data sovereignty? Get started with AltaStata on IBM LinuxONE today.
Serge Vilvovsky, AltaStata Founder & CEO
Nicolas Mading, IBM
Kevin Cattell, Red Hat
Related resources: