Encryption of AI Data at Rest, in Transit and in Use

Why This Topic Matters

Artificial intelligence systems concentrate enormous amounts of valuable and often highly sensitive data in one place. Training datasets may contain personal data, health records, financial transactions, or proprietary business information. Model weights and parameters represent millions of dollars of intellectual property and compute investment. Prompts, embeddings, inference logs, and retrieval-augmented generation (RAG) indexes can expose confidential business context, customer conversations, or regulated information. Because AI pipelines move data constantly between storage, compute clusters, GPUs, APIs, and third-party services, the attack surface is far larger than that of a traditional application.

Encryption is the primary confidentiality control that protects this data wherever it lives and moves. For the ISACA Advanced in AI Security Management (AAISM) exam, encryption is not just a technical detail; it is a governance and risk management concern. Regulators (GDPR, HIPAA, PCI DSS, the EU AI Act, and sector-specific rules) expect appropriate technical measures, and frameworks such as ISO/IEC 27001, ISO/IEC 42001, and the NIST AI Risk Management Framework reference cryptographic protection of data and models. A security manager must be able to decide what to encrypt, where, how strongly, who controls the keys, and how to verify that the controls work.

What It Is: The Three States of Data

Security professionals describe data as existing in three states, and each state requires a different protective approach:

1. Data at rest is data stored on persistent media: databases, data lakes, object storage buckets, file systems, backups, snapshots, vector databases, model registries, and checkpoint files. For AI, this includes raw and curated training data, labelled datasets, feature stores, model weights, fine-tuning artifacts, embeddings, and logs of prompts and completions.

2. Data in transit (also called data in motion) is data moving across a network: between a data lake and a training cluster, between distributed GPU nodes, between a client application and an inference API, between microservices in an ML pipeline, and between an enterprise and a cloud AI provider or model-as-a-service vendor.

3. Data in use is data actively being processed in memory, in CPU or GPU registers, and in caches. During model training and inference, plaintext data and model parameters are loaded into memory where traditional encryption no longer protects them. This has historically been the weakest link and is the area where AI-specific innovation is most active.

How It Works: Encryption at Rest

Encryption at rest uses symmetric algorithms, most commonly AES-256, to render stored data unreadable without the key. Common implementation layers include:

- Full disk or volume encryption (for example, LUKS, BitLocker, cloud-provider managed disk encryption) protects against physical theft or decommissioned media but offers little protection against an attacker with operating-system-level access.
- File and object-level encryption protects individual datasets, model files, and checkpoints in object storage such as S3, Azure Blob, or GCS, typically with server-side encryption (SSE) or client-side encryption (CSE).
- Transparent Data Encryption (TDE) in databases and column or field-level encryption for specific sensitive attributes within training tables.
- Application-layer encryption where the AI application encrypts data before it is handed to any storage service, giving the strongest control because the cloud provider never sees plaintext.

Most enterprise and cloud implementations use envelope encryption: a unique data encryption key (DEK) encrypts the data, and the DEK itself is encrypted by a key encryption key (KEK) held in a Key Management Service (KMS) or Hardware Security Module (HSM). This allows efficient key rotation and centralised control. Options such as customer-managed keys (CMK), Bring Your Own Key (BYOK), and Hold Your Own Key (HYOK) define how much control the organisation retains over keys in cloud AI platforms. AI-specific at-rest targets that are frequently forgotten include model registries, experiment-tracking metadata, vector database indexes (embeddings can be inverted to recover approximate source text), GPU node local scratch disks, and notebook environments where data scientists cache datasets.

How It Works: Encryption in Transit

Data in transit is protected primarily by Transport Layer Security (TLS), ideally version 1.2 or higher with 1.3 preferred, deprecating SSL and early TLS. Key practices include:

- TLS for all inference and training APIs, including REST and gRPC endpoints used by model-serving frameworks.
- Mutual TLS (mTLS) for service-to-service communication inside the ML pipeline so that both client and server authenticate, which is especially important in containerised and Kubernetes-based MLOps platforms and service meshes.
- VPNs, IPsec, or private connectivity (private endpoints, dedicated interconnects) for traffic between on-premises data sources and cloud AI services.
- Encryption of inter-node traffic in distributed training, where gradients, activations, and parameter updates are exchanged at very high speed across many GPUs; high-performance interconnects may need specific configuration to enable encryption without unacceptable latency.
- Certificate lifecycle management, strong cipher suites, perfect forward secrecy, and disabling weak protocols.
- Secure handling of API keys and tokens used to call third-party LLM providers; these are credentials in transit and at rest and must not be embedded in prompts or code.

In federated learning, in-transit protection is critical because model updates travel from many edge participants to an aggregator; secure aggregation protocols combine encryption with cryptographic techniques so that the server cannot see individual updates.

How It Works: Encryption in Use

Protecting data while it is being computed on is the hardest problem, because a processor must ultimately operate on meaningful values. Three families of techniques are relevant:

1. Confidential computing and Trusted Execution Environments (TEEs). Hardware-isolated enclaves (Intel SGX, Intel TDX, AMD SEV-SNP, Arm CCA) encrypt memory contents and isolate the workload from the host operating system, hypervisor, and cloud administrator. Confidential GPUs (such as NVIDIA H100 confidential computing mode) extend this protection to AI accelerators so that model weights and inference data remain encrypted in GPU memory. Remote attestation lets a data owner cryptographically verify that the code and environment are genuine before releasing keys or data into the enclave. This is currently the most practical approach for production AI workloads that must process sensitive data in a shared or third-party environment.

2. Homomorphic encryption (HE) allows computations to be performed directly on ciphertext, producing an encrypted result that decrypts to the correct answer. Fully homomorphic encryption is mathematically powerful but computationally expensive, often orders of magnitude slower, so it is currently used for narrow inference tasks or partial pipeline steps rather than full model training.

3. Secure multi-party computation (SMPC) splits data or computation among multiple parties so that no single party ever sees complete plaintext, enabling joint model training across organisations that cannot share raw data. Related privacy-enhancing technologies such as differential privacy are not encryption but are frequently paired with these methods and may appear as distractors in exam questions.

Key Management: The Control Behind the Control

Encryption is only as strong as its key management. Examiners consistently test this point. Essential principles include: generating keys in a KMS or FIPS 140-2/140-3 validated HSM; enforcing separation of duties so that those who administer data or models cannot also access keys; least privilege and role-based access to keys; defined rotation schedules and immediate rotation after suspected compromise; secure backup and escrow to avoid data loss; audit logging of all key usage; and documented key lifecycle procedures from generation through destruction. Crypto-agility, the ability to swap algorithms and key lengths quickly, is increasingly important as organisations prepare for post-quantum cryptography (PQC); long-lived training data and model IP encrypted today may be targeted by harvest-now-decrypt-later attacks.

Governance and Management Considerations

From the AAISM management perspective, encryption decisions should flow from data classification and risk assessment, not from technology enthusiasm. A mature program will:

- Classify AI assets (datasets, models, prompts, outputs) and map required encryption strength and key control to each classification level.
- Document an encryption standard and policy covering approved algorithms, minimum key lengths, protocol versions, and prohibited legacy methods.
- Address third-party and cloud AI providers through contracts, shared responsibility models, SOC 2 or ISO 27001 reports, and verification of CMK/BYOK support and no-training-on-customer-data clauses.
- Balance performance and cost against risk; for example, confidential GPUs or HE may be justified only for the most sensitive workloads.
- Integrate encryption with identity and access management, logging, and monitoring, because encryption does not stop an authorised but malicious user, nor does it prevent model inversion, membership inference, or prompt injection attacks on a running model.
- Verify effectiveness through audits, configuration scanning, penetration testing, and evidence of key rotation.

Limitations to Remember

Encryption protects confidentiality, and with authenticated modes also integrity, but it does not by itself provide availability, does not prevent misuse by legitimate key holders, does not defend against attacks that query the model through its intended interface, and can impose latency that affects real-time inference. Misconfiguration, such as publicly readable storage buckets or TLS with certificate validation disabled, is a far more common failure than broken cryptography.

