A security architect is asked to make prompts to AI services readable, so that data loss policy can act on them. The answer is that it is possible, on the organisation's own managed devices, by having the organisation sit in the middle of every encrypted connection and decrypt it. It is not possible on a personal device, and doing it at all carries costs that reach beyond the network team. Understanding why requires understanding what TLS actually guarantees, and to whom.
Chapter one established that a prompt sealed by TLS is unreadable on the wire, and readable only at the endpoints. This chapter is about how that seal is made, the single field it has historically left exposed, and what it takes to break the seal deliberately.
What TLS provides
TLS, Transport Layer Security, gives a connection three things: confidentiality, so a third party cannot read the contents; integrity, so tampering is detected; and server authentication, so the client can confirm it is talking to the real server and not an impostor. Its predecessor was SSL, and the term is still used loosely. Modern deployments use TLS 1.3.
The connection begins with a handshake. The client and server use asymmetric cryptography, in which a public and a private key are mathematically paired, to agree on a fresh set of symmetric keys that only the two of them hold. The rest of the session is encrypted with those symmetric keys, which are faster. Because a new set of keys is generated for each session, a party who later obtains the server's long-term private key still cannot decrypt past sessions; this property is forward secrecy, and it is standard in TLS 1.3.
Certificates and trust
Server authentication rests on a certificate: a signed document that binds a server's name to its public key. The signature comes from a Certificate Authority, an organisation the client already trusts. The client trusts a set of authorities whose own certificates are installed in its trust store, placed there by the operating system or browser vendor. When a server presents its certificate, the client checks that the name matches the site it intended to reach, that the certificate chains to an authority in its trust store, and that it has not expired or been revoked. This system of authorities, certificates and trust stores is the PKI, the public key infrastructure. Its load-bearing assumption for this chapter is simple: the client will only trust a certificate signed by an authority already in its trust store.
The one field left in the open
Historically, the client's first handshake message carries the name of the site it wants, the SNI, in clear text, so that a server hosting many sites at one address knows which certificate to present. A device watching the handshake can read the SNI, even though everything after the handshake is encrypted. This is why an organisation can filter or record by destination name without decrypting anything: it reads the SNI. TLS 1.3 encrypted more of the handshake than earlier versions, including the server's certificate, but the SNI remained visible until the separate Encrypted Client Hello effort, covered below, began to close it.
Reading inside: TLS inspection
To read the content of a TLS session, an organisation must become one of the two endpoints. This is TLS inspection, sometimes called break-and-inspect. An inspection point, usually a proxy or gateway, intercepts the connection, presents its own certificate to the client, and makes its own separate connection onward to the real server. It decrypts the traffic in the middle, inspects or logs it, then re-encrypts it. With inspection in place, the organisation can read the full request, including a prompt, and apply policy to it.
Inspection works only because of the trust rule above. The proxy presents a certificate signed by an internal authority, and the client accepts it only if that authority is in the client's trust store. An organisation can install its own authority in the trust store of a device it manages. It cannot do so on a device it does not manage. This single requirement is the reason TLS inspection is a managed-device control: on a personal laptop, the browser does not trust the organisation's authority, so the interception is detected and the connection fails or warns. The device-state limits from the earlier chapters reappear here as a hard boundary.
Why inspection is contested
TLS inspection is the strongest network-side way to read AI prompts, and it is contentious for several reasons at once. It removes the confidentiality TLS is meant to provide, on every inspected site, not only the ones of interest, so it concentrates a large amount of sensitive traffic at one decryption point. It can weaken security if the inspection product validates upstream certificates less rigorously than a modern browser would. It breaks applications that use certificate pinning, where a client is built to accept only a specific certificate and refuses any substitute, including the organisation's. And it raises proportionality and privacy questions, because it exposes staff banking, health and personal activity to the employer along with work traffic. These legal and proportionality questions belong to Part Five; the technical point here is that inspection is powerful, bounded to managed devices, and not free of cost. (high)
The destination name is becoming unavailable even for filtering. Encrypted Client Hello (ECH) encrypts the SNI, so where it is in use, name-based filtering and logging that relied on reading the SNI no longer work, and the organisation is pushed toward either full inspection or coarser address-based controls. (medium; ECH deployment is partial and changing)
Certificate pinning defeats inspection for the applications that use it, which increasingly includes some native apps and updaters, so an inspection deployment usually needs a list of exceptions that are passed through undecrypted, and those exceptions are blind spots. On unmanaged devices, inspection cannot be applied at all, because the organisation's authority is not trusted. And inspection only sees traffic that traverses the inspection point, so a device on QUIC that was not forced back to TCP, or a device off the corporate network, is not inspected regardless of trust. Reading a prompt on the network requires trust, a decryption point, and a path through it, together.
- Explain, to a manager, why the organisation can read prompts on its own laptops but not on a staff member's personal laptop, in terms of certificates and trust.
- A colleague says TLS inspection lets the organisation "see everything". Give two categories of traffic it will not see, and one category it exposes that raises a privacy concern.
- Filtering that relied on reading the SNI has started to fail for some sites. What change is the likely cause, and what are the organisation's two remaining options?
- Why does certificate pinning force an inspection deployment to maintain a list of pass-through exceptions, and why is each exception a blind spot?
Glossary terms used in this chapter
TLS · forward secrecy · certificate · Certificate Authority · PKI · SNI · TLS inspection · certificate pinning · ECH
Sources
- RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3. IETF, August 2018. rfc-editor.org/rfc/rfc8446. Checked 9 August 2026. (high)
- RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions. IETF, January 2011. rfc-editor.org/rfc/rfc6066. Defines SNI. Checked 9 August 2026. (high)
- RFC 5280, Internet X.509 Public Key Infrastructure Certificate and CRL Profile. IETF, May 2008. rfc-editor.org/rfc/rfc5280. The certificate and trust-chain model. Checked 9 August 2026. (high)
- RFC 9162, Certificate Transparency Version 2.0. IETF, December 2021. rfc-editor.org/rfc/rfc9162. Context on how mis-issued certificates are detected. Checked 9 August 2026. (high)
- TLS Encrypted Client Hello, IETF TLS Working Group draft (draft-ietf-tls-esni), work in progress. datatracker.ietf.org/doc/draft-ietf-tls-esni. Deployment is still changing. Checked 9 August 2026. (medium)
Last updated 9 August 2026