Using Proxies to Hide Secrets from Claude Code - FormalBlogJan 13, 2026Using Proxies to Hide Secrets from Claude CodeDrew GregorySoftware EngineerTable of contentsSandboxing agentic coding tools is a networking problemWhat is the worst a sandbox can do?Unpacking the devcontainer firewallUsing network proxies to prevent secrets exfiltration: hiding the ANTHROPIC_API_KEY from Claude CodeTying a developer’s permissions to their Claude Code permissions: proxying Claude Code to the Formal ConnectorWhen hostnames and headers are hard to edit: mitmproy add-onsApplying fine-grained least privilege policiesSandboxing agentic coding tools is a networking problem
Allowlisting commands on a trusted host for an agentic coding tool can be somewhat fraught. Taking inspiration from Simon Willison:

Sandboxes help us reason about their relation to the lethal trifecta:

What untrusted content is the sandbox exposed to?
How can they externally communicate?
What sensitive data are we providing to the sandbox?

 
Anthropic provides several sandboxing tools specific to Claude Code:

Claude Code’s Sandbox Bash tool, which uses sandbox-exec under the hood for OS X users. This is the same technique Chromium uses
Claude Code’s experimental sandbox runtime, which also uses sandbox-exec for OS X users
Anthropic provides a devcontainers template for working with Claude Code that will apply a firewall to
allowlisted IPs.

 
Cursor also has a similar sandboxing feature for Mac users that uses sandbox-exec under the hood for the Cursor IDE. OpenAI’s Codex CLI also supports a sandbox argument that uses sandbox-exec. We’re super excited to see all the new tools to limit what access these agentic coding tools have to our host!
You could also write your own sandbox using gVisor or Firecracker VMs! The themes around network isolation and proxies should transfer.

What is the worst a sandbox can do?
Although the specifics of the sandbox technology affect the level of isolation, a sufficiently sandboxed Claude Code can make a sandboxed Claude Code look like a separate host.

What network access am I allowing Claude Code to have?
What actions can Claude Code perform with this network access and the data it has?

For example, almost all Claude Code instances have access to Anthropic API keys to be able to interact with the Anthropic API.
Claude Code has access to all environment variables present in your terminal session (which are propagated to the Claude Code sandbox), and Claude Code has access to read the files from the directory where you run claude.
Unfortunately, a lot of software requires secrets. For example, development on third-party integrations requires using secrets.
This makes having separate development, staging, and production integration credentials especially valuable, but even development integration credentials are not designed to be publicly accessible: otherwise, they wouldn’t be credentials!

What data am I providing to Claude Code?
What secrets or environment variables will Claude Code have access to?
Are the files (including the source code) I’m providing to Claude Code open-source or public?

 
Consider the precedence of dotenv files to manage secrets on your local repo. Making sure that these .env files are properly .gitignored and .dockerignored is no longer sufficient: leaving these .env files in a folder where you are running claude gives Claude Code access to these secrets.
You could also write your own sandbox using gVisor or Firecracker VMs! The themes around network isolation and proxies should transfer.

Unpacking the devcontainer firewall
The provided devcontainer template has an init-firewall.sh script that applies a firewall to the devcontainer running Claude Code. This firewall permits network connections to the following hosts by default:

registry.npmjs.org: allow installing npm packages
api.anthropic.com: interact with Anthropic’s API
sentry.io: a logging and error observability product that Anthropic is using
statsig.anthropic.com/statsig.com: a feature flagging product that Anthropic is using
marketplace.visualstudio.com: enable installing VSCode extensions
vscode.blob.core.windows.net/update.code.visualstudio.com: a blob store used by VSCode
GitHub’s web, API, and git servers

 
This firewall is enforced at the IP layer: the init script performs a dig to resolve these hosts’ IP addresses and uses iptables to allow connections to these IPs. This does mean that the particular connection to these hosts is not necessarily enforced at the TLS/HTTP layers; for example, an AWS ALB on an allowlisted IP that routes traffic based on SNI or Host headers could still receive requests that specify different hosts.
In addition, the firewall supports inbound and outbound traffic to any IP address on port 22 for SSH connections.
If we:

Use this firewall
Provide environment variables we would not want to be publicly accessible
Run the devcontainer with claude –dangerouslyUnsafePermissions

 
The devcontainer could exfiltrate sensitive data, including credentials, via a
variety of ways:

Connect to a random IP over port 22
Create an npm package with the secret in the tarball
Create a github gist with the credentials

 
Even if we only HTTP traffic to a select set of hosts, this problem remains challenging because of Domain Fronting: there are often a huge diversity of actions you can perform on a single domain. Applying restricted privileges to these kinds of domains at the IP, domain, or even host level is often not fine-grained enough to allow the actions you want to allow and block the actions you want to block. In fact, prompt injection attacks in particular have taken advantage of overly broad domain allowlists to exfiltrate sensitive information!
The specifics of what kind of network traffic you want to permit and not permit often requires looking at the application layer.

