Encryption at Rest vs. In Transit vs. In Use: A Buyer’s Glossary for Private AI Deployments

Encryption at rest protects data stored on a disk, database, or backup; encryption in transit protects data moving across a network; encryption in use protects data while it is being processed by a CPU or GPU, including the moment an AI model reads a prompt or a document chunk to generate an answer [dualitytech.com][filecloud.com]. Buyers evaluating private AI deployments need all three, because an AI system that only encrypts storage and network traffic still exposes plaintext data the instant it enters memory for inference or retrieval [fidelissecurity.com]. This is the gap most vendor pitches gloss over, and the gap that matters most once an AI agent starts reading confidential documents.

TL;DR

• Encryption at rest secures stored data using standards like AES-256; encryption in transit secures data moving over a network, typically via TLS [back4app.com].
• Encryption in use is the newest and hardest category, addressed by confidential computing and trusted execution environments, not by traditional disk or network encryption [fidelissecurity.com].
• Homomorphic encryption can process data without decrypting it, but the performance overhead currently limits it to narrow, non-real-time use cases.
• AI knowledge bases and agentic workflows are uniquely exposed at the “in use” layer, because retrieval and generation both require plaintext access to sensitive content in memory.
• A zero trust architecture treats every request as untrusted by default, which is the right operating assumption once AI agents start acting on data across systems.

About the Author: Fooyo builds and operates AI knowledge bases and agentic automation for government agencies, enterprises, and SMEs, with home base in Singapore and presence in China and Japan, deploying every solution into a client’s own private cloud rather than a shared public model. This glossary reflects the encryption questions Fooyo answers directly with procurement and security teams during deployment scoping.

What Do “At Rest,” “In Transit,” and “In Use” Actually Mean?

These three terms describe the state a piece of data is in at any given moment, and each state carries a different attack surface. Data at rest is inactive data sitting in a database, file system, or backup archive [datalocker.com]. Data in transit is data actively moving between two points, such as a browser and a server, or two microservices inside a cloud environment [dualitytech.com]. Data in use is data loaded into RAM or a processor register while an application is actively working on it, which includes the exact moment an AI model reads a document to answer a question [fidelissecurity.com].

The distinction matters because each state requires a different defense. Full-disk or database encryption defends data at rest. Transport Layer Security defends data in transit. Neither defends data in use, which is why a system can pass every storage and network audit and still leak plaintext to a compromised process or a malicious cloud administrator [akeyless.io].

How Does Encryption at Rest Actually Work?

Encryption at rest converts stored data into ciphertext using a key, so that anyone who gains access to the physical storage medium or a stolen backup sees only unreadable output [censinet.com]. The dominant data encryption standard for this layer is AES-256, applied at the disk, database, or file level. Encrypted data storage of this kind defends against a specific, well-documented risk: physical media theft and unauthorized access to storage systems, whether that is a stolen laptop, a decommissioned hard drive, or a misconfigured cloud storage bucket.

Key management is the part buyers underweight. Encryption at rest is only as strong as the process controlling who can request the decryption key, when, and under what approval. A vendor claiming “AES-256 encryption” without describing key rotation, key custody, and access logging is describing half a control.

How Does Encryption in Transit Protect Data Moving Across a Network?

Encryption in transit protects data as it moves between two endpoints, most commonly using TLS to wrap the connection between a client and a server [splunk.com]. This defends against man-in-the-middle attacks, packet sniffing, and session hijacking, all of which target data while it is traveling across a network rather than while it sits in storage [akeyless.io]. For an AI deployment, this covers the path between a user’s browser and the application, and the internal paths between the retrieval layer, the model, and any connected enterprise system such as a CRM or CMS.

End-to-end encryption is a stricter version of this idea: data is encrypted at the source and only decrypted at the final destination, so no intermediate hop, including the vendor’s own servers in some architectures, can read the plaintext in between. For enterprise AI, true end-to-end encryption is rare in practice, because the AI model itself is usually an intermediate hop that must decrypt content to generate an answer.

Why Is Encryption in Use the Hardest Problem for AI Deployments?

Building on the transit layer above, the harder question is what happens the moment that data reaches the AI model. Encryption in use protects data while it is actively being processed, and it is the newest and least mature of the three categories, both technically and regulatorily [dualitytech.com]. NIST Cybersecurity Framework 2.0 formalizes this gap explicitly: PR.DS-1 covers data at rest, PR.DS-2 covers data in transit, and PR.DS-10 covers data in use as a distinct control category. ISO 27001:2022 Annex A 8.24 similarly mandates cryptographic policy across all three states, not just the first two.

This is the layer that matters most for a RAG-based AI knowledge base, because answering a question requires the model to hold retrieved document text in plaintext in memory during inference. Documented risks at this layer include memory scraping, insider access by cloud or system administrators, and plaintext exposure during active processing. A storage system can be fully encrypted and a network fully wrapped in TLS, and an AI system built on top of it can still expose confidential contract terms or patient records the instant a query pulls them into memory for the model to read.

Two technical approaches currently address this gap, and buyers should understand the trade-off between them:

• Confidential computing, implemented through a trusted execution environment, isolates data in an encrypted, hardware-protected enclave during processing, offering near-native performance. Earlier process-based enclave designs often required application refactoring, but modern VM-based trusted execution environments can isolate an entire virtual machine, allowing existing applications and containers to be deployed with little to no code change. Scalability and workload fit still vary by implementation.
• Homomorphic encryption allows computation directly on encrypted data without ever decrypting it, which is architecturally elegant but currently carries enough performance overhead to limit its viability for real-time enterprise workloads.

Neither is a drop-in fix. A trusted execution environment is closer to production-ready for enterprise inference workloads today; homomorphic encryption remains better suited to narrow, latency-tolerant computations.

What Does Zero Trust Architecture Add on Top of Encryption?

A related but distinct question is what protects data once it’s decrypted and being legitimately used, which encryption alone cannot answer. A zero trust architecture assumes no user, device, or internal service is automatically trusted, and instead verifies every request against identity, device posture, and policy before granting access, regardless of whether the requester is inside or outside the network perimeter. Encryption protects the data itself; zero trust governs who and what is allowed to touch it in the first place.

For an AI agent that can read across a company’s document store and trigger downstream actions, this combination is not optional. The agent needs the same request-level scrutiny a human employee would face, plus a human-in-the-loop review gate before it acts on what it retrieves. This is why Fooyo builds source-cited, grounded responses and review checkpoints directly into every automated workflow, rather than treating the AI agent as an implicitly trusted internal service.

What Do Regulators Actually Require?

Stepping back from the architecture, the compliance question is simpler than it looks. GDPR Article 32 and HIPAA both mandate encryption for data at rest and in transit, with regulatory expectations now extending toward protections for data in use as well. Singapore’s PDPA requires “reasonable security arrangements,” which in practice means encrypting data at rest and in transit as a baseline, with in-use protection increasingly expected for sensitive categories of data. For any organization deploying AI across borders, such as between Singapore and Japan, the safest posture is to design for the strictest applicable requirement across all three states rather than the minimum in any single jurisdiction.

How Should Buyers Evaluate an AI Vendor’s Encryption Claims?

The table below is a working checklist for procurement conversations.

Private deployment is the practical answer most enterprises land on today: run the AI system inside the client’s own private cloud, so data never leaves the client’s environment and never trains a shared model, and pair that with strict TLS and access controls rather than waiting for in-use encryption tooling to mature further. This is the deployment model Fooyo uses across its AI Knowledge Base and agentic automation products, which is a pragmatic middle ground while confidential computing tooling continues to mature industry-wide.

How Does This Compare to Other Enterprise AI Platforms in Singapore?

Several platforms offer private or hybrid deployment models for enterprise AI workloads, with varying strengths in document processing, code generation, and field service management. Each takes a different approach to integration and agent autonomy, from no-code builders and vendor-managed knowledge bases to cloud-native infrastructure dependencies and mobile-first job tracking.

Fooyo’s own position is a private-cloud deployment model built specifically around grounded, source-cited retrieval with human-in-the-loop review gates, delivered in as little as six weeks rather than the six-month build cycle typical of enterprise AI projects, with integration into existing CRM, POS, CMS, and messaging systems rather than a rip-and-replace approach.

Frequently Asked Questions

Is encryption at rest enough for an AI knowledge base? No. It protects stored documents but not the plaintext content an AI model reads into memory during retrieval and generation.

What is the difference between encryption in transit and end-to-end encryption? Encryption in transit protects data between two points on a network path; end-to-end encryption ensures only the sender and final recipient can decrypt it, with no intermediate party, including servers along the way, able to read the plaintext.

Is homomorphic encryption ready for production AI use today? Generally not for real-time enterprise workloads; the performance overhead currently makes it better suited to narrow, latency-tolerant computations rather than live inference.

What is a trusted execution environment used for? It creates a hardware-isolated enclave where data can be decrypted and processed with hardware-level protection against outside access, forming the basis of confidential computing.

Does private cloud deployment replace the need for in-use encryption? No, but it narrows the exposure significantly by ensuring data never leaves the client’s own environment or trains a shared model, which is why it’s a common interim posture.

What does zero trust architecture change for AI agents specifically? It requires every request an agent makes, whether reading a document or triggering an action, to be verified against identity and policy, rather than assuming the agent is implicitly trusted because it’s internal.

Do Singapore’s PDPA requirements cover data in use? PDPA requires “reasonable security arrangements” that practically necessitate encryption at rest and in transit, with in-use protection an emerging rather than explicit requirement.

About Fooyo

Fooyo is a Singapore-headquartered company that builds data platforms and AI agents, including its AI Knowledge Base, Smart Tourism products, and workflow automation, and deploys every one of them into a client’s own private cloud environment. It operates from Singapore, with a development office in Chengdu and a business partnerships office in Tokyo, delivering across Asia. Fooyo is trusted by government agencies, enterprises, and SMEs across Asia, and takes production-grade AI from prototype to live deployment in as little as six weeks by acting as a hands-on operating partner rather than a consultancy that only delivers reports.

If your organization is weighing encryption architecture for an AI knowledge base or agentic workflow deployment, get in touch with Fooyo to scope a private, secure deployment built around your existing systems.