Hello! Today we look at data loss prevention in the AI era — with a particular focus on the communications technology involved — and discuss how organizations should approach AI security.

1. Introduction

With the rapid spread of generative AI, corporate data governance has entered a new phase. Large language models (LLMs) such as ChatGPT and Claude dramatically improve productivity, but they also bring a serious risk: the unintended leakage of confidential information.

Many organizations are still not fully aware that customer information or trade secrets casually entered by employees could end up being used as training data for AI services. Traditional DLP (Data Loss Prevention) solutions are good at monitoring email and file transfers, but they are not equipped for the new threats that can arise in real-time, web-based AI chat and interactions with AI agents.

In this article, we take a detailed, technical look at the core technology behind data loss prevention in the AI era — in particular, HTTPS traffic interception and its limits. From how proxy servers work to the defense mechanism known as certificate pinning, we will clarify, from a technical standpoint, the practical challenges that corporate security teams face.

2. Fundamentals of HTTPS Traffic Interception

Now that virtually all modern web traffic is encrypted, an organization that wants to monitor data being sent to AI services (data that could well lead to information leakage) needs a way to see inside encrypted communications.

HTTPS, however, was designed precisely to prevent eavesdropping by third parties. How do we resolve this contradiction?

The SSL/TLS protocol establishes a secure communication channel between a client and a server. During this process, the client verifies the certificate presented by the server and confirms that it was signed by a trusted certificate authority (CA). Once encryption is established, the traffic is exchanged in a form that third parties cannot decipher.

In an enterprise environment, monitoring this encrypted traffic requires a proxy server to act as a "man in the middle." This means using the same principle as the well-known security threat, the man-in-the-middle (MITM) attack, for a legitimate purpose. This approach demands great care, both technically and ethically.

Nobody enjoys having their communications monitored.

Speaking for myself, as an individual, the thought that someone might be reading my email or chat messages is not a comfortable one. I think that is a perfectly natural feeling for anyone who values privacy.

When we work for a company, however, we take on responsibilities that differ from those of a private individual.

Companies are entrusted with valuable personal information from their customers — from basics such as names, addresses, and phone numbers to purchase histories, health records, and financial data. They also handle, day in and day out, the confidential information that underpins their competitiveness: years of R&D results, sales strategies, blueprints for new products, and more.

What happens if this information leaks — carelessly or maliciously? A leak of personal information causes great trouble for customers and can sometimes inflict real harm. A leak of corporate secrets can mean the loss of competitive advantage, a plunging stock price, and in some cases can even threaten the company's survival. Above all, trust built over many years can be lost in an instant.

That is exactly why companies have a responsibility to appropriately monitor employees' work communications and prevent the risk of information leakage. This is not a matter of distrusting employees. Rather, it is about protecting them from mistakes they might make unintentionally, and creating an environment where they can focus on their work with peace of mind.

3. The Two Operating Modes of Enterprise Proxies

With that in mind, let's turn our focus to the proxy server as a tool for monitoring data exchanged over HTTPS.

Proxy servers used in enterprises operate in one of two broad modes. Each mode has different goals and constraints, and the difference matters greatly when monitoring AI traffic.

3.1 Tunneling Mode (the CONNECT Method)

In tunneling mode, the proxy server functions as, quite literally, a "tunnel." When a client requests a connection through the proxy using the CONNECT method, the proxy establishes a connection to the destination server and thereafter simply relays the encrypted data exchanged between the two.

Let's look at how this mode works in concrete terms. The client first sends a request like the following:

CONNECT api.openai.com:443 HTTP/1.1
Host: api.openai.com:443

When the proxy receives this request, it establishes a connection to api.openai.com on port 443 (HTTPS) and, on success, returns a "200 Connection Established" response. From that point on, the proxy simply relays the encrypted data as-is and never decrypts its contents.

The greatest advantage of this mode is that end-to-end encryption is preserved. Because the proxy cannot see the data, privacy is protected. But this is also its greatest drawback: if a company wants to monitor confidential information being sent to AI services, this mode allows no monitoring at all.

3.2 SSL/TLS Interception Mode

In SSL/TLS interception mode, the proxy actively intervenes in the communication, temporarily removing the encryption to inspect the contents. In this mode, the proxy establishes two independent SSL/TLS connections: one between the client and the proxy, and another between the proxy and the server.