Using network proxies to prevent secrets exfiltration: hiding the ANTHROPIC_API_KEY from Claude Code
Thankfully, Claude Code supports using proxies to route traffic! There are two ways to configure Claude Code to use proxies:

A HTTP_PROXY environment variable that applies to all Claude Code HTTP traffic. This proxy environment variable intercepts HTTP traffic that the parent Claude Code process makes.
A sandbox httpProxyPort. This intercepts HTTP proxy traffic for bash commands executed from within the sandbox.

 
Note that these proxy configurations are independent of each other: the HTTP_PROXY environment variable will not intercept HTTP traffic from bash commands in the sandbox, and the sandbox httpProxyPort will not intercept HTTP traffic from the Claude Code CLI tool that is outside of the sandbox.
You can configure Claude Code to use an HTTP proxy using the following configuration in settings.json:

mitmproxy is a great tool to run these HTTP proxies. Note: provide the mitmproxy-generated TLS certificate to intercept TLS traffic to Claude for node processes via export NODE_EXTRA_CA_CERTS=~/mitmproxy/mitmproxy-ca-cert.pem.
The mitmproxy tool also supports addons where you can transform HTTP requests between Claude Code and third-party web servers. For example, you could write an add-on that intercepts https://api.anthropic.com and updates the X-API-Key header with an actual Anthropic API Key.
You could then pass an invalid Anthropic API Key to Claude Code so that neither the Claude Code process nor the sandbox has access to our Anthropic API Key!

You could then run mitmweb with the right API key:

Afterwards, run claude with the ANTHROPIC_API_KEY environment variable set to an invalid API key:

From the perspective of Claude Code, all API responses from api.anthropic.com will appear to Claude Code as if the API key of sk-ant-dummy is a valid API key!
Unfortunately, Claude Code still requires signing in via OAuth before checking if the ANTHROPIC_API_KEY is set, so you may have to sign in via OAuth first, grab the API key, close the session, and then start a new claude process with an invalid ANTHROPIC_API_KEY environment variable.
This kind of technique is not unique to hiding your Anthropic API Keys: you could insert dummy API keys and secrets and use mitmproxy addons to intercept these HTTP requests and inject actual API keys once the request has left the Claude Code process and sandbox.

Tying a developer’s permissions to their Claude Code permissions: proxying Claude Code to the Formal Connector
Our customers use Formal to apply least privilege to both human and machine identities. You can also leverage Formal to decouple human & machine identities from Native Users and apply fine-grained least privilege at the application layer. A lot of the techniques to apply organizational least privilege are relevant for applying least privilege to Claude Code sandboxes: if your organizational permissions are sufficiently constrained, the blast radius of a rogue Claude Code with a developer’s credentials should be small as well.
To date, Admin Anthropic API Keys inherit the full permissions of the user who created them, and there is no ability to make API keys more fine-grained. API keys generated from the Claude API for Claude Code, however, seem to have restrictions on what API endpoints they are allowed to use, but we have not found documentation on the exact permissions that are allowed versus disabled.
Developers may want to use Claude Code to write and run code that uses an Admin Anthropic API Key. If they pass the API Key via an environment variable, the sandbox will have access to this Admin Anthropic API Key. An organization, however, may want to prevent certain API actions from being taken with an Anthropic API Key and have logging on who is performing which API actions. Developers may not notice the distinction as well!
The best way to prevent Claude Code from leaking an API Key is to make sure that it never has direct access to the credentials in the first place! One can use Formal Connectors, Formal Resources, and Native Users to make sure that Claude Code cannot leak the API Key. That way, Claude Code can make requests to the Connector with Formal-specific credentials and the Connector can inject actual secrets when communicating with the upstream API.

When hostnames and headers are hard to edit: mitmproy add-ons
For hostnames and headers that are hard to tweak, use mitmproxy add-ons to route the HTTP requests for these domains to the corresponding listener.

You can then pass this add-on via mitmproxy -s reroute_hosts.py.
One advantage of this approach is that you do not have to configure hostnames and ports for Claude Code: the default hostnames and ports for these APIs will look identical from the perspective of Claude Code.

Applying fine-grained least privilege policies
We could then create a policy in a similar way to the policy we created for the local Github MCP server use case.

If we change the path param to “/v1/messages,” we can confirm that this policy is able block requests to the Anthropic API even outside of the Claude Code sandbox:

We also get visibility into every request being made to the Anthropic API across our organization!

Of course, this technique was not specific to safeguarding Anthropic API Keys: one can use HTTP proxies and Claude Code sandboxes to enforce least privilege for your API Keys even if you want to enable Claude Code to use some of these APIs!
Proxies as a result can help in two dimensions of the lethal trifecta:

Proxies can limit the ability to externally communicate by allowing or blocking traffic.
Proxies can also limit an agent’s access to private data if they don’t need to read that data for inference. Credentials can be injected for actions the agent wants to take with those credentials without allowing the credential to be available to a language model’s context window.