Exam Tips: Answering Questions on Encryption of AI Data at Rest, in Transit and in Use

1. Identify the data state first. Read the scenario and determine whether the data is stored, moving, or being processed. Storage, backups, model files, and vector databases point to at-rest controls (AES-256, TDE, object encryption). APIs, network transfers, and provider connections point to in-transit controls (TLS 1.2+, mTLS, VPN). Memory, training, inference, GPU processing, and multi-party collaboration point to in-use controls (TEEs, confidential computing, homomorphic encryption, SMPC).

2. When a question asks what is MOST important or the GREATEST risk, think key management. Weak key management, shared keys, lack of rotation, or the cloud provider holding the only copy of the keys is frequently the correct concern. Strong algorithms with poor key control provide false assurance.

3. Prefer governance-first answers for a manager role. ISACA exams test the security manager, not the engineer. If a question asks what should be done FIRST, the answer is usually to perform a risk assessment, classify the data, or define policy rather than to deploy a specific product. Technical selection follows classification.

4. Recognise the confidential computing signal. If the scenario involves processing sensitive data on infrastructure the organisation does not fully control, such as a public cloud or a third-party GPU provider, and the concern is exposure during processing, the best answer is typically a trusted execution environment or confidential computing with attestation.

5. Know the trade-offs of homomorphic encryption. Expect questions highlighting that HE preserves confidentiality during computation but has significant performance overhead, making it unsuitable today for full-scale model training. Do not choose HE for a low-latency, high-volume inference scenario unless the question explicitly prioritises confidentiality over performance.

6. Watch for distractors that are not encryption. Differential privacy, data masking, tokenisation, anonymisation, and access controls are complementary controls. If the question asks specifically about cryptographic protection of a state of data, eliminate these. Conversely, if the question asks how to prevent a model from leaking training data through its outputs, encryption is usually the wrong answer and privacy-preserving training techniques are correct.

7. Remember the AI-specific assets. Questions may test whether you recognise model weights, embeddings, prompts, logs, and checkpoints as sensitive data that require protection just like training data. Embeddings in vector databases are a favourite because candidates assume they are harmless.

8. Apply shared responsibility logic for cloud AI. The provider typically encrypts infrastructure by default, but the customer remains responsible for classification, key ownership decisions (CMK/BYOK), configuration, and verifying provider claims. An answer that fully delegates encryption responsibility to the vendor is usually wrong.

9. Encryption does not prevent authorised misuse or integrity attacks on models. If a scenario describes an insider with legitimate access, or model poisoning and tampering, look for answers involving access control, integrity verification, signing of model artifacts, logging, and monitoring rather than more encryption.

10. Use elimination on protocol and algorithm questions. Any answer mentioning SSL, TLS 1.0 or 1.1, DES, 3DES, MD5, or RC4 is almost certainly wrong. Look for AES-256, TLS 1.3, and FIPS-validated modules. Also recognise crypto-agility and post-quantum readiness as forward-looking best practices for long-lived AI assets.

11. Verification matters. When asked how a manager would gain assurance that encryption is effective, correct answers involve independent audit, configuration review, evidence of key rotation, attestation reports, and testing, not merely a policy statement or a vendor assertion.

Quick Revision Summary

- At rest: AES-256, TDE, object and file encryption, envelope encryption, KMS/HSM, CMK/BYOK; cover datasets, models, embeddings, backups, logs.
- In transit: TLS 1.2+/1.3, mTLS, VPN/private links, certificate management, secure inter-node and API traffic, secure aggregation in federated learning.
- In use: confidential computing and TEEs with attestation, confidential GPUs, homomorphic encryption, SMPC; balance strong protection against performance cost.
- Everywhere: classification-driven, policy-based, risk-assessed, key management with separation of duties and rotation, verified through audit, and integrated with access control and monitoring.

Master the ability to map a scenario to the correct data state, choose the control appropriate to the risk and the manager's role, and always ask who controls the keys, and you will handle AAISM questions on this topic with confidence.