Let's walk through the flow in detail. When a client tries to access an HTTPS site, the proxy actually responds by impersonating that site. Using an intermediate CA certificate managed by the company, the proxy generates a server certificate on the fly. The client receives this certificate, and because the CA has been pre-registered as trusted, the connection is established without any warnings.

Meanwhile, the proxy establishes a separate connection to the real server and communicates using the server's legitimate certificate. With this dual connection, the proxy can decrypt traffic in both directions and inspect the contents in plaintext. Once inspection is complete, the data is re-encrypted and forwarded.

Implementing this mode involves a wide range of technical considerations — dynamic certificate generation, session management, performance optimization, and more — making it far more complex than simple forwarding.

4. Building a Trust Chain with an Intermediate CA Certificate

The key to making SSL/TLS interception work is the proper management of an intermediate CA certificate. To understand this mechanism, we first need to look closely at the certificate trust chain.

An ordinary website's certificate is signed by a trusted root certificate authority (Root CA), either directly or via an intermediate CA. Browsers and operating systems ship with a built-in list of trusted root CAs, and certificate validation follows this chain to confirm trustworthiness.

To perform SSL/TLS interception in an enterprise environment, the company must create its own intermediate CA certificate and distribute it to every managed device. This certificate — usually called an "enterprise CA" or "private CA" — is valid only within the organization.

In a Windows domain environment, certificate distribution can be automated with Group Policy. Administrators register the certificate in Active Directory and configure it to install automatically when computers boot or users log in. On macOS and Linux, distribution is typically handled through an MDM (Mobile Device Management) solution or Configuration Profiles.

What matters most is keeping the private key of this intermediate CA certificate under strict control. If the private key leaks, an attacker could impersonate the legitimate proxy and intercept traffic. For this reason, protecting the key with a hardware security module (HSM) is recommended.

5. Practical Challenges in Implementing AI-DLP

The challenges we engineers face in implementing DLP for the AI era are qualitatively different from those of traditional DLP. What are they?

5.1 Cases That Can Be Monitored

Let's start with the cases that today's technology can reliably monitor.

Technically, the easiest case to monitor is AI use through a web browser. Common browsers such as Chrome, Edge, and Firefox use the OS certificate store, so they work without issues through a properly configured enterprise proxy.

Company-managed applications can be monitored as well. For example, an AI client application developed in-house, or an application customized for enterprise use, can be brought under monitoring with the appropriate proxy configuration.

Access via an API gateway is another effective monitoring approach. By deploying its own API gateway and restricting all AI API access to go through it, a company can achieve complete monitoring and control. This method is technically clean and sidesteps the pinning problem, though it is not very common.

5.2 Cases That Are Hard to Monitor

On the other hand, some cases are difficult or impossible to monitor with today's technology. The prime example is certificate pinning — applications implemented to trust only hard-coded CAs or certificates. By design, these applications do not tolerate any man in the middle, so they are fundamentally incompatible with enterprise proxies. VPNs that use SSL tunneling and access via personal devices also tend to be blind spots. When an employee accesses an AI service from a personal smartphone over mobile data, corporate network monitoring is completely ineffective. With the spread of BYOD (Bring Your Own Device), this problem is becoming ever more serious.

Monitoring is also difficult when the network is open to the outside without passing through the proxy, when lines exist that connect directly to the outside world apart from the corporate LAN, or when traffic uses protocols other than HTTP/HTTPS, such as WebSocket or gRPC.

6. Proxy Architecture Implementation Patterns

Deploying a proxy in an enterprise environment requires a design that considers the network architecture as a whole. Let's look at the main implementation patterns and their characteristics.

6.1 Transparent Proxy

A transparent proxy is an implementation that requires no special configuration on the client. At the network-device level (routers or firewalls), HTTPS traffic is forcibly redirected to the proxy server.

The greatest advantage of this approach is that it prevents user misconfiguration and deliberate evasion. Users browse the internet as usual without ever being aware of the proxy. Implementation, however, is complex and requires changes to the network configuration.

Technically, it is often implemented using policy-based routing (PBR) or the Web Cache Communication Protocol (WCCP), which demands advanced skills from network engineers. When performing SSL/TLS interception, certificate errors also need to be handled.

6.2 Explicit Proxy

