Anthropic Python SDK 0.107.1 Fixes Foundry Auth — The Boring Patch That Decides Enterprise Claude Deployments

There's a particular kind of bug that only appears in production: the kind where two correct things collide. That's what happened with anthropic-sdk-python v0.107.0. The maintainers had just hardened the Foundry auth path to prevent a stray ANTHROPIC_API_KEY from leaking into Microsoft Azure Foundry requests. Good fix. But in removing the old header behavior to prevent that leak, they broke the header Foundry actually requires. Result: every v0.107.0 deployment using API-key auth with Azure Foundry started getting 401 errors, and the model — fully healthy, fully deployed — looked broken. v0.107.1 landed June 7 with the patch: send x-api-key, keep api-key for backwards compat, and only send either one when it's actually the Foundry key, never a stray global key.

This is the most enterprise-flavored kind of SDK bug, and it's worth understanding why it happened and what it says about running Claude at scale in cloud-governed environments.

The header that broke a rollout

Issue #1661 on the Anthropic SDK repo is the paper trail. A user reported that anthropic==0.105.2 worked fine with Azure Foundry API-key auth, but upgrading to 0.107.0 produced a clean 401: "Access denied due to invalid subscription key or wrong API endpoint." The model was fine. The deployment was fine. The key was fine. The header name was wrong.

The commit that fixed it is one line in src/anthropic/lib/foundry.py: API-key mode now sends the Foundry key as x-api-key, with api-key preserved alongside it for backwards compatibility. That's the entire changelog. It's also the entire story of why SDK auth regressions are different from model capability bugs — they look like authentication failures, they fail silently in ways that make you怀疑 your cloud configuration, and they affect exactly the teams who've invested the most in getting Claude through their enterprise procurement pipeline.

Azure Foundry is attractive to enterprises precisely because it lets them run Claude through Microsoft infrastructure they already understand: Entra ID, RBAC, regional controls, compliance tooling, and procurement channels that map to existing vendor contracts. That value proposition only holds if the SDK behaves exactly as Microsoft's endpoint expects. One wrong header — or one missing header — and the whole governance story falls apart at the first login attempt.

The security patch that created the regression

What makes v0.107.1 interesting isn't the fix itself but the security tradeoff it documents. The v0.107.0 change that introduced the regression was trying to solve a real problem: in enterprise environments, you often have multiple API keys and deployment-specific credentials floating around the same shell, CI runner, or notebook. ANTHROPIC_API_KEY pointing at the wrong endpoint is both a reliability bug and a data-governance smell. The previous fix tried to prevent any ANTHROPIC_API_KEY from being sent to Foundry when a Foundry-specific key or Entra ID path should be used instead.

That instinct was right. But the implementation removed the header Foundry's endpoint actually checks, replacing it with a header it doesn't recognize. v0.107.1 solves this by keeping both concerns: the safety check still ensures only the Foundry-specific key goes to Foundry (never a stray global key), but the endpoint now gets the header it expects. The security improvement from v0.107.0 stays; the regression goes away.

That's a harder engineering problem than it looks. Auth header design is one of those places where two reasonable requirements — "don't leak the wrong key to the wrong endpoint" and "send the right header to the right endpoint" — can conflict if you don't design the branches carefully. The v0.107.1 patch is the right shape: explicit Foundry key path gets x-api-key, Entra ID token path takes precedence when configured, and the two paths don't cross-contaminate.

What this means for enterprise Claude deployments

The teams feeling this most acutely are the ones who've standardized Claude access through Azure: organizations that have gone through the procurement, compliance, and networking work to get Claude behind their corporate cloud boundary. For them, Foundry isn't a nice-to-have — it's the governance path that made the deployment possible in the first place.

Framework integrations add another layer of complexity here. The bug report mentions Pydantic AI as the context where the breakage appeared. Pydantic AI sits one abstraction above the Anthropic SDK and doesn't always expose every auth nuance cleanly. So a team using Pydantic AI with Azure Foundry might have hit the 401 without ever directly touching the Anthropic SDK's auth logic — the error would look like a Pydantic AI configuration problem, or a Foundry deployment problem, when the real issue was an SDK version bump.

This is the operational hazard of treating SDK updates as routine maintenance. The Anthropic Python SDK is not a commodity HTTP library. When it changes how it authenticates to cloud endpoints, it changes the behavior of every framework, internal wrapper, and agent harness built on top of it. Six files changed, one commit, one header name. That single line can break a production deployment that nobody was watching because "it just installs the latest version on startup."

Microsoft's own Foundry docs reinforce the operational picture. Claude deployments through Foundry require the right base URL, deployment name, auth mode, subscription type, region, and model availability. Claude Code's Foundry docs add a specific sharp edge: pin model versions because aliases like opus may resolve to defaults that aren't available in your account, and Foundry has no startup model check. In that environment, precise auth headers aren't polish — they're how teams avoid blaming the wrong system when something goes wrong.

What teams should do

If you're on anthropic==0.107.0 and use AnthropicFoundry with API-key auth, move to 0.107.1 now. Not after your next deployment cycle. Before.

Add a smoke test that calls your deployed Foundry model using the same auth path as production — not a mocked client, not a local sandbox. That test will catch the next auth regression before it becomes a support ticket. Prefer Entra ID or managed identity for production services where your org supports it, but verify that API-key paths still work for local tools, internal scripts, and framework integrations that depend on them.

Keep ANTHROPIC_API_KEY and ANTHROPIC_FOUNDRY_API_KEY intentionally separated in CI and local environments. Don't let a global key shadow a deployment-specific one. Pin model deployment names, not aliases. And when you see a Foundry 401, inspect the actual headers being sent before you start rotating keys or questioning your cloud configuration — the bug might be in the SDK, not your setup.

The broader read

As Claude spreads into enterprise clouds, SDK releases become integration infrastructure in a way they weren't when the SDK was primarily a researcher tool. The value isn't just new model capabilities — it's predictable behavior across Azure auth, SDK wrappers, agent frameworks, CI systems, and cloud-provisioned endpoints. One missing x-api-key can make a frontier model look broken to an entire enterprise org that spent months getting it approved.

The boring patch is worth covering because it's the patch that decides whether enterprise Claude actually ships, or whether it gets blocked at the "works in dev, fails in prod" stage. The 80% code-authorship numbers from Anthropic's own institute are impressive. But for every organization trying to replicate that outcome through Azure Foundry and enterprise SDK integrations, the real bottleneck isn't model intelligence — it's whether the auth headers are exactly right. v0.107.1 is a reminder that the unsexy parts of the stack are still the parts that matter most.

Sources: GitHub — anthropic-sdk-python v0.107.1, GitHub issue #1661, Microsoft Learn — Deploy Claude in Foundry, Claude Code Foundry docs