Is AI Customer Support Data Encrypted in Transit and at Rest?

Encryption is one of the most fundamental security controls for protecting customer data — and one of the first things security teams ask about when evaluating AI customer support tools. The good news is that most reputable vendors encrypt data both in transit and at rest. The nuance lies in how well they do it, what encryption standards they use, how they manage encryption keys, and whether encryption covers every layer of their architecture.

TL;DR: Encryption in transit (TLS 1.2+) and at rest (AES-256) are baseline requirements for any AI customer support tool handling sensitive data. But encryption alone is not enough — key management practices, certificate handling, and the scope of encryption across all storage layers determine actual security. Evaluate whether your vendor encrypts data at every point in the pipeline, not just the obvious ones.

Key takeaways:

• Encryption in transit using TLS 1.2 or higher protects data as it moves between the customer, your systems, and the AI vendor
• Encryption at rest using AES-256 protects stored conversation data, backups, and logs from unauthorized access
• Key management is critical — vendor-managed keys, customer-managed keys (CMK), and bring-your-own-key (BYOK) offer different levels of control
• Encryption must cover all storage layers including databases, vector stores, caches, logs, and backups
• Regulations including GDPR, HIPAA, PCI-DSS, and SOC 2 all require or strongly recommend encryption as a security control

Encryption in Transit: Protecting Data in Motion

When a customer types a message into your AI support widget, that message travels across the internet to the vendor's servers. Without encryption in transit, anyone intercepting that traffic — on a public Wi-Fi network, at an ISP, or through a compromised network device — could read the conversation in plain text.

Transport Layer Security (TLS) is the standard protocol for encrypting data in transit. Here is what you should look for:

TLS Version

• TLS 1.3 is the latest version (published 2018) and offers the strongest security with improved performance. It eliminates obsolete cipher suites, reduces the handshake to one round trip, and provides forward secrecy by default.
• TLS 1.2 remains widely used and acceptable, provided strong cipher suites are configured. It has been the minimum acceptable standard since TLS 1.0 and 1.1 were deprecated by NIST and major browser vendors.
• TLS 1.0 and 1.1 are deprecated and considered insecure. Any vendor still supporting these versions has a security gap.

Cipher Suites

Within TLS, the cipher suite determines the specific algorithms used for key exchange, encryption, and message authentication. Strong configurations include:

• ECDHE for key exchange (providing forward secrecy)
• AES-128-GCM or AES-256-GCM for symmetric encryption
• SHA-256 or SHA-384 for message authentication

Weak cipher suites (RC4, DES, 3DES, MD5-based MACs) should be disabled. You can verify a vendor's TLS configuration using tools like SSL Labs' SSL Server Test.

Certificate Management

TLS relies on digital certificates to verify server identity. Vendors should:

• Use certificates from trusted Certificate Authorities (CAs)
• Implement certificate pinning for API connections where appropriate
• Automate certificate rotation to prevent expiration-related outages
• Monitor for certificate transparency log anomalies

Internal Encryption

Encryption in transit should not stop at the vendor's load balancer. Data moving between internal services — from the API gateway to the application server, from the application to the database, from the application to the LLM inference endpoint — should also be encrypted. This is often called "encryption in transit within the network" or "mutual TLS (mTLS)" when both parties authenticate each other.

Some vendors terminate TLS at their edge and transmit data in plain text internally, relying on network segmentation for security. While network segmentation adds a layer of protection, internal encryption provides defense in depth against lateral movement by attackers who breach the perimeter.

Encryption at Rest: Protecting Stored Data

Encryption at rest protects customer data when it is stored on disk — in databases, file systems, backups, and logs. If an attacker gains access to the storage medium (through a compromised server, stolen backup tape, or improperly decommissioned hardware), encryption at rest renders the data unreadable without the encryption key.

Encryption Standards

AES-256 (Advanced Encryption Standard with 256-bit keys) is the gold standard for encryption at rest. It is approved by NIST, used by government agencies for classified information, and considered computationally infeasible to break with current technology.

AES-128 is also acceptable and is used by some vendors for performance reasons. The security difference between AES-128 and AES-256 is marginal in practical terms — both are considered secure — but AES-256 is preferred for regulatory and perception reasons.

Encryption Scope

The critical question is not just whether the vendor encrypts data at rest, but where encryption is applied:

Storage Layer	Should Be Encrypted	Notes
Primary database	Yes	Most cloud databases support transparent data encryption
Vector database	Yes	Varies by provider — verify explicitly
Object storage (attachments)	Yes	S3, GCS, and Azure Blob support default encryption
Cache layers (Redis, Memcached)	Ideally	Redis supports encryption; Memcached traditionally does not
Application logs	Yes	Often overlooked — logs contain data fragments
Backups	Yes	Must be encrypted independently, not just inherited
Analytics/reporting data	Yes	Data exported to analytics platforms must maintain encryption

Vendors that encrypt their primary database but leave logs, caches, or backups unencrypted have gaps that undermine the overall security posture.

Key Management: The Critical Factor

Encryption is only as strong as the protection of the encryption keys. If an attacker obtains the key, encryption provides zero protection. Key management practices are therefore the most important aspect of a vendor's encryption implementation.

