An organisation buys a cloud service that promises to inspect web traffic and enforce AI policy wherever staff work, on or off the corporate network. It is deployed, and coverage is good for staff on managed laptops. It is zero for staff using personal devices at home. The vendor did not overstate the product. The gap is structural, and it is the same gap that has appeared at the end of every chapter in this part. This chapter names the architectures that decide where inspection happens, and shows why the roaming case always returns to the device.
This is the synthesis chapter for Part One. It puts the address, transport, TLS and HTTP mechanisms together into the question a defender actually asks: where, physically, does the organisation get to look, and what has to be true for the look to happen.
Proxies: forward and reverse
A forward proxy sits in front of clients and mediates their outbound connections to the internet; it is the kind relevant to controlling staff use of AI services. A reverse proxy sits in front of servers and mediates inbound connections to them, and is a different tool for a different job. When this manual says proxy without qualification, it means a forward proxy.
A forward proxy can be explicit, meaning devices are configured to send traffic to it, often through a PAC file that tells the browser which proxy to use for which destinations; or transparent, meaning the network silently redirects traffic to it without device configuration. Either way, the proxy is only useful for traffic that reaches it, and, as the previous two chapters established, it reads content only when it performs TLS inspection on a device that trusts its authority.
The secure web gateway
A SWG, secure web gateway, is a forward proxy with security functions built around it: URL and category filtering, malware scanning, TLS inspection, and data loss inspection of what passes through. It is the product an organisation typically points to when it says it controls web access. A SWG can run as an appliance on the corporate network, or as a cloud service. The distinction decides its reach.
An on-premises SWG inspects traffic that crosses the corporate network. It covers devices in the office, and remote devices only when their traffic is carried back to the corporate network through a VPN. A staff member working from home without that tunnel does not pass through it, so it does not see their traffic at all.
Cloud SWG and SASE
A cloud SWG moves the inspection point to the provider's network, reached over the internet. To send a device's traffic to it, the organisation installs a small forwarding agent on the device, or configures the device to tunnel to the provider. The agent follows the device wherever it goes, so a managed laptop at home is inspected the same way it is in the office. This is the model that delivers the roaming coverage the on-premises appliance cannot.
SASE, secure access service edge, is the broader architecture that combines a cloud SWG, a CASB, zero trust network access and cloud firewalling into one cloud-delivered service; its security functions on their own are often labelled SSE, security service edge. The relevant part for AI control is the same cloud SWG function: it inspects a device's web traffic from the cloud, including prompts, when TLS inspection is configured. Zero trust network access, ZTNA, is a related idea that replaces broad VPN access with per-application access decisions; it governs reaching internal applications more than reaching public AI services, but it belongs to the same architecture. The term SASE was defined by an industry analyst firm in 2019 and is used loosely by vendors, so confirm what a given product actually does rather than relying on the label. (medium; the term is a market category, not a standard)
The pattern that runs through all of it
Every architecture that inspects a roaming device's traffic does so by getting that traffic to an inspection point and decrypting it there. Getting the traffic there, off the corporate network, requires software on the device: an agent or an enforced tunnel. Decrypting it requires the device to trust the organisation's inspection authority. Both are properties of a managed device. It follows that the strongest network-layer control over AI prompts, a cloud SWG or SASE with TLS inspection, reaches exactly as far as device management reaches, and no further. On an unmanaged personal device off the corporate network, there is no agent to forward the traffic and no trusted authority to decrypt it, so none of these products apply. This is the same boundary seen at the DNS, transport, TLS and HTTP layers, now stated at the level of architecture. (high)
The roaming agent is a managed-device feature, so the entire cloud-SWG and SASE approach is absent on personal devices. Even on a managed device, the same evasions from earlier chapters persist: QUIC that was not forced back to TCP can bypass a proxy that only handles TCP; a personal browser or profile that is not covered by the agent's forwarding is not inspected; certificate pinning forces pass-through exceptions that are blind spots; and split-tunnel configurations send some traffic around the inspection point.
There is also a governance cost that this part flags and Part Five develops: routing all of a person's traffic through an employer-controlled cloud inspection service, and decrypting it, gathers a large amount of personal activity into one place, which raises proportionality and privacy questions independent of whether the technology works. The architecture answers where inspection can happen. Whether it should, and within what limits, is a separate decision.
- An on-premises SWG covers the office well but misses staff working from home. Explain why, and name the two ways their traffic could be brought back into coverage.
- A cloud SWG reaches managed laptops anywhere but not personal devices. Identify the two device properties that create that boundary.
- A vendor sells a "SASE platform". List three questions you would ask to establish what it actually inspects for AI usage.
- State the single sentence that summarises how far a cloud SWG with TLS inspection can see, and why.
Glossary terms used in this chapter
forward proxy · reverse proxy · PAC file · SWG · VPN · SASE · SSE · CASB · ZTNA
Sources
- RFC 9110, HTTP Semantics. IETF, June 2022. rfc-editor.org/rfc/rfc9110. Defines proxy behaviour and the CONNECT method used by forward proxies. Checked 9 August 2026. (high)
- NIST Special Publication 800-207, Zero Trust Architecture. NIST, August 2020. csrc.nist.gov/pubs/sp/800/207/final. Underpins the ZTNA concept. Checked 9 August 2026. (high)
- Gartner, origin of the term "secure access service edge" (SASE), 2019. Publisher: Gartner. Cited as the source of the market category; the defining report is not freely available, so treat vendor use of the term with care. Checked 9 August 2026. (medium)
Last updated 9 August 2026