The OSI and TCP/IP models, and why we keep two of them

Why a network is described in layers

Moving data from a laptop to a server in another country involves several separate mechanisms: the physical signal on copper, fibre or radio; the local office network; routing across the internet; reliable delivery of the data in order; encryption; and the rules a browser and a web server use to exchange messages. These parts are designed and built independently. The standard way to manage that complexity is to divide the work into layers, each with one job. A layer relies on the layer below it and provides a service to the layer above, and it does not need to know how the lower layers work internally.

The common naming scheme for those layers is the OSI model, short for Open Systems Interconnection, a seven-layer reference model published by the international standards bodies in the 1980s. The internet is not built exactly to this shape, but the model is worth learning because it gives everyone a shared vocabulary. When an engineer refers to a problem "at layer 3" or a product that works "at layer 7", they mean a specific layer in this model. From the bottom up, the layers are as follows.

The physical layer is the actual signal: voltage on a wire, light in a fibre, radio in Wi-Fi. The data link layer organises those signals into frames and moves them between devices on the same local network, using hardware addresses assigned to each network interface. The network layer is where data becomes a packet and gains an IP address, a numeric address that lets the packet be routed across many networks to a machine anywhere in the world. The transport layer gets a stream of data to the right program on that machine, in order and without gaps where required; this is where TCP and UDP operate, and where the port numbers identify which program the data is for. The top three layers, session, presentation and application, deal with keeping a conversation going, the format of the data, and the protocols programs actually speak, such as the web's HTTP. "Layer 7" usually refers to this top layer, which carries the meaning of the traffic.

One term recurs throughout Part One: protocol. A protocol is an agreed set of rules for a conversation: which messages are allowed, in what order, and what to do on error. Each layer has its own protocols, and each protocol exposes a different amount of information to anyone watching the traffic. That point is central, and the chapter returns to it.

How a message travels down the stack

The mechanism that connects the layers is encapsulation. As the data goes down the stack, each layer adds its own header describing what it is carrying. By the time the data leaves the laptop, the original prompt is wrapped in a series of headers: an application-protocol header, then a transport header naming the port, then a network header naming the source and destination IP addresses, then a link header for the next hop. Each layer adds only the header it is responsible for. At the receiving end the process runs in reverse: each layer reads and removes its own header and passes the rest up, until the server's application receives the prompt as sent.

This is what determines visibility. A device in the middle of the network can usually read only the outer headers. A router needs the network-layer header to forward the packet, so it can read the IP addresses; it does not read the inner headers or the payload, and often cannot. A firewall may also read the transport header, so it can read the port. Whether anything in the middle can read the payload, which is the prompt itself, depends on whether that payload is encrypted.

The other model, and why we keep both

The OSI model is a reference and a teaching tool. The internet itself was built to a simpler design that predates OSI's final form: the TCP/IP model, named after its two central protocols. It has four layers rather than seven. Its link layer combines OSI's physical and data link; its internet layer corresponds to the network layer and is where IP operates; its transport layer matches OSI's; and a single broad application layer absorbs OSI's session, presentation and application. This is the model the internet actually follows, set out in the early Internet standards for how a host should behave.

Both models are kept because they serve different purposes. TCP/IP describes what happens on the wire; where the two disagree about where something belongs, the wire follows TCP/IP. OSI, with its finer divisions and numbered layers, is the common vocabulary for explaining and comparing products; a vendor describes "layer 7 filtering" because the term is widely understood. A defender needs both: OSI for communication, TCP/IP for accuracy. The mismatch is worth knowing. OSI's session and presentation layers do not correspond to any distinct layer the internet implements, which shows that the seven-layer diagram is a simplification, not a build specification.

One more point before the worked example. A packet's IP address gets it to the right machine; the port number in the transport header gets it to the right program on that machine. Web servers listen on well-known ports, 443 for encrypted web traffic. But the user did not type an address or a port; they typed a name. Turning that name into an address is the job of the DNS, the Domain Name System, and it happens before any connection is made. The fact that the name is looked up first, and separately, matters for what follows.

The worked example, layer by layer

We can now answer the opening question by following the prompt down the stack and asking, at each layer, what an observer at that layer can read.

First, the name. Before the browser can connect, it asks DNS to turn chat.openai.com into an IP address. That request goes to whichever resolver the laptop or network is configured to use. Anyone operating that resolver, or watching the request, sees the name being looked up. A block at the DNS layer is a common first control: the organisation configures its resolver to refuse to answer for chat.openai.com, or to answer with a dead address, and the page does not load. Note the limit of what this sees. A DNS control sees that a request was made for a particular name. It does not see any of the prompt, because at this point nothing has been sent to the service.

Second, the connection. With an address in hand, the browser opens a TCP connection to that IP on port 443. A firewall or router in the path reads the network and transport headers, so it sees the source address (the laptop, or the shared office address after NAT), the destination IP, and the port. It can allow or refuse the connection on those grounds. An IP address is imprecise: large services share addresses behind content delivery networks, so blocking by address can catch unrelated sites or miss the target when its address changes. No content is visible at this layer.

Third, the encryption. Before any prompt is sent, the browser and the server carry out a TLS handshake to set up an encrypted channel. Historically, one field in that handshake is sent in clear text: the SNI, or Server Name Indication, which tells the server which site the client wants, so that one address can host many. A network device watching the handshake can read that field. This is why the organisation can accurately state that the device connected to chat.openai.com: the destination name is exposed in the handshake, even though the rest of the session is encrypted.

Fourth, the prompt. Once TLS is established, the user submits the three paragraphs as an HTTPS request inside the encrypted channel. On the wire, that request is encrypted; a device in the middle sees an unreadable stream. The prompt exists in unencrypted form in only two places: in the browser on the user's device, before it is encrypted, and on the service's servers, after it is decrypted. It is not readable anywhere in between.

This is the central principle of the manual, and the rest of it follows from this point. The layer at which a control operates determines what it can read. A control on the network can read names, addresses and ports; it cannot read a prompt encrypted by TLS. To read the prompt, a control must operate where the prompt is unencrypted: at the application layer, on the endpoint itself. That means the browser, an agent running on the device, an extension inside the browser, or an inspection point that has been given the keys. Later chapters cover endpoint data loss prevention, the browser compliance extension, and inspecting proxies installed on managed machines. Each is a response to the same constraint: the prompt is readable only at the endpoints, so a control that needs to read it must operate at an endpoint.

Last updated 9 August 2026