Vendor-Managed Keys

The vendor generates, stores, and manages encryption keys using a key management service (KMS) such as AWS KMS, Google Cloud KMS, or Azure Key Vault. This is the most common approach and provides adequate security for most use cases, assuming the vendor follows KMS best practices:

• Keys are stored in hardware security modules (HSMs)
• Key rotation occurs automatically at defined intervals
• Key access is restricted and audited
• Separate keys are used for different purposes (database encryption, backup encryption, etc.)

Customer-Managed Keys (CMK)

The customer provides and manages the encryption keys used to encrypt their data in the vendor's system. This gives you control over key lifecycle — you can rotate, revoke, or destroy keys independently of the vendor. If you revoke the key, the vendor can no longer access your data.

CMK is increasingly offered by enterprise-grade platforms and is particularly valuable for organizations with strict data sovereignty or security requirements.

Bring Your Own Key (BYOK)

Similar to CMK, BYOK allows you to generate keys in your own environment and import them into the vendor's KMS. The vendor uses your keys for encryption but the keys are managed within the vendor's infrastructure. This provides a middle ground between vendor-managed and fully customer-managed approaches.

Key Rotation

Encryption keys should be rotated periodically to limit the impact of a potential key compromise. Best practice is to rotate keys at least annually, with the ability to rotate immediately in response to a security incident. The rotation process should be transparent — existing data should be re-encrypted with the new key without service interruption.

Encryption in the AI Inference Pipeline

A unique aspect of AI customer support tools is the inference pipeline — the path data takes when it is processed by the AI model. This pipeline has specific encryption considerations:

Customer message to AI vendor. Encrypted via TLS between the customer's browser/app and the vendor's API endpoint.

Vendor API to LLM endpoint. If the vendor uses an external LLM provider (OpenAI, Anthropic, etc.), the customer's message is transmitted to that provider. This connection must also use TLS. Some vendors process LLM inference internally, keeping data within their own encrypted infrastructure.

LLM response back to vendor. The model's response is transmitted back over TLS.

Vendor to customer. The response is delivered to the customer over the original TLS connection.

At each hop, data should be encrypted in transit. At any point where data rests — even briefly in a queue or buffer — encryption at rest should apply.

Regulatory Requirements for Encryption

Multiple regulations mandate or strongly recommend encryption:

GDPR (Article 32) lists encryption as an explicit security measure and notes that encrypted data affected by a breach may not require notification to data subjects if the encryption renders the data unintelligible to unauthorized persons.

HIPAA Security Rule (45 CFR 164.312(a)(2)(iv) and (e)(2)(ii)) identifies encryption as an addressable implementation specification for both data at rest and in transit. While "addressable" does not mean optional, it means organizations must implement it or document an equivalent alternative safeguard.

PCI-DSS (Requirements 3 and 4) mandates encryption of stored cardholder data and encryption of cardholder data in transit over open, public networks.

SOC 2 Common Criteria evaluates encryption as part of the security trust service criterion, examining both the implementation and management of encryption controls.

How Twig Handles Encryption

Twig implements encryption across every layer of its infrastructure. Data in transit is protected by TLS 1.2 and above, with strong cipher suites and forward secrecy enabled. Data at rest is encrypted using AES-256 across all storage layers — primary databases, vector stores, object storage, backups, and logs.

Twig's key management uses cloud-native KMS with hardware security module backing, automated key rotation, and strict access controls over key operations. All key access events are logged and monitored.

The AI inference pipeline is encrypted end-to-end, with internal service-to-service communication protected by TLS. Customer conversation data is never transmitted or stored in plain text at any point in the processing pipeline.

Decagon and Sierra also implement encryption for data in transit and at rest as part of their security frameworks. Twig specifies the exact encryption standards, covers the full scope of storage layers, and documents its key management practices. For security teams conducting vendor assessments, comparing the level of detail each vendor provides enables a thorough evaluation.

An Encryption Evaluation Checklist

When evaluating AI customer support vendors on encryption:

1. What TLS version is supported? Is TLS 1.0/1.1 disabled?
2. Which cipher suites are enabled? Are weak ciphers disabled?
3. Is internal service-to-service traffic encrypted?
4. What encryption algorithm is used for data at rest? (AES-256 preferred)
5. Which storage layers are encrypted? (databases, vectors, caches, logs, backups)
6. How are encryption keys managed? (vendor-managed, CMK, BYOK)
7. Are keys stored in HSMs?
8. How often are keys rotated?
9. Is the LLM inference pipeline encrypted end-to-end?
10. Can you provide documentation of your encryption architecture for security review?

Conclusion

Encryption in transit and at rest is a baseline expectation for any AI customer support tool — but meeting that baseline requires more than checking a box. The strength of the encryption, the scope of its application, and the rigor of key management practices together determine whether your customer data is genuinely protected. Do not settle for a vendor that says "we encrypt everything" without being able to specify how, where, and with what controls. Encryption done well is one of the most effective defenses against data exposure. Encryption done poorly creates a false sense of security that can be worse than no encryption at all.