Is this worth asking a vendor about?

Only as a way into the more useful question, which is how many parties a request passes through. The connection from your browser is a settled matter; what a vendor does onward, and which other providers are involved, is where the differences between two vendors actually appear.

Does it protect us from the vendor?

No, and it is not intended to. The material arrives readable at the vendor because that is what makes the service work. Protection from the vendor is a matter of what they retain, what they may use it for and who inside can reach it, all of which are contractual.

What about internal connections?

They are the likelier gap. Public connections are effectively always encrypted, while traffic between internal services has sometimes been left plain on the assumption that the internal network is safe, which is the assumption current thinking treats as the weakest link.

Glossary

Encryption in transit

Scrambling data while it moves between two systems so that anything watching the connection sees nothing usable in passing.

In plain terms

The envelope is sealed while the letter is in the post. Nobody handling it along the way can read it. What the sender wrote, and what the recipient does with it once opened, are outside what the envelope has any opinion about.

Why it matters

Because it is genuinely universal and therefore rarely the thing that goes wrong. Any serious service uses it, browsers refuse connections without it, and a buyer will not find a credible vendor lacking it. The value of understanding it is knowing that the journey is the settled part, so attention belongs at the two ends where nothing is settled at all.

How it works

The two ends agree on a shared secret before any content moves, and everything after that is unreadable to anything watching the connection. What passes over the network is noise to an observer, which is why public networks stopped being the interesting risk some years ago.

The protection ends exactly where the connection does. Material arrives readable at the far end because it has to be usable there, so everything the receiving system then does with it, including storing it, indexing it or passing it onward, happens outside this control entirely.

Identity is the half people forget. The arrangement also establishes that the far end is who it claims to be, which matters more than the scrambling in practice: a perfectly encrypted connection to the wrong destination protects the material beautifully all the way to somewhere it should never have gone.

Inside an organisation it is less uniform than on the public internet. Traffic between internal services, or between a tool and a connected system on a private network, has historically sometimes been left unencrypted on the reasoning that the network itself was trusted, which is the assumption most modern security thinking has moved away from.

For AI tools the relevant question is how many hops there are. A request may pass from a browser to a vendor, from that vendor to a model provider, and from there to somewhere else again, and each hop is a separate arrangement. The first hop is the one a buyer can see, and it is rarely the whole journey.

Where a request is readable

Laying the hops out in order shows why end-to-end is the wrong mental picture for most AI tools. The protection is real and it applies to the segments between the parties, not across them; at every place the request stops to be processed it is ordinary readable text, because processing it is the entire purpose. That is not a flaw in the arrangement, it is what the arrangement is. The consequence worth drawing is that a buyer asking whether a connection is encrypted has asked about the segments, which are settled and uniform across every credible vendor, and has not asked about the stops, which vary enormously. How many parties are involved, which of them retain anything, and for how long, are the questions that separate one vendor from another, and none of them is visible from the fact that the connection is secure. The second thing the sequence makes plain is that the buyer can usually only see the first hop themselves. Everything past the vendor is described rather than observed, which is why it belongs in a contract rather than in a technical check.

Seen in the wild

Asking an assistant vendor which onward providers a request reaches, rather than only how the browser connects to them.
ChatGPT
Checking that a search tool's connections to internal systems are encrypted, not only its public interface.
Glean
Confirming a self-hosted deployment terminates connections properly, since nobody else is doing it for you.
Open WebUI

Common misconceptions

People assume

It protects the data end to end.

In fact

It protects each connection. Where a request passes through several parties, each hop is its own arrangement and the material is readable at every point in between, which is exactly where it is processed.

People assume

The encryption is the important part.

In fact

Verifying the far end is at least as important. A properly encrypted connection to the wrong destination delivers the material intact to somewhere it should never have reached, and the encryption worked perfectly throughout.

Questions

Is this worth asking a vendor about?: Only as a way into the more useful question, which is how many parties a request passes through. The connection from your browser is a settled matter; what a vendor does onward, and which other providers are involved, is where the differences between two vendors actually appear.
Does it protect us from the vendor?: No, and it is not intended to. The material arrives readable at the vendor because that is what makes the service work. Protection from the vendor is a matter of what they retain, what they may use it for and who inside can reach it, all of which are contractual.
What about internal connections?: They are the likelier gap. Public connections are effectively always encrypted, while traffic between internal services has sometimes been left plain on the assumption that the internal network is safe, which is the assumption current thinking treats as the weakest link.

Key takeaways

The journey is the settled part; the two ends are not.
Each hop is a separate arrangement, so several parties means several connections.
Verifying the far end matters as much as the scrambling.
Internal traffic is likelier to be the gap than public traffic.

Tools that use this

ChatGPT
Asking which onward providers a request reaches beyond the first hop.
Glean
Whether internal connections are encrypted, not only the public interface.
Open WebUI
Self-hosting makes terminating connections properly your responsibility.

Last checked August 2026

All glossary terms