A large law firm's security team was reviewing proposals from three legal AI vendors when one vendor's RFP response listed "AES encryption" without specifying the key length, the key management approach, or whether the encryption applied to data in transit or at rest. When pressed, the vendor confirmed it used AES-128, not AES-256—a difference that matters for national security-level data protection but is functionally equivalent for most legal data today. The vendor had answered a different question than the one being asked, and the vague terminology made the distinction invisible.
Encryption evaluation for legal AI vendors is an area where technical specificity is required. Terms like "bank-level encryption" and "enterprise-grade security" appear in vendor marketing but convey no specific information. What matters is the specific algorithm, key length, key management practice, and whether encryption applies at every relevant layer of the system.
For law firms evaluating legal AI platforms—especially those handling sensitive client data in document review, research, or drafting workflows—understanding what encryption questions to ask is the difference between an informed vendor selection and a security theater exercise. This guide provides the technical framework and the specific questions.
TL;DR
- AES-256 for data at rest is the standard requirement for legal AI vendors; AES-128 is technically sound but below the standard for sensitive legal data.
- TLS 1.3 for data in transit is the current standard; TLS 1.2 is acceptable as a fallback but vendors should be on a TLS 1.3 migration roadmap.
- Key management is where most encryption evaluations miss significant risks—ask specifically about HSM use, customer-managed key options, and key rotation schedules.
- If a vendor routes queries through a third-party LLM API, ask whether that data is encrypted end-to-end or whether it passes through the third-party API in plaintext.
- Customer-managed keys (BYOK) provide the strongest assurance that vendor key compromise does not expose client data—available from Harvey AI and select enterprise vendors.
- Encryption at rest protects against storage compromise; encryption in transit protects against network interception; neither protects against authorized access by vendor employees with appropriate system access.
- RFP questions covering these standards are included in the Core Analysis section.
Background
Encryption is the technical foundation of data security for cloud-hosted legal AI tools. When client documents are uploaded to an AI platform, when queries are transmitted, when outputs are returned, and when data is stored in vendor systems—encryption is what prevents that data from being readable if intercepted or improperly accessed.
The legal profession's encryption requirements are not defined by a single standard. Model Rule 1.6's "reasonable measures" requirement is technology-neutral. State bar ethics opinions have addressed cloud storage and vendor data handling but rarely specify encryption algorithms. The practical standard is derived from the industry benchmarks that constitute "reasonable" security in the contexts where legal data is most sensitive: financial data, health information, government contracts.
AES-256 (Advanced Encryption Standard with 256-bit keys) has been the de facto standard for data at rest in enterprise cloud services since the early 2010s. It is used by major cloud providers (AWS, Azure, Google Cloud) as their default encryption, is approved by NIST, and is considered quantum-resistant under current analysis for typical legal data protection timelines.
TLS (Transport Layer Security) version 1.3, finalized by the IETF in 2018, is the current standard for encryption in transit. It provides stronger security than TLS 1.2 through improved handshake protocols and forward secrecy. Major cloud infrastructure providers have supported TLS 1.3 since 2018–2019; vendors still on TLS 1.2 exclusively are operating below current standards.
Key management is the component most often evaluated superficially. A vendor can implement AES-256 correctly but use inadequate key management—storing encryption keys alongside encrypted data, using software-based key management instead of hardware security modules, or not rotating keys on an appropriate schedule. The security of encrypted data is ultimately limited by the security of the key management, not the encryption algorithm alone.
For legal AI tools specifically, inference-time security—what happens when client documents and queries are actively being processed by the AI model—is the least-documented layer. Client data that is encrypted at rest and in transit may pass through inference infrastructure in a form accessible to the processing system. Understanding what happens at inference time is critical for assessing the actual security of client data during active use.
Core Analysis
Encryption at Rest
Data at rest encryption protects client documents and data stored in vendor systems from unauthorized access if storage media is compromised—through theft, improper disposal, or a storage-layer breach.
Standard requirement: AES-256-bit encryption for all client data at rest.
What to ask:
- What algorithm and key length are used for data at rest? (Correct answer: AES-256)
- Is encryption applied at the file level, database level, or storage volume level? (Volume-level encryption is the minimum; file-level or database-level encryption provides additional protection)
- Are encryption keys stored separately from encrypted data?
- What is the key rotation schedule? (Annual rotation is a minimum standard; more frequent rotation is better)
- Are backup copies of client data encrypted with the same standard as primary storage?
RFP question: "Describe your encryption at rest implementation for client document data, including algorithm, key length, key storage architecture, and backup encryption. Provide the name of the NIST-approved standard used."
Encryption in Transit
Encryption in transit protects client documents and query content as they are transmitted between the law firm's systems and the vendor's infrastructure—preventing network interception.
Standard requirement: TLS 1.3 as primary protocol; TLS 1.2 with strong cipher suites acceptable as a fallback.
What to ask:
- What TLS version is used for client connections? Does the platform support TLS 1.3?
- What cipher suites are supported? Are weak cipher suites (RC4, 3DES, MD5) disabled?
- Is certificate pinning implemented to prevent man-in-the-middle attacks?
- Is mutual TLS (mTLS) available for enterprise API integrations?
RFP question: "Describe your encryption in transit implementation, including TLS version support, cipher suite configuration, and certificate management. Provide documentation of TLS security testing (e.g., SSL Labs grade or equivalent)."
Key Management Practices
Key management is where the practical security of encryption is determined. The most common inadequacy in vendor encryption implementations is poor key management—sound encryption algorithms with inadequate protection of the keys that decrypt the data.
Hardware Security Modules (HSMs): HSMs are dedicated hardware devices for cryptographic key management that provide physical security for keys and tamper-resistant operations. The use of HSMs for managing encryption keys at rest is the gold standard for enterprise data protection. Ask vendors specifically whether their key management uses HSMs or software-based key storage.
Customer-Managed Keys (BYOK): Customer-managed keys (also called Bring Your Own Key) allow the law firm to control the encryption keys used to protect its data in the vendor's systems. If the vendor does not have access to the keys, they cannot decrypt client data even with full access to their own storage systems. BYOK provides the strongest protection against vendor-side unauthorized access and against scenarios where the vendor is acquired or subject to legal process.
Harvey AI and select enterprise vendors offer BYOK options for the largest deployments. This is a meaningful differentiator for firms handling the most sensitive client data.
Key rotation: Encryption keys should be rotated regularly. Ask vendors what their key rotation schedule is and whether key rotation is performed without service interruption. Keys that are never rotated represent a growing risk over time.
RFP question: "Describe your key management architecture for data at rest encryption, including: whether HSMs are used for key storage, whether customer-managed key (BYOK) options are available, and your key rotation schedule and process."
Model Inference Security
Inference-time security is the encryption dimension most specific to AI tools. When client documents and queries are actively processed by the AI model, what is the security posture of that processing?
Third-party LLM APIs: Many legal AI platforms route queries to external LLM APIs (OpenAI, Anthropic, Google) for processing. Ask specifically: Is client document content transmitted to any third-party API? If so, is that transmission encrypted? Does the third-party API provider operate under zero-data-retention terms with the vendor?
Data that passes through a third-party API in encrypted transmission is protected from network interception—but the third-party API processes it in plaintext during inference. The security of that processing depends on the third-party API provider's own security posture and contractual terms.
GPU and compute security: AI model inference runs on GPU infrastructure that may be shared with other tenants in cloud deployments. Ask vendors: Is inference run on dedicated GPU instances or shared infrastructure? What tenant isolation controls are in place?
Prompt injection security: Prompt injection attacks can cause AI models to reveal other users' data or bypass security controls by manipulating input. Ask vendors: What prompt injection testing is performed? Are there architectural controls (input filtering, output scanning) to prevent prompt injection attacks from exposing client data?
Encryption for Specific Workflows
Document review: Client documents uploaded for review should be encrypted both during upload (in transit) and while stored for processing (at rest). Verify that document storage is encrypted, not just the transmission.
Research queries: Research queries may contain privileged legal analysis. Verify that query content is treated with the same encryption standard as document content.
Output storage: AI-generated outputs (research summaries, draft language) may contain client-confidential analysis. Ask whether outputs are encrypted at rest and whether they are retained after delivery.
Walk-through
A 75-attorney firm evaluated three legal AI platforms using the following encryption assessment:
Vendor A: RFP response indicated "AES encryption" and "TLS encryption" without specifics. Follow-up confirmed AES-256 at rest but TLS 1.2 only (no TLS 1.3 support). Key management was software-based (no HSM). No BYOK option. Routed queries through a third-party LLM API with standard commercial terms (not zero-data-retention). Assessment: below standard on TLS version, key management, and inference security.
Vendor B: AES-256 at rest, TLS 1.3 in transit, HSM-based key management, annual key rotation. No BYOK. Did not route queries to third-party APIs—proprietary model inference on dedicated GPU infrastructure. Strong encryption posture across all layers. Assessment: meets enterprise standard.
Vendor C: AES-256 at rest, TLS 1.3, HSM-based key management, BYOK available for enterprise deployments. Routes research features to a third-party LLM API under a zero-data-retention enterprise agreement; document analysis runs on proprietary infrastructure. Highest overall encryption posture; BYOK available for the firm's most sensitive practice groups. Assessment: exceeds standard.
Firm deployed Vendor C for high-sensitivity matters, Vendor B for standard matters.
Recommended Tools
Harvey AI – Enterprise deployment with strong encryption documentation; BYOK available for largest deployments; proprietary model infrastructure.
CoCounsel – Thomson Reuters infrastructure with established enterprise encryption standards. Compare Harvey AI vs CoCounsel.
Relativity – Industry-standard encryption for ediscovery and document review; detailed security documentation available. Compare Everlaw vs Relativity.
Everlaw – Strong encryption posture with SOC 2 Type II; detailed technical documentation available under NDA.
Ironclad – Contract AI platform with enterprise encryption standards; relevant for firms evaluating contract management AI.
FAQ
Q: Is AES-128 unacceptable for legal AI? Some vendors offer it as their at-rest standard.
A: AES-128 is not cryptographically broken—it provides strong protection for most legal data today. However, AES-256 is the enterprise standard for sensitive data and is the algorithm specified in most enterprise security requirements. For data that will remain sensitive for many years, AES-256 provides a larger security margin. Require AES-256 in vendor agreements.
Q: What does "end-to-end encryption" mean when a vendor claims it for their AI tool?
A: The term is frequently misused. True end-to-end encryption means data is encrypted from sender to recipient with no intermediate decryption. For AI tools, this is technically difficult because the AI model must process decrypted text. Ask vendors exactly what is encrypted at each stage rather than accepting an "end-to-end" characterization without specifics.
Q: If a vendor uses AWS or Azure for infrastructure, does that mean they inherit those providers' security certifications?
A: No. AWS and Azure have their own security certifications for their infrastructure layer. The vendor's application layer—where client data is processed—has its own security posture that must be evaluated separately. A vendor running insecure software on AWS infrastructure is not protected by AWS's certifications.
Q: How do we evaluate encryption security without in-house technical expertise?
A: Use the specific questions in this guide as RFP requirements and evaluate whether vendors can answer them specifically and consistently. Vendors that cannot answer these questions precisely likely have not implemented them well. For large deployments, engaging a cybersecurity firm to conduct a technical evaluation of the vendor's security posture is a reasonable investment.
Q: What is quantum computing's threat to AES-256, and should we be worried about it for legal data today?
A: Current quantum computers cannot break AES-256; Grover's algorithm theoretically reduces the effective key strength to 128 bits—which remains strong. NIST's post-quantum cryptography standardization, finalized in 2024, addresses asymmetric cryptography (used in key exchange) more urgently than symmetric encryption (AES). For legal data with a 5–10 year sensitivity horizon, AES-256 is adequate. For data with longer sensitivity requirements, monitor NIST post-quantum guidance.
Key Takeaways
Encryption evaluation for legal AI vendors requires specific technical questions, not general assurances. The four-layer framework—encryption at rest (AES-256), encryption in transit (TLS 1.3), key management (HSM, BYOK), and inference security—covers the complete attack surface for cloud-hosted AI tools.
Key management is where most encryption evaluations fall short. HSM use for key storage and BYOK availability are meaningful differentiators that provide protection against vendor-side access and legal process scenarios that encryption-at-rest alone does not address.
Inference-time security—what happens when client data is actively processed—is the dimension most specific to AI tools and the least commonly addressed in vendor security documentation. Third-party LLM API dependencies are a significant inference-time security consideration that requires specific verification.
Build encryption standards into your RFP process as specific, verifiable requirements rather than general security certification requests. A SOC 2 report confirms controls exist; the RFP questions in this guide confirm those controls are implemented at the specific technical standard your firm requires.
This article reflects independent editorial analysis. LawyerAI does not accept payment for editorial coverage. Tool scores are based on methodology described in Our 5-Dimension Methodology. Last reviewed: 2026-08-16.