You've built an AI agent that looks simple from the outside. A customer asks a question, the agent retrieves relevant documents from a vector store, sends context to a model API, calls a business tool, and returns an answer through Slack or a web application. Behind that single interaction, sensitive data may cross several networks and organizational boundaries.
Encryption in transit protects data during those journeys. It's necessary, but it isn't the same as protecting data on disk, inside application memory, or from an authorized service that shouldn't have seen the payload in the first place. The important architectural question isn't only whether traffic is encrypted. It's where encryption ends, which services can decrypt the data, what identity each service proves, and what metadata remains visible.
Table of Contents #
What Encryption in Transit Actually Means #
Consider an agent processing a customer support request. The browser sends the question to an API gateway. The gateway forwards it to the agent runtime. The runtime queries a vector store, sends retrieved context to a model API, receives a response, and may write a ticket to Zendesk or a message to Slack. Each connection is a separate movement of data.
Encryption in transit protects information while it travels across a network. It addresses risks such as interception and modification between communicating endpoints. That makes it different from encryption at rest, which protects stored data in databases, disks, and backups, and encryption in use, which focuses on data while software or hardware processes it.
A useful mental model is a sealed envelope carried by a courier. The envelope should keep outsiders from reading the contents, reveal whether someone altered the contents, and give you confidence that the courier is delivering to the intended recipient. Those are three different promises:
- Confidentiality keeps observers from reading the payload.
- Integrity exposes unauthorized changes in transit.
- Authentication helps the sender verify the endpoint's identity.
TLS commonly provides all three for a network connection, but only within the boundaries of that connection. When a gateway decrypts a request, the data is available to the gateway in plaintext. A new encrypted connection may protect the next hop, but the gateway remains a decryption point.
Practical rule: Every network hop is its own security decision. A secure first connection doesn't automatically secure the connections that follow.
For a platform handling customer prompts, retrieved documents, tool arguments, and model responses, that distinction matters. You'll need to choose protocols, define trust boundaries, manage certificates and private keys, verify what connections negotiate, and decide where hop-by-hop protection is enough versus where payload-level end-to-end encryption is required. Your privacy and data-handling expectations should also be reflected in a documented privacy policy.
How TLS and HTTPS Protect Moving Data #
TLS is the standard mechanism behind most encrypted web traffic. Return to the courier analogy. The client asks to establish a protected delivery route, the server proves its identity with an official ID, both sides agree on secret material, and subsequent envelopes are sealed so the courier can't read or replace their contents.
A TLS 1.3 connection follows that pattern:
- ClientHello: The client proposes supported protocol options, cipher suites, and a key share.
- Server response: The server selects compatible parameters and presents a certificate containing its public identity.
- Key agreement: Both sides derive shared session keys from the handshake material.
- Protected records: Application data travels in authenticated encrypted records.
The certificate doesn't encrypt the entire conversation by itself. It helps the client authenticate the server and establish trust in the key exchange. TLS 1.3 then uses authenticated encryption, commonly through AEAD constructions such as AES-GCM or ChaCha20-Poly1305, to protect records against reading and tampering.
HTTPS is HTTP inside TLS. HTTP still defines requests, responses, headers, methods, and status codes. TLS supplies the protected transport beneath it. That's why an HTTPS request can still expose metadata such as the destination, timing, connection patterns, and approximate message sizes even when its body is protected.
TLS 1.3 also removed several older design choices, including static RSA key exchange, CBC cipher suites, and renegotiation. Its smaller handshake can reduce setup work, which matters when an AI workflow makes frequent calls across distributed services. NIST's guidance for U.S. government systems recommends migration to TLS 1.3, while retaining TLS 1.2 with approved cipher suites as the minimum supported baseline in the referenced publication. See the NIST TLS guidance for the protocol and cipher requirements.
A strong audit asks three separate questions:
- Can an unauthorized observer read the content? That tests confidentiality.
- Can an intermediary change the content without detection? That tests integrity.
- Did the client verify the intended service? That tests authentication.
A connection can be encrypted yet poorly authenticated. It can authenticate a server while still allowing weak protocol negotiation. Encryption in transit is effective when all three properties are configured and verified together.
Choosing Between TLS, SSH, IPSec, and mTLS #
These protocols solve related problems at different layers. Picking one depends on who needs to authenticate, where the tunnel should exist, and which systems should be able to decrypt traffic.
| Protocol | OSI Layer | Identity Model | Typical Use | Main Trade-off |
|---|---|---|---|---|
| TLS | Transport-adjacent, commonly used by application protocols | Usually server authentication through certificates | HTTPS, REST APIs, browser-to-origin traffic | Client identity is often handled separately |
| SSH | Application layer over a secure transport | User keys, certificates, or passwords | Shell access, SFTP, administrative tunnels | Excellent for operators, less natural for broad service meshes |
| IPSec | Network layer | Host, gateway, or network identities | VPNs, site-to-site links, host and cluster tunnels | Can protect broad network paths but adds routing and policy complexity |
| mTLS | TLS with client and server authentication | Both peers present certificates | Service meshes, internal APIs, workload identity | Strong identity, but certificate issuance and rotation require automation |
Use TLS for north-south traffic. A browser connecting to an API, a mobile application calling an origin, or a model runtime calling a public vendor endpoint will usually use HTTPS. The server proves its identity, and the client may authenticate with a session, token, or application credential.
Use mTLS for east-west traffic when services need cryptographic identities. A vector retrieval service can require a certificate from the agent runtime, while the runtime validates the vector service's certificate. That's stronger than trusting a shared API key copied into several workloads. The certificate can represent a specific workload, namespace, or service identity.
Use SSH for human administration. It's appropriate for operator shell access, secure file transfer, and carefully controlled tunnels. It shouldn't become an excuse to build undocumented permanent application dependencies.
Use IPSec for network-level protection. It can secure a whole connection between sites, hosts, or network zones. That's useful when applications shouldn't need to understand the encryption layer, but it doesn't automatically provide the fine-grained service identity that mTLS offers.
The trade-off is operational. TLS is familiar and broadly supported. mTLS gives stronger peer authentication but creates a certificate lifecycle to operate. IPSec can cover more traffic at once, while SSH remains highly practical for people. Choose the narrowest mechanism that matches the trust boundary, then monitor its actual negotiation and termination points.
End-to-End versus Hop-by-Hop Encryption #
Hop-by-hop encryption protects each network link separately. A client establishes TLS with a load balancer, the load balancer decrypts the request, and it creates another protected connection to an application server. An API gateway may repeat the same pattern before forwarding traffic to a model adapter or tool service.
End-to-end encryption keeps a payload protected from the original sender to the final recipient. Intermediate infrastructure can route or transport the data, but it can't decrypt the protected content. Messaging applications that are designed around sender-to-recipient secrecy provide a familiar example. By contrast, ordinary HTTPS through a CDN normally protects the client-to-CDN connection and the CDN-to-origin connection independently.
The difference is not cosmetic. It defines which systems become trusted with plaintext.
A typical AI workflow may need both models:
- Hop-by-hop TLS protects every service connection and supports routing, rate limiting, observability, and policy enforcement.
- End-to-end payload protection can keep especially sensitive prompts, retrieved records, tool arguments, or model responses hidden from infrastructure that only needs to forward them.
- Selective decryption lets a designated agent or policy-controlled service inspect a payload while keeping unrelated intermediaries outside the trust boundary.
The common mistake is treating a browser padlock as proof that the entire workflow is end-to-end encrypted. It usually proves that the browser has a protected connection to a particular endpoint. It says nothing by itself about the CDN, gateway, service mesh, model provider, vector database, logging system, or downstream tool.
Trust boundary equals decryption boundary. If a component can decrypt a payload, treat that component as part of the data's trusted processing environment.
For each AI data flow, document the sender, recipient, intermediaries, and decryption points. If a gateway must inspect a request to enforce authorization, that may be an intentional design choice. If it only decrypts because the architecture evolved that way, consider whether payload encryption, stronger workload identity, or a narrower routing role would reduce exposure.
Key Management and Certificate Lifecycles #
TLS depends on more than a sound protocol. Certificates, private keys, trust stores, renewal workflows, and access controls determine whether the protection continues working in production.
A certificate authority, or CA, signs certificates that bind a public key to an identity such as a hostname or service. Root CAs act as trust anchors. Intermediate CAs issue operational certificates, creating a chain that clients can validate without placing root private keys directly into everyday systems.
Build the lifecycle around automation
Public endpoints can use an ACME-compatible CA such as Let's Encrypt. Internal services can use an internal CA and tooling such as cert-manager. The exact products can vary, but the operational pattern should remain consistent:
- Issue automatically: Create certificates from approved identities rather than manual tickets.
- Renew before expiry: Alert with a meaningful buffer and test renewal paths continuously.
- Rotate private keys: Replace keys on a defined schedule and after suspected compromise.
- Protect key material: Store private keys in an HSM, cloud KMS, or tightly controlled secret store.
- Limit trust: Keep internal and external trust domains separate where their security requirements differ.
Short-lived certificates reduce the period during which a stolen credential remains useful. They also make automation essential. A certificate that expires during a deployment, weekend, or model-provider migration can interrupt every dependent workflow.
For mTLS, assign each workload a distinct identity rather than sharing one certificate across many services. A certificate can represent a service account, namespace, or SPIFFE identity, allowing policy to distinguish the agent runtime from the vector service and the tool connector. Certificate operations should align with your broader security policy. That policy should state who can issue certificates, which services can request them, how revocation works, and how teams investigate unexpected trust relationships. CRLs and OCSP stapling can support revocation handling, but prevention depends on protected keys, narrow permissions, and reliable renewal automation.
Testing What Your Traffic Actually Negotiates #
Configuration files describe intent. A real connection reveals what the client and server agreed to. Test public endpoints, internal gateways, service-mesh listeners, mobile backends, and vendor integrations separately because they may use different policies.
For an external review, [Qualys SSL Labs SSL Server Test](https://www.ssllabs.com/ssltest/) provides a public assessment of certificate deployment, protocol support, cipher selection, and common configuration weaknesses. Treat the grade as a diagnostic, not as proof that your application authorization or logging practices are sound.
For repeatable engineering checks, testssl.sh can enumerate supported versions and ciphers and check for known TLS issues. Run it against controlled test environments and selected production endpoints in CI or scheduled security checks.
For a quick manual inspection, OpenSSL s_client documentation helps engineers inspect the negotiated version, certificate chain, and handshake details. Browser DevTools adds a useful perspective because it shows the connection a real user made, including the protocol version, cipher suite, certificate information, and hostname validation.
Check the result, not just the switch
Your review should confirm:
- Protocol floor: TLS 1.2 or TLS 1.3 is accepted, and obsolete versions are rejected.
- Cipher quality: Negotiation uses forward-secret, authenticated encryption.
- Certificate chain: The chain reaches a trusted root without unexpected intermediates.
- Hostname match: Subject Alternative Names cover the requested hostname.
- Termination path: The backend connection remains protected after a gateway or load balancer.
- Client diversity: Browsers, mobile applications, SDKs, and service clients receive the intended policy.
An agent platform should make these checks part of deployment controls. A changed gateway policy or expired internal certificate should fail a build or rollout before customers discover it. For teams deploying managed agent workloads, hosting and runtime boundaries should also be reviewed alongside transport settings through the Hermes agent hosting page.
Common Pitfalls and Misconceptions #
TLS creates a protected channel, not a complete security architecture. Most failures happen at the edges, where teams assume the channel covers more than it does.
“HTTPS means the whole workflow is encrypted”
HTTPS protects a connection between a client and an endpoint. A gateway can decrypt the request, inspect it, log it, and create another connection. If that backend hop is unencrypted, the first connection's security doesn't extend through the architecture.
Mitigation: Map every hop and require TLS on internal connections. Use mTLS where services need verified workload identities.
“The padlock proves the recipient is trustworthy”
A valid certificate can establish that a client reached the holder of a particular hostname. It doesn't prove that the service handles data appropriately, that an API token has the right scope, or that a compromised endpoint won't expose plaintext.
Mitigation: Combine certificate validation with authorization, scoped credentials, workload identity, and endpoint security.
“Encrypted content hides all useful information”
Transport encryption can still leave metadata visible to network operators and monitoring systems. IP addresses, connection timing, request sizes, routing information, and some handshake fields can reveal relationships and usage patterns. An AI agent calling different tools may expose a recognizable operational profile even when prompt and response bodies remain protected.
A 2026 industry survey reported that 52% of respondents incorrectly believed encryption protects metadata, while 47% incorrectly believed it prevents impersonation or spoofing. Those findings are summarized in BlackBerry's secure communications reporting. Transport encryption doesn't replace privacy controls, authentication, or device trust.
Mitigation: Minimize metadata, restrict telemetry access, avoid sensitive values in URLs, and evaluate traffic-analysis risks for high-sensitivity workflows.
“Modern defaults are universal”
Legacy endpoints can still accept older TLS versions. Email and partner integrations often have long compatibility tails. A separate analysis reported that TLS 1.0 represented 27.61% of email transport and TLS 1.1 represented 22.51% in its dataset, despite their long-standing deprecation. The figures appear in the TechnologyChecker encryption analysis.
Mitigation: Disable obsolete protocols, inventory exceptions, and require documented ownership for any compatibility carve-out.
“Logging is outside the encryption problem”
A service may receive a protected request and then write the full body to plaintext logs. That turns a secure network path into a sensitive data distribution system for every engineer, vendor, dashboard, and backup that can access the logs.
Mitigation: Scrub prompts, retrieved documents, authorization headers, and tool responses by default. Store only the fields needed for debugging, with strict access and retention policies.
“Shared API keys are good enough internally”
A long-lived key reused by an agent, vector service, and tool connector makes attribution and revocation difficult. If one workload is compromised, the same credential can be used to access unrelated paths.
Mitigation: Use per-service credentials, narrow permissions, automatic rotation, and mTLS when certificate-based workload identity fits the environment.
A Practical Encryption in Transit Checklist #
A small platform team can make meaningful progress by treating each connection in the agent workflow as a separate control point.
- Set the protocol baseline. Require TLS 1.2 at minimum, prefer TLS 1.3, and remove weak cipher and legacy protocol support. Enable HSTS for web applications when the deployment supports it, and consider preload only after confirming that every relevant subdomain can remain HTTPS-only.
- Secure certificate operations. Use an automated CA for public endpoints and automated issuance for internal services. Keep certificates short-lived, monitor expiry with a substantial renewal buffer, protect private keys in a KMS or HSM-backed system, and document emergency replacement procedures.
- Give services distinct identities. Use mTLS for sensitive east-west calls between the agent runtime, vector store, model adapter, and tool services. Avoid shared credentials that make it impossible to identify or isolate one workload.
- Protect every internal hop. Verify the connection from browser to gateway, gateway to agent, agent to vector store, agent to model API, and agent to each external integration. Don't assume a private network removes the need for transport protection.
- Test negotiated behavior. Schedule SSL Labs checks for public endpoints, run testssl.sh in controlled CI checks, and use OpenSSL or browser DevTools during investigations. Confirm protocol versions, cipher suites, certificate chains, hostname matching, and termination points.
- Control what survives decryption. Scrub request bodies from logs, restrict access to traces, review metadata exposure, and separate operational diagnostics from customer content. Encryption in transit ends at decryption, so downstream handling becomes part of the security design.
- Add payload protection where trust requires it. If gateways, infrastructure providers, or intermediary services shouldn't see a prompt, retrieved document, or tool result, use an end-to-end design for that payload rather than relying only on hop-by-hop TLS.
The final test is architectural: trace one customer question through the browser, gateway, agent runtime, vector store, model API, and tool integrations. At every hop, record who authenticates, what gets decrypted, what gets logged, and which key or certificate controls access. That map will show whether your encryption strategy protects the workflow you operate, not just the endpoint you configured.
Donely provides a unified dashboard for hosting, deploying, and managing AI employees, with isolated instances, per-instance RBAC, scoped data access, and unified audit logs. If you're turning a multi-service agent workflow into a managed production platform, visit Donely to evaluate how its deployment and governance model fits your encryption and trust-boundary requirements.