With an explicit proxy, the client is explicitly aware of the proxy server and configured to use it. The proxy server's address and port are specified in the browser's or OS's network settings.

To automate configuration, many companies use Proxy Auto-Configuration (PAC) files or the Web Proxy Auto-Discovery (WPAD) protocol. These technologies enable flexible proxy control while minimizing manual configuration by users.

How WPAD Auto-Configuration Works

WPAD is a particularly interesting technology: without employees configuring anything, the browser automatically discovers the appropriate proxy settings. Let's look at how it works.

When an employee launches a browser with "automatically detect proxy settings" enabled, the browser first queries the DHCP server. If a WPAD file URL is provided via DHCP option 252, it is used. If no information is obtained via DHCP, the browser attempts discovery through DNS.

In DNS discovery, the browser searches for a WPAD server step by step, based on its own domain name. For example, if an employee's PC has the hostname "pc01.sales.tokyo.qualiteg.com," the search proceeds in the following order:

1. wpad.sales.tokyo.qualiteg.com
2. wpad.tokyo.qualiteg.com
3. wpad.qualiteg.com

Once a WPAD server is found at any of these stages, the browser downloads the "wpad.dat" file (effectively a PAC file) from that server. This file contains proxy-selection logic written in JavaScript and chooses the appropriate proxy server based on the destination URL.

For example, a wpad.dat file that accounts for AI monitoring might look like this:

function FindProxyForURL(url, host) {
    // Connect directly to internal sites
    if (isInNet(host, "10.0.0.0", "255.0.0.0")) {
        return "DIRECT";
    }
    
    // Route AI services through the dedicated monitoring proxy
    if (dnsDomainIs(host, ".xxx_ai.com") || 
        dnsDomainIs(host, ".ai_xxx_chat.com")) {
        return "PROXY ai-proxy.qualiteg.com:8080";
    }
    
    // All other external sites go through the standard proxy
    return "PROXY proxy.qualiteg.com:3128";
}

Integration with Group Policy

In an Active Directory environment, combining WPAD with Group Policy makes auto-configuration even more reliable. Group Policy can enable WPAD auto-detection or explicitly specify the URL of a PAC file. Many companies configure both to ensure redundancy.

WPAD does come with a few caveats. For security reasons, Windows 10/11 has tightened restrictions around WPAD, and serving it over HTTPS is recommended. In addition, the wpad.dat file must be served with the correct MIME type (application/x-ns-proxy-autoconfig); it will not work if served as a plain text file.

The advantages of an explicit proxy are its simple implementation and minimal impact on the existing network configuration. It also integrates easily with authentication, enabling per-user access control and logging. On the downside, users may change the settings or bypass the proxy.

Summary

In this article, we focused on the technical side of data loss prevention in the AI era — in particular, how HTTPS interception works and where its limits lie.

We examined the technical foundations of enterprise web-traffic monitoring in detail: decrypting SSL/TLS traffic with a proxy server, building a trust chain with an intermediate CA certificate, the difference between CONNECT-based tunneling and SSL/TLS interception, and the technical constraint known as certificate pinning.

In fact, these proxy techniques and HTTPS interception are common methods already widely adopted in existing DLP products. In traditional data loss prevention as well — email monitoring, file-transfer control, web-access auditing — these technologies have played a central role.

As this article has made clear, however, these "traditional monitoring technologies" alone are not enough in the AI era. Technical limits remain: the constraints imposed by certificate pinning, access via personal devices, support for new protocols, and more.

Next Time: The Evolution from Traditional DLP to AI-DLP

This time, we focused on HTTPS interception, a "foundational technology" also used in existing DLP products. It is an important foundation, but for data loss prevention in the AI era, it is only the starting point.

Next time, we turn to the more essential questions: why traditional DLP cannot keep up in the AI era, and what new considerations AI-DLP must take into account.

1. What are the data-leakage risks unique to AI?

2. The need for real-time processing and contextual understanding

3. Bidirectional auditing — a new paradigm

4. Implementation challenges specific to AI-DLP

The proxy technology covered this time is, so to speak, the foundational technology for "seeing the traffic." Next time, we dive deep into the challenges specific to AI-DLP: how to judge and control the traffic we can now see, in the age of AI.

We will consider — from both the technical and operational perspectives — a new approach to data protection truly suited to the AI era, rather than a mere extension of traditional DLP.

See you next time!