Two organisations both run a proxy, and both route staff traffic through it. In the first, the security team can produce the exact text a staff member submitted to an AI service. In the second, the team can produce only the name of the service and the times of the connections. Neither proxy is misconfigured. The difference is a single decision about whether the proxy decrypts, and this chapter shows precisely what that decision includes and excludes.
The previous chapter covered how TLS is decrypted. This chapter covers what is inside once it is, and what remains hidden when it is not, by looking at the structure of an HTTP request.
The shape of an HTTP exchange
HTTP is a request-and-response protocol. A client sends a request naming a method, such as GET to retrieve or POST to submit; a target, expressed as a URL; a set of headers carrying metadata such as the host, the type of content and authentication tokens; and, for methods like POST, a body carrying the actual payload. The server replies with a status code, its own headers, and a response body. HTTP is stateless in itself, so applications track a logged-in session using a cookie or a token carried in a header on each request.
When a staff member submits a prompt through a chat interface or an application, the prompt travels in the body of a POST request to the service's endpoint, and the model's reply comes back in the response body. The destination name is in the host header and matches the SNI seen during the handshake. The full path and query are in the URL. The prompt itself is in the request body, and the answer is in the response body.
The version of HTTP affects the framing but not this structure. HTTP/2 multiplexes several requests over one connection; HTTP/3 does the same over QUIC. Both carry the same requests, responses, headers and bodies as HTTP/1.1, so the question of what is visible reduces to whether an observer can read inside the encryption.
HTTPS is HTTP inside TLS
HTTPS is not a separate protocol; it is HTTP carried inside a TLS connection. Everything above, the method, URL, headers, body and response, sits inside the encrypted channel. On the wire, none of it is visible; an observer sees an encrypted stream to an address, plus the destination name in the handshake, as covered earlier. This is the whole reason the proxy's decision matters.
What a proxy sees, in two postures
A proxy is a server that traffic passes through. Its view of an HTTPS request depends entirely on whether it terminates and decrypts the TLS connection.
In the pass-through posture, the proxy does not decrypt. A client asks the proxy to connect it to a destination using the CONNECT method, and the proxy then relays an opaque encrypted tunnel between the client and the server. The proxy can see the destination name in the CONNECT request and in the SNI, the address, the timing, and the rough volume of traffic. It cannot see the method, the full URL path, the headers, the request body or the response. In this posture, a prompt is not visible; the proxy log shows that a device reached the service and roughly how much data passed.
In the inspecting posture, the proxy performs the TLS inspection described in the previous chapter: it terminates the client's TLS connection, decrypts, and opens its own connection onward. Now it sees the complete request and response: the method, the full URL, every header, the request body containing the prompt, and the response body containing the answer. Everything the application sent is available to logging and policy. This posture is what allows content-based data loss policy to act on the text of a prompt. Its preconditions are exactly those of TLS inspection: a managed device that trusts the organisation's authority, and traffic that actually passes through the proxy. (high)
The two postures are the boundary. Without decryption, the request body is never visible, so no amount of proxy logging yields the prompt; the organisation has destination and volume only. With decryption, the prompt is visible, but only for traffic that meets the inspection preconditions, and only for the browsers and applications whose traffic is routed through the proxy and do not pin their certificates.
Some patterns complicate even the inspecting posture. Streaming responses, where a model returns its answer token by token over a held-open connection, arrive as a long response body rather than a single message, which a naive logger may capture partially. Multiplexing in HTTP/2 and HTTP/3 interleaves several requests on one connection, so parsing has to separate them. And a prompt submitted through a service's own application programming interface, rather than a browser, is still a POST body and is visible under inspection, but may travel from a tool the proxy does not cover. The rule holds across all of these: destination without decryption, content with it, and only where the traffic and the device allow inspection at all.
- Two teams both route traffic through a proxy; one can retrieve prompt text and one cannot. Name the single difference and explain, in terms of the request body, why it produces that result.
- In the pass-through posture, list what the proxy log can and cannot contain for a connection to an AI service.
- Where in an HTTP request does a submitted prompt travel, and where does the model's answer travel? Why does that placement matter for logging?
- A prompt is sent through an AI service's API from a desktop tool rather than a browser. Under what conditions is it still visible to the organisation, and under what conditions is it not?
Glossary terms used in this chapter
HTTP · HTTPS · URL · cookie · HTTP/2 · SNI · proxy · CONNECT method
Sources
- RFC 9110, HTTP Semantics. IETF, June 2022. rfc-editor.org/rfc/rfc9110. Defines methods, headers, status codes and the CONNECT method. Checked 9 August 2026. (high)
- RFC 9112, HTTP/1.1. IETF, June 2022. rfc-editor.org/rfc/rfc9112. Checked 9 August 2026. (high)
- RFC 9113, HTTP/2. IETF, June 2022. rfc-editor.org/rfc/rfc9113. Checked 9 August 2026. (high)
- RFC 9114, HTTP/3. IETF, June 2022. rfc-editor.org/rfc/rfc9114. Checked 9 August 2026. (high)
- RFC 6265, HTTP State Management Mechanism. IETF, April 2011. rfc-editor.org/rfc/rfc6265. Defines cookies. Checked 9 August 2026. (high)
Last updated 9 August 2026