Credential injection but not via reverse proxy: is it possible?

[sahuguet]

TL;DR

• the reserve proxy approach forces the sandboxed agent to be written knowing network access will go through the reverse proxy
• a different approach is to launch the agent with HTTP_PROXYset to a local proxy that does credential injection, with zero change in the code of the agent
• would it make sense for nono to support this mode as well.

Longer version
The one issue I have with the reverse proxy approach is that the agent to be sandboxed must be aware of the sandboxing.
To the best of my understanding, the agent code MUST be written as GET http://127.0.0.1:PORT/my-service/... instead of GET https://my-service.com/.... Am I correct?

An approach I have experimented with is to set-up an HTTP proxy (I am using https://www.mitmproxy.org/) and launch Claude code using HTTP_PROXY=http://localhost:8080 claude.

Note

You actually need to provide more env variables to cover upper case, lower case and also no_proxy.

Using this, Claude Code and all the tools and MCPs used by Claude Code do not have to aware of the sandbox.
In my current setting, I am using nono to restrict file access and exclude all network connections with the exception of port 8080 of the HTTP proxy.

All calls routed to the HTTP proxy can be handled with

• policy-based routing, e.g. GET/POST restriction, path restriction, MCP tool restriction
• throttling
• credential injection

According to my reading of the documentation, all network calls (e.g. local tools, MCPs, etc.) inside the nono sandbox must follow the reverse proxy naming convention. This means that I need to change my code to accommodate for that. Am I correct
?

I would prefer to have the luxury of wrapping my agent inside nono, with zero code change.
By forcing my agent to use an HTTP proxy, I think we can achieve that.

[wurbanski]

I was very excited to see the credential injection pattern introduced in nono, but it seems to be very hard to actually use with the current pattern. +1 for getting some documentation and explanations for this.

just for reference: I tried implementing the injected credentials for private gitlab instance and couldn't get it to work easily as all connections get the following:

2026-05-01T21:49:14.224815Z DEBUG Blocked CONNECT to route upstream my.gitlab.instance.com:443 — use reverse proxy path instead
2026-05-01T21:49:14.224820Z  INFO proxy request denied mode=connect host="my.gitlab.instance.com" port=443 decision="deny" reason="route upstream: CONNECT bypasses L7 filtering"
curl: (56) CONNECT tunnel failed, response 403

[lukehinds]

This would be resolved through TLS interception #650 , now planned work in issue: #779

What you're hitting is the intentional block from when reverse-proxy routes are configured for a host, direct CONNECT's to that host are denied with "CONNECT bypasses L7 filtering". The reason being, the proxy sees opaque TLS bytes and cannot inject credentials, so we can't actually swap the credential out. No saying this justifies the current implementation, I agree its not right and should at least be better documented. I hope to get onto this shortly, as a few folks are keen to see this.

[lukehinds]

should be a PR up this week @sahuguet @wurbanski

[sahuguet]

Sweet !!!!
That looks similar to what I have with Python MITM.

Naive question: do we need the NONO_PROXY_TOKEN? I understand this is to prove that the requesting agent is inside the sandbox. But this forces the code to be aware of the sandbox.
And what's the security threat if the proxy injects the Anthropic credentials in a request to api.antropic.com for a client that does not have the nono token? The injection is based on the route of the destination. It will only inject Anthropic credentials to the anthropic.com domain.

Assuming we need the nono token, could the sandbox patch on the fly the requests (or httpx) libraries to make things totally seamless? I would like to avoid the f"Bearer: ...." logic.

[musaabhasan]

The HTTP_PROXY approach makes sense from an application-compatibility point of view because the sandboxed agent can keep using the real upstream URLs. The tradeoff is that credential injection becomes a network boundary concern rather than an explicit route in agent code.

If this mode is supported, I would make a few controls explicit:

• proxy is opt-in per sandbox profile, not global
• credentials are scoped by destination host/path/method, not just by process
• injected headers are never visible to the sandboxed process or logs
• NO_PROXY is controlled or ignored so the agent cannot bypass the proxy for protected hosts
• TLS interception, if used, is clearly visible because it changes the trust model
• every injection event emits an audit record with destination, credential reference, policy version, and decision result

That keeps the ergonomics of normal SDKs while preserving the main safety property: the agent can request a resource, but it never directly receives or stores the credential used to authorize that request.

[lukehinds]

This is in review now: #856