Almost every connection leaving a laptop, a server or an agent sandbox is encrypted. That protects the data in transit, and it also hides each request from any control that needs to read it. SSL inspection, also called TLS inspection or SSL/TLS inspection, is how a security proxy you operate reads that traffic: SSL decryption at the proxy, a policy decision on the plaintext, then re-encryption to the destination.

What is SSL inspection?

SSL inspection is the practice of decrypting TLS-encrypted traffic at a proxy the organization controls, examining or enforcing policy on the plaintext, and re-encrypting it before it continues to its destination. Technically it is a man-in-the-middle (MITM) on your own traffic, made legitimate because the clients have been configured to trust the proxy. You’ll also see it called HTTPS inspection, SSL traffic inspection or encrypted traffic inspection.

Without decryption, a network control only sees metadata: the destination IP address and port, and the server name the client asks for. That’s enough to block a domain, not to tell a read from a write on a domain you allow. SSL packet inspection, as some firewall vendors call it, is what turns an opaque stream into requests a policy can reason about.

Is TLS inspection the same as SSL inspection?

Yes. TLS inspection and SSL inspection name the same technique; only the protocol name changed. SSL was the original encryption layer for the web. The IETF prohibited SSL 2.0 in 2011 (RFC 6176) and deprecated SSL 3.0 in RFC 7568 in 2015, then TLS 1.0 and 1.1 in 2021 (RFC 8996). Every connection a modern client opens uses TLS 1.2 or 1.3.

The old name stuck in product menus, in “SSL certificates” and in environment variables such as SSL_CERT_FILE. Search behaviour follows it: more people look for SSL inspection than for TLS inspection. On this page the two terms are interchangeable, and SSL/TLS inspection covers both.

How does a proxy perform TLS inspection?

The proxy ends the client’s encrypted session itself and opens a second one to the real server. Five steps run on every inspected flow:

  1. Get in the path. The client is configured to use the proxy (an explicit proxy), or the operating system or network diverts its connections without the client knowing (a transparent proxy).
  2. Read the ClientHello. The first TLS message names the server the client wants, so the proxy can decide whether to decrypt this flow at all.
  3. Connect to the server. The proxy opens its own TLS session to the destination and receives the server’s real certificate, which it has to validate.
  4. Present its own certificate. The proxy generates a certificate for the same hostname, signed by an inspection certificate authority (CA) that the client trusts, and completes the handshake with the client.
  5. Decrypt, decide, re-encrypt. Requests arrive in plaintext at the proxy, which logs, allows, blocks or rewrites them, then sends them on through the second session.

A firewall that does SSL inspection follows the same steps from the network path; an endpoint agent follows them on the device. A proxy that clients send their outbound traffic through is a forward proxy, and one that decrypts that traffic is sometimes called an SSL forward proxy.

Outbound vs inbound SSL inspection

Outbound inspection, the subject of this page, covers connections your users, servers and agents open to the internet, using your inspection CA. Inbound inspection, or SSL inbound inspection, covers connections arriving at servers you run: the inspecting device holds those servers’ own certificates and private keys, so clients notice nothing. Inbound is closer to TLS termination at a load balancer.

SSL decryption vs SSL inspection vs TLS interception: what’s the difference?

The three terms describe three parts of one process, and vendors often use them as synonyms:

  • TLS interception (or HTTPS interception) is getting into the path of a connection and terminating it, so the client talks to the proxy instead of the server.
  • SSL decryption (or TLS decryption) is turning the encrypted records into plaintext, which interception makes possible.
  • SSL inspection is what happens to the plaintext: logging it, matching it against policy, blocking or rewriting a request.

You can intercept without inspecting (a proxy that only forwards) and inspect without decrypting (reading handshake metadata only). Deep packet inspection, which reads payloads rather than headers, sees only ciphertext on encrypted traffic unless SSL decryption has happened first.

What does SSL decryption mean for privacy?

SSL decryption puts plaintext somewhere it wasn’t before: in the proxy and in its logs. That plaintext can include an employee’s banking session, medical portal or personal email, and the credentials typed into them. The proxy and its log store become sensitive systems that need the same access controls as the data they hold.

Teams that decrypt usually skip categories such as health and finance, tell employees what is inspected and why, limit who can read decrypted content, and keep only the fields a policy or an investigation needs. Rules on monitoring employees differ by country, so check them with your legal team before decrypting personal traffic.

SSL certificate inspection vs deep SSL inspection

Some firewalls offer two modes. Certificate inspection reads what the handshake exposes without decrypting: the server name in the ClientHello and, up to TLS 1.2, the server’s certificate. In TLS 1.3, every handshake message after the ServerHello is encrypted (RFC 8446), so a device that doesn’t decrypt sees little more than the server name. Deep SSL inspection terminates the session and reads the content.

To look at a site’s certificate yourself, click the padlock in the browser’s address bar, or run openssl s_client -connect example.com:443 -servername example.com. On an inspected network, the issuer you see is the inspection CA, not a public certificate authority.

Why inspect encrypted traffic?

Organizations inspect encrypted traffic when a decision depends on the content of a request, not only its destination:

  • Data loss prevention. Find source code, credentials or customer records in an upload or a prompt before they leave.
  • Malware and malicious payloads. Scan downloads and responses that would otherwise arrive inside an encrypted stream, where a security tool sees only ciphertext.
  • Request-level policy. Allow git clone from a code host and block git push to it, or allow reads from an API and block deletes. A domain allowlist can’t express either.
  • Audit. Keep a record of what was sent, by whom, to which service.

URL filtering by hostname needs no decryption, which is why many deployments start there. Moving from destinations to requests is the step that needs SSL decryption, and it’s where a secure web gateway for AI agents differs from a hostname filter.