Speak to an EngineerLearn the platform in less than an hour. Secure your data stack in less than a day.
Get a demoGet the latest Formalities in our newsletter.Find usFor DevelopersIntegrationsSecurity CenterResourcesBlogCustomersSupport StatusCompanyAboutCareersPartners© 2025 Formal. All Rights Reserved.TermsPrivacyCookies

The article explores the challenges of securing agentic coding tools like Claude Code by addressing the critical issue of secret exfiltration through network proxies. It begins by framing sandboxing as a networking problem, emphasizing three core concerns: the exposure of untrusted content to the sandbox, its external communication capabilities, and the sensitive data it accesses. The authors reference Simon Willison’s work on this topic, highlighting that while sandboxes aim to isolate processes, they often remain vulnerable to data leaks. For example, Claude Code instances typically have access to environment variables and files in the directory from which they are run, including secrets like API keys. This creates a risk if developers inadvertently expose sensitive data through configuration files or environment variables, such as `.env` files that may not be properly excluded from version control.

The article then delves into the specific tools provided by Anthropic for sandboxing, such as the Sandbox Bash tool and devcontainers template. These tools apply firewalls that restrict network access to predefined hosts, including `api.anthropic.com` and GitHub servers. However, the firewall operates at the IP layer, using `iptables` to allow connections based on resolved IP addresses. This approach has limitations: for instance, a load balancer on an allowlisted IP could route traffic to unintended hosts via SNI or Host headers, bypassing the firewall’s intent. Additionally, the firewall permits SSH traffic on port 22, which could be exploited by malicious code to exfiltrate data. The authors caution that even with these protections, a compromised devcontainer running `claude –dangerouslyUnsafePermissions` could still leak secrets through methods like creating malicious npm packages or GitHub gists.

To mitigate these risks, the article advocates for using network proxies to intercept and control Claude Code’s traffic. It outlines two primary methods: configuring the `HTTP_PROXY` environment variable for general HTTP traffic and setting a sandbox-specific `httpProxyPort` to intercept bash command traffic. The authors recommend tools like mitmproxy, which can act as a transparent proxy to monitor and manipulate HTTP/HTTPS requests. By deploying mitmproxy with custom add-ons, developers can rewrite headers (e.g., replacing the `X-API-Key` field) to inject real API keys only after requests leave the sandbox. This technique allows developers to pass dummy API keys to Claude Code, ensuring that the actual credentials are never exposed within the sandboxed environment. However, they note a caveat: Claude Code requires OAuth authentication before validating the `ANTHROPIC_API_KEY`, so users must first sign in, retrieve the key, and then reset it to an invalid value before running the tool.

The article also discusses extending this approach to enforce least privilege policies at the application layer. By integrating formal identity management systems like Formal, organizations can decouple human and machine identities, ensuring that even if a developer’s credentials are compromised, the scope of potential damage is limited. For instance, Formal Connectors can act as intermediaries between Claude Code and external APIs, injecting real secrets only when necessary. This approach prevents direct exposure of API keys to the sandbox while maintaining accountability through logging. The authors emphasize that this strategy aligns with broader organizational security practices, where fine-grained access controls are applied to both human and automated workflows.

A specific challenge addressed is the difficulty of modifying hostnames and headers in certain scenarios, such as when dealing with third-party APIs. The article suggests using mitmproxy add-ons to reroute HTTP requests dynamically, bypassing the need for manual configuration of hostnames and ports. For example, an add-on script can intercept traffic to `api.anthropic.com` and redirect it to a local proxy, ensuring that Claude Code remains unaware of the redirection. This method preserves the appearance of normal network behavior while enabling centralized monitoring and policy enforcement. The authors also highlight that such proxies can be used to apply granular access controls, blocking requests based on specific paths (e.g., `/v1/messages`) or headers, thereby preventing unauthorized API calls.

The discussion extends to the broader implications of proxies in addressing the “lethal trifecta” of security: external communication, data access, and privilege escalation. By limiting network traffic to predefined endpoints and injecting secrets only when necessary, proxies reduce the risk of data leaks. Additionally, they restrict agents from accessing sensitive information not required for their tasks, such as environment variables or source code. The article underscores that this dual-layer approach—combining technical safeguards (proxies, firewalls) with organizational policies (least privilege)—is critical for securing agentic tools.

Finally, the authors conclude by emphasizing that while sandboxes and proxies are powerful tools, they must be complemented by robust internal practices. This includes auditing environment variables, ensuring `.env` files are excluded from version control, and training developers to recognize the risks of exposing secrets. The article positions these strategies as essential for maintaining security in an era where agentic tools increasingly interact with sensitive systems and data. By combining technical solutions like mitmproxy with organizational frameworks such as Formal, developers can create a more secure ecosystem for using tools like Claude Code.