Secure Web Gateway (SWG) for AI Agents

On a developer laptop, a coding agent and the engineer who started it share one user, one device and one IP address. A secure web gateway that decides by user and URL sees one client. To allowlist what the agent reaches without locking out the engineer, the egress policy has to know which process opened each connection.

What is a secure web gateway (SWG)?

A secure web gateway (SWG) is a proxy between your users and the internet that applies security policy to outbound traffic: which sites and services can be reached, what can be sent, and what gets logged. Secure web gateway services ship as cloud services, on-premises appliances or endpoint agents, and are often sold inside a SASE or SSE platform.

Most secure web gateway solutions combine TLS inspection, URL and category filtering, malware scanning and data loss prevention for web traffic, built around a person browsing the web. That model still works for employees, so the question for AI agents isn’t whether to keep your SWG. It’s what agent traffic needs on top of it.

Why does agent traffic need more than an SWG allowlist?

An agent doesn’t browse. It runs shell commands, calls model APIs, talks to MCP servers, pulls packages and pushes code, often from processes it spawned a few seconds earlier. Every one of those connections leaves with the engineer’s identity, so a policy keyed on user, device and destination can’t treat the agent differently from the person.

Allowlists alone don’t close the gap either. An allowed domain still accepts uploads, so the control has to look inside the request: the method, the path, the MCP tool call, the git command. And agents increasingly run in places an SWG client was never installed: cloud agent VMs, Kubernetes jobs and ECS tasks.

How do TLS inspection and egress filtering work in Formal?

Formal Endpoint intercepts outbound traffic in Transparent Mode, without changes to client applications. Network rules written in CEL choose which TCP connections to intercept, in up to three stages:

• pre_tcp (macOS only) sees the connecting process, its ancestors and the destination port.
• pre_tls sees the destination hostname and port, the process tree, its command line and the user. If any pre_tls condition matches a TLS flow, Formal terminates TLS with a certificate from the Formal local CA.
• post_tls sees the classified plaintext protocol: http, mcp, llm, aws, gcp, postgres, mysql, mariadb, mongodb or ssh.

Intercepted traffic is evaluated against your Rego policies, which can allow, block or rewrite a request (headers, path or body for HTTP, LLM and MCP traffic). A block with block_with_formal_message returns the policy ID plus the session and request IDs, so the person or agent who hit it can hand those to the security team.

Interception is opt-in. A connection that no rule matches passes through untouched and doesn’t appear in Logs. To build an allowlist, select everything a given agent sends, then block what the policy doesn’t allow, as the Codex Desktop example above does.

TLS inspection needs clients to trust the Formal CA. formal ca trust adds it to the OS trust store, which browsers and Go programs use. Node.js and most Python HTTP clients ship their own roots, so on macOS the Endpoint can set NODE_EXTRA_CA_CERTS, SSL_CERT_FILE and similar variables for them. Exclude from pre_tls any application that still won’t trust the Formal certificate.

Where does Formal Endpoint run?

Transparent Mode runs on macOS and Linux. Elsewhere, how traffic reaches the Endpoint differs, so plan the rollout per platform:

Explicit proxy mode, on Linux and on Fargate, only sees clients that honor the proxy variables. A client that ignores HTTPS_PROXY connects directly and isn’t inspected, so use full interception wherever Formal must enforce all egress.

How do you control egress from agent sandboxes and Kubernetes pods?

On Kubernetes, the Endpoint runs as a native sidecar next to the application container, not on the host. It authenticates as a Formal machine user, and the Helm chart injects it into Pods labeled formal.ai/kubernetes-egress-inject: "true" along with the Formal CA. By default it doesn’t attribute traffic to a process; with a shared process namespace, logs add the PID, name and command line. See the Kubernetes egress guide.

On Amazon ECS, a Terraform module adds the sidecar and signs it in with the task role over OIDC, so there’s no API key to rotate. Application containers start only after the Endpoint has loaded your policies, so their first request is already inspected. Cloud agents follow the same pattern, as described in giving cloud agents production access with OIDC.

How does Formal fit next to your existing SWG?

Keep your secure web gateway for employee browsing. Scope Formal’s network rules to agents and the processes they spawn, and the two don’t collide: in the Codex Desktop example, a developer’s own browser never matches the rule. Policies, identities and audit logs live on the shared Formal platform, alongside the Connector that protects databases and internal services.

Because the Endpoint classifies the protocols agents use most, the same deployment also covers:

• Model traffic: prompts and responses to LLM providers, covered on the AI gateway page.
• Tool calls: MCP requests to approved and unknown servers, covered on the MCP gateway page.
• Unapproved tools: discovering AI harnesses, MCP servers and skills nobody approved, covered on the shadow AI page.
• Package registries: npm, PyPI and other registry traffic can be routed through a Socket Registry Firewall, which scans packages while Formal applies access policy.

Roll out in Draft or Dry-run first: dry-run triggers appear in Logs with their policy status, so you can see what a rule would block before it blocks anything. Endpoint logs carry the source desktop and can be forwarded to your SIEM.

Who uses Formal to control agent access?

Cursor combines isolated environments and tightly restricted outbound connections with scoped Formal policies on data, so its security team decides what agents access and sees what they do with it:

“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 how Cloud Agents connect through a dedicated Formal identity tied to the employee who started the task.