"Your data is encrypted" is one of the least informative sentences in enterprise software marketing, not because it is false — it is usually technically true, in some narrow sense, of nearly every vendor who says it — but because the sentence is compatible with an enormous range of actual security postures, from genuinely rigorous, defense-in-depth architecture to something close to a checkbox exercise that would not meaningfully slow down a determined attacker. Encryption is a necessary control, not by itself a sufficient description of a system's security architecture, and understanding what actually happens to data as it moves through an AI workflow system requires unpacking the claim into its real component parts, each of which can independently be done well or done poorly.
1. Encryption in Transit
Data moving between a user's device, the workflow system's servers, and any AI processing layer should be protected by TLS — specifically, current guidance points to TLS 1.3, formalized in RFC 8446, which removes several cryptographically weaker cipher options and handshake modes that earlier TLS versions permitted for backward compatibility, and that a sophisticated attacker could potentially exploit through a downgrade attack that tricks two endpoints into negotiating a weaker, breakable connection instead of the strongest one both actually support. This layer protects data as it travels across a network, preventing an attacker positioned between the endpoints — on a shared network, at an internet exchange point, anywhere along the physical or logical path — from reading or tampering with it in transit. It says nothing, by itself, about what happens to the data once it arrives at its destination and the TLS connection terminates.
A system that correctly implements TLS 1.3 for every network hop in its architecture — not merely the user-facing connection a customer's browser sees, but every internal service-to-service call as data moves through processing, masking, and storage layers inside the vendor's own infrastructure — has closed one meaningful and often-overlooked attack surface. A system that terminates TLS at a public-facing load balancer and then passes data unencrypted between internal services, on the theory that the internal network is "trusted" and therefore does not need the same protection, has left a real and exploitable gap: an attacker who gains any foothold inside that internal network, through an unrelated vulnerability in an adjacent service, can read data traveling between components that were never designed to be exposed to an internal adversary because nobody expected one.
2. Encryption at Rest
Data stored on disk — in a database, in a file store, in a backup archive — should be encrypted using an approved algorithm, typically AES-256 under the Advanced Encryption Standard formalized in FIPS 197, implemented through a cryptographic module that has itself been independently validated against FIPS 140-3. This distinction between using AES in the abstract and using a FIPS-140-3-validated implementation of AES matters considerably more than it might initially appear to someone outside the field: a cryptographic algorithm can be correctly specified on paper, mathematically sound, while a specific software implementation of it contains subtle bugs — a flawed random-number generator, an implementation that leaks timing information an attacker can measure — that undermine its actual real-world security guarantee despite the underlying algorithm being perfectly fine. FIPS 140-3 validation is the formal, independent process by which an implementation's correctness is actually verified by a third party, rather than merely assumed because the vendor says it uses "AES-256," a phrase that, on its own, guarantees considerably less than most people assume.
Encryption at rest protects against a specific, genuinely important threat: an attacker who gains physical or low-level access to storage media — a stolen hard drive, an improperly decommissioned server whose disks were not properly wiped, unauthorized low-level access to a cloud provider's underlying storage layer — without also independently obtaining the encryption keys. It does not, by itself, protect against an attacker who compromises the application layer and accesses data through the normal, authorized query path, because that path decrypts the data as a matter of ordinary, legitimate operation — encryption at rest is one layer of a defense-in-depth posture, addressing one specific threat model, not a complete security architecture that renders every other control unnecessary.
3. Key Management as the Load-Bearing Component
Encryption is only as strong as the protection around the keys that unlock it, and this is, in practice, where a genuinely rigorous architecture distinguishes itself from a superficial one that merely satisfies the letter of "we encrypt your data." NIST SP 800-57's recommendations for key management — covering key generation, rotation, storage, and eventual destruction — describe the full lifecycle a key should pass through, and each stage is a place where a poorly built system can quietly undermine an otherwise strong encryption implementation. Keys should be generated using a cryptographically secure random process, not a predictable or insufficiently random one; rotated on a defined schedule, so that a compromised key has a bounded, limited window of usefulness to an attacker rather than remaining valid indefinitely; and stored separately from the data they protect, ideally in a dedicated hardware security module — a physical device purpose-built to generate and guard cryptographic keys, resistant to extraction even by someone with direct physical access to it — or a managed key-management service, rather than sitting alongside the encrypted data itself in the same database or file system.
The specific architectural question worth asking any vendor is not "do you encrypt data" — nearly every vendor will answer yes — but "who can access the keys, under what conditions, and is that access itself logged and independently auditable." A system where a single database administrator credential can both access encrypted data through the ordinary application path and separately retrieve the keys needed to decrypt a raw backup has not meaningfully separated the two roles, regardless of what encryption algorithm sits underneath the architecture on paper — the practical security boundary that actually matters to an attacker is determined by key access control, not by algorithm choice, which is why security audits focus disproportionately on this specific question relative to how little attention it gets in marketing material.
4. Envelope Encryption and Why Key Hierarchies Matter
Mature systems rarely encrypt data with a single, flat key used identically across the entire dataset — instead, they typically implement envelope encryption, a layered key hierarchy in which individual pieces of data are each encrypted with their own unique data key, and those data keys are themselves encrypted by a smaller number of master keys held in a hardware security module or managed key service, one level up. This layered approach has a specific practical benefit that a flat, single-key architecture lacks: it allows a compromised data key — one associated with a single record or a single customer's data — to be rotated and reissued without requiring the entire dataset to be re-encrypted from scratch, a process that at scale can be prohibitively slow and operationally disruptive to run on short notice during an active incident.
Envelope encryption also supports a cleaner audit story: because the master key never directly touches the bulk of the actual data, access to the master key can be logged and restricted far more tightly than access to the (necessarily more numerous, more frequently used) data keys, giving an organization a genuinely smaller, more defensible set of credentials whose compromise would constitute a catastrophic, dataset-wide failure, as distinct from the much larger and more routine set of credentials whose compromise, while still serious, is contained to a narrower blast radius.
5. Encryption in Use: The Gap Most Architectures Still Leave Open
Encryption in transit and at rest are now close to table stakes for any serious enterprise vendor. A third, considerably less mature category — encryption in use, sometimes discussed under the broader banner of confidential computing — addresses a gap the first two categories leave entirely open: while data is actively being processed in memory, decrypted so a CPU can actually operate on it, it has traditionally been vulnerable to a sufficiently privileged attacker (including, in some threat models, the cloud provider's own infrastructure operators) who can inspect a running process's memory directly. Trusted Execution Environments — hardware-isolated regions of a processor that keep data encrypted and shielded even from the host operating system and hypervisor while it is being actively computed on — are the emerging technical answer to this gap, and organizations with the most stringent threat models are increasingly asking vendors specifically whether any confidential-computing protection exists for the moment data is actually in active use, rather than only for the moments it is at rest or in transit.
This remains a genuinely less mature and less universally deployed layer than the first two, and most organizations' actual risk profile does not yet require it — but it is worth understanding as a real, distinct gap in the "encrypted" claim, one that a security-sophisticated evaluator should at least ask about explicitly rather than assume is covered by a vendor's general encryption assurances.
6. Data Residency and the Question of Where, Physically
Beyond encryption itself, the physical and jurisdictional location where data is stored and processed carries its own independent significance, separate from how well it is encrypted — a masked secure-cloud deployment processing data in a specific geographic region determines which country's legal system governs government access requests to that data, which regional data-residency regulations apply, and which disaster-recovery and business-continuity commitments are realistic given the physical distance and jurisdiction involved. This is a genuinely separate axis from encryption strength: a well-encrypted dataset stored in a jurisdiction with weak legal protections against compelled government access, or one geographically distant from the organization's own operations in a way that complicates incident response and legal process, carries a real category of risk that stronger encryption alone does not resolve, no matter how good the underlying cryptography is.
Organizations with specific data-residency requirements — driven by regulation, contract, or internal policy — should treat this as a genuinely distinct question from encryption strength when evaluating a deployment architecture, and should expect and demand a specific, independently verifiable answer about physical processing location, down to the actual data-center region, rather than accepting a general assurance that "your data is secure" as though the two questions were the same one.
7. What a Fully Local Deployment Changes About This Picture
A fully on-premises or edge deployment changes the encryption-and-storage conversation in a specific and important way: the organization itself becomes directly responsible for implementing every layer described above correctly — TLS configuration, encryption at rest, key hierarchy and hardware security modules, and increasingly confidential computing — rather than relying on a specialized vendor's infrastructure team to have already done so. This is a genuine tradeoff, not an automatic security improvement simply by virtue of being local. An organization with a mature internal security function, capable of implementing FIPS-140-3-validated encryption, rigorous envelope key management, and properly configured TLS across its own infrastructure, gains real, meaningful additional control by keeping everything local. An organization without that internal capability may, in practice, implement a fully local deployment considerably less rigorously than a specialized vendor would have implemented the equivalent cloud infrastructure, simply because building and maintaining this entire stack correctly is a genuine, ongoing engineering discipline that takes sustained investment and specialized expertise to do well, year after year, not a one-time setup task.
This is why the deployment-model decision, examined throughout this series primarily through a regulatory and data-sensitivity lens, also has a genuine technical-capability dimension that deserves its own honest assessment: the right choice depends not only on what the data requires as a matter of regulation or risk, but on which party — the organization itself or the vendor — is actually better positioned to implement the encryption and key-management architecture correctly for a given workload, given each party's real, current capability rather than an aspirational one.
8. Conclusion
"Encrypted" describes a property, not a complete architecture, and the actual security of an AI workflow system's data storage depends on a stack of specific, independently verifiable decisions — TLS 1.3 enforced at every network hop including internal ones, FIPS-140-3-validated encryption at rest, an envelope key hierarchy with rigorously separated and rotated keys, an honest answer about encryption in use, and a deliberate, verifiable answer to where data physically and jurisdictionally resides. Organizations evaluating a vendor's security claims should ask about each layer specifically and expect a specific answer for each, because a system that gets most of these right and stays vague about even one has a real, exploitable gap, regardless of how confidently the marketing material describes the system as "fully encrypted."