Which clients break under TLS inspection?

Clients have to trust the inspection CA for any of this to work, and not every client asks the operating system which CAs to trust. Browsers and Go programs read the OS trust store, so installing the CA there covers them. Node.js and most Python HTTP clients ship their own list of root certificates instead and fail the handshake against the inspection certificate until they’re configured.

The usual breakage list, and the usual fix for each:

  • Node.js and npm read extra CAs from NODE_EXTRA_CA_CERTS.
  • Python uses SSL_CERT_FILE (the ssl module and httpx, which the OpenAI and Anthropic SDKs use) or REQUESTS_CA_BUNDLE for requests. Clients that pin the certifi bundle need their own setting.
  • Java uses its own truststore, so the CA has to be imported there.
  • Go binaries that embed a CA pool ignore both the OS store and these variables, so they need their own trust configuration.

Apps that pin a server’s certificate or public key reject any other certificate, including a trusted inspection one; the only fix is to exclude them from decryption. Formal’s Transparent Mode setup and runtime TLS trust docs list the variables per client.

What are the risks of SSL inspection, and when shouldn’t you inspect?

The proxy becomes the client’s only check on the server. Once a connection is intercepted, the client validates the proxy’s certificate, not the real one. In 2017, CISA warned in alert TA17-075A, “HTTPS Interception Weakens TLS Security”, that products which don’t properly validate server certificates, or don’t pass certificate errors on, weaken the protection HTTPS is meant to give.

The other risks are operational. The inspection CA’s private key can impersonate any site to every client that trusts it, so limit who and what can reach it. Decrypted logs are a new store of sensitive data and a privacy exposure of their own. Every exception for a pinned or broken app has to be maintained. And decryption has a performance cost: the proxy does extra cryptographic work on every flow it inspects.

That’s the reasoning behind the “is SSL inspection worth it?” threads that rank for this topic: blanket decryption takes on all of those costs for traffic no rule ever acts on. Skip decryption in these cases:

  • Apps that pin certificates, which will break rather than accept inspection.
  • Personal and regulated categories you have no reason to read, such as banking and health.
  • Destinations no policy will ever make a decision about.
  • Traffic you can control by hostname alone, where blocking or allowing the domain is enough.

The pattern that holds up is selective: decide before decrypting, based on the destination and, where the proxy can see it, the process, then decrypt only what a policy needs.

How does TLS inspection apply to AI agents and coding agents?

AI agents make inspection more useful and harder to scope. A coding agent runs as the engineer who started it, on the same laptop, with the same IP address, and spawns shells, package managers, git and browsers. Almost all its traffic is HTTPS: model APIs, MCP servers, package registries and code hosts, usually domains you already allow.

Without decryption, a policy can only allow or block those domains. With it, three capabilities matter:

  • Select by process before decrypting. Decrypt what an agent and the processes it spawned send, and leave the engineer’s own browser alone.
  • Classify after decrypting. Tell an LLM prompt from an MCP tool call or a plain HTTP request, so a policy can block a secret in a prompt or allow only approved MCP servers.
  • Attribute every request to the person who started the agent, not just to the device.

A proxy can also keep secrets away from the agent entirely by adding credentials on the way out; we walk through that for Claude Code in using proxies to hide secrets from Claude Code. Egress filtering by hostname remains the first layer, and inspection adds the request-level decisions on top.

How does Formal inspect agent traffic?

Formal Endpoint, our egress proxy for AI agents, does TLS inspection on the machine or in the Pod that sends the traffic. On macOS and Linux, Transparent Mode diverts connections at the operating system, with no client changes, and ends each selected TLS session with a certificate issued by the Formal local CA. formal ca trust installs that CA in the OS trust store; on macOS, the Endpoint can also set the CA variables listed above for other runtimes.

Decryption is opt-in. Network rules are CEL conditions evaluated at three points of a connection:

  • pre_tcp runs on macOS, before Formal takes over the connection. A rule can match a known agent such as Claude Code, Codex or Cursor by its code signature, or any process with an agent ancestor. On Linux, this stage is ignored and agents are matched by process name.
  • pre_tls decides whether to decrypt, from metadata alone: where the connection goes, which user and which process tree opened it. A match on a TLS flow makes Formal terminate it. A flow that opens without a ClientHello, such as SSH, is never decrypted.
  • post_tls runs on the plaintext, once Formal has classified it: LLM, MCP or plain HTTP, AWS and GCP API calls, SSH, or one of four database protocols (Postgres, MySQL, MariaDB, MongoDB). If no post_tls condition matches, Formal forwards the traffic unchanged and doesn’t log it.

The Codex Desktop guide walks through a full example: one rule selects Codex and every process it launches, and a policy allows LLM traffic and approved MCP servers while blocking other HTTP. If an app refuses the Formal certificate, the fix is to stop matching it in pre_tls.

The same Endpoint runs where agents run without a desktop. In Kubernetes, a native sidecar intercepts the Pod’s TLS, and injection mounts the Formal CA into application containers; it needs Kubernetes 1.29+, NET_ADMIN and the Privileged Pod Security Standard. In Amazon ECS, the sidecar takes every TCP connection on EC2 and Managed Instances. On Fargate, where NET_ADMIN isn’t available, clients reach it through their HTTP and HTTPS proxy settings instead.

Formal also sits on the data side of agent access. Cursor puts Formal between the environments its agents run in and the sensitive data those agents need:

“Without Formal, we couldn’t have agents with access to sensitive data. With Formal, because we are able to inspect all traffic and enforce controls, we are able to provide a safe environment for the agents to get the job done.”

— Travis McPeak, Head of Security @ Cursor

The Cursor case study covers that deployment. For how Formal fits next to an existing web gateway, see secure web gateway for AI agents.