Microsoft Agent Framework behind a corporate proxy: the HTTP transport that ignored HTTPS_PROXY

#python

Originally published in French on Medium.

An agent works on the developer's laptop, then can't reach its API once deployed at the client. No clear exception, no useful trace: the call just never gets through. In a large company, the first suspect is usually the same: the proxy.

That's what happened to me with the TypeSafe (Jev) connector in Microsoft Agent Framework. The fix was merged by the Microsoft team on October 6, 2026: microsoft/agent-framework#8984.

Context

I use Jev, TypeSafe's model, to decide whether a passage retrieved from a large document library actually supports an answer. Microsoft Agent Framework ships a Python connector for TypeSafe. In corporate environments, servers reach the Internet through a proxy configured with HTTPS_PROXY, HTTP_PROXY, ALL_PROXY and NO_PROXY.

The symptom: the TypeSafe SDK on its own reached the API in that environment. The same call through the Agent Framework connector did not.

Root cause

When the connector created its own client (AsyncTypeSafeClient), it passed a custom HTTP transport, _ApiKeyTransport, whose only job was to add the Authorization: Bearer <key> header.

httpx only reads the proxy environment variables when no custom transport is given. By replacing the transport, the connector silently disabled the company's whole network configuration.

A textbook silent bug: no error when the client is created, no warning. The setting exists; it is just ignored.

The fix

The custom transport was redundant: the TypeSafe SDK (0.7.1 and 0.7.2) already sends the Authorization header itself. It redacts that header in log records and exception messages, not on the wire.

The fix:

removes _ApiKeyTransport, so the SDK builds its default transport and proxy variables apply again;
updates the connector's AGENTS.md note: connector-owned clients rely on the SDK for the bearer header and keep its transport;
keeps transport-level tests that check the configured key is actually sent in the outgoing request.

Less code, standard network behavior.

The test to add to your own integrations

Whenever an HTTP client gets a custom transport, adapter or session, check two things:

the proxy: run the integration with HTTPS_PROXY pointing to a test proxy and check the request goes through it;
the header actually sent: test the request that leaves the client (with a mock transport that captures it), not just the object's configuration.

A test on configuration says "the key is set". A test on the request says "the key is sent, through the right path".

Takeaways

Replacing the httpx transport makes it ignore HTTPS_PROXY, NO_PROXY and the other proxy variables.
Before adding a transport for a single header, check whether the SDK already sends it.
Test what goes on the wire, not what the object thinks it sends.

This is my first fix in Microsoft Agent Framework. I've also had fixes merged into Mistral AI (mistral-common) and OGX (formerly Llama Stack), with the same method: audit a component under real conditions before adopting it, and fix it at the source.

Zakaria Khchiche is a freelance Data & AI Tech Lead in Paris. He builds and runs AI agents in production for large companies and contributes to open-source agent frameworks. LinkedIn · Website

Want your team to build agents like these? I run a hands-on Copilot Studio training (in French, with Spar-x, Qualiopi-certified, eligible for OPCO funding in France): training program and a free AI Act article 4 kit: AI Act kit.

DEV Community