Use Claude on Microsoft Foundry
Claude Inside the Microsoft Cloud
Microsoft Foundry is the third platform through which Claude is offered to developers, alongside the direct API, Amazon Bedrock, and Google Cloud's Vertex AI. An organization that runs on Microsoft's cloud, and manages identity through Microsoft Entra ID, can reach Claude through the same resources, billing, and access controls it uses for its other Azure services. The SDK includes a Foundry client for this, and the Messages API you have learned is the interface.
This lesson covers how the Foundry client is created, the two ways it can authenticate, how the resource name determines where requests go, and how to check the configuration for mistakes that are easy to make, including the most serious one: writing a secret into source code.
Resources and Endpoints
A Foundry request is addressed to a resource, which is the Azure object that holds your Claude access. The client builds the address of the service from the resource name, so the name is the one setting that decides where requests go. A wrong name sends the request to the wrong resource, or to none, and the error is typically a not-found or access problem rather than a clear message about the name itself.
The resource name appears in the endpoint address, so it follows the rules for web hostnames: lowercase letters, digits, and hyphens, with no spaces or underscores. A name that fails those rules cannot be a valid endpoint, and the check in this lesson catches it before a request is attempted.
Installing and Creating the Client
Like the other cloud clients, the Foundry client is available with the SDK. The client is created with the resource name, and it reads the credentials from the environment:
from anthropic import AnthropicFoundry
client = AnthropicFoundry(resource="acme-claude")
message = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=256,
messages=[{"role": "user", "content": "Say hello."}],
)
The model name in this example is an illustration of the call's shape. Model names on Foundry come from the deployments in your resource, so the name must match a deployment that exists there. The Foundry documentation lists the available models and how deployments are named, and that list is the authority.
Two Ways to Authenticate
Foundry accepts two kinds of credential, and the choice depends on how the application runs:
| Method | How it works | Suits |
|---|---|---|
| API key | A key for the resource, read from the environment variable ANTHROPIC_FOUNDRY_API_KEY | Local development, and simple deployments with a secret store |
| Microsoft Entra ID | A token issued to a managed identity or a service principal | Production workloads on Azure, where no secret needs to be stored |
The API key method is the simplest to start with. Entra ID is generally preferred in production, because the application holds no long-lived secret, and access can be granted and revoked through the identity system. Lesson 164 covers both methods in detail, including where each credential should live.
Validating the Configuration
The configuration check below does two jobs. It verifies that the resource name follows hostname rules, and it refuses a configuration in which the API key is written directly into the code. The second check is the more important one, because a key in source code is copied into version control, into build logs, and into every copy of the project:
"""foundry_config.py: check a Foundry resource name and where the credential comes from."""
import re
RESOURCE = re.compile(r"^[a-z0-9](?:[a-z0-9-]{0,62}[a-z0-9])?$")
def check_foundry(resource: str, credential_source: str) -> list[str]:
problems = []
if not RESOURCE.match(resource):
problems.append(f"resource name {resource} must use lowercase letters, digits, and hyphens")
if credential_source == "literal":
problems.append("API key must not be written in code; use the environment or Entra ID")
return problems
if __name__ == "__main__":
cases = [
("acme-claude", "environment"),
("Acme_Claude", "environment"),
("acme-claude", "literal"),
]
for number, (resource, source) in enumerate(cases, start=1):
print(f"case {number}:", check_foundry(resource, source) or "ok")
Output:
case 1: ok
case 2: ['resource name Acme_Claude must use lowercase letters, digits, and hyphens']
case 3: ['API key must not be written in code; use the environment or Entra ID']
How It Works
- The resource pattern follows hostname rules. It requires a lowercase letter or digit at each end, with lowercase letters, digits, or hyphens between them, up to sixty-four characters.
Acme_Claudefails on its capital letters and underscore. - The credential check is about where a value comes from, not what it looks like. The configuration states the source, and a literal value is refused, because a literal in code is a secret in the repository.
- Each problem names the rule it breaks, so the fix is clear. A developer reading the message knows whether to rename the resource or move the key.
- The checks run before the client is created, which means a bad configuration fails at startup, not on the first user request.
Summary
Microsoft Foundry provides Claude through an Azure resource, addressed by a resource name that must follow hostname rules. The Foundry client is created with that name, and it authenticates with either an API key from the environment or a Microsoft Entra ID identity. The most important rule is that the key never appears in code, and the configuration check enforces it. The next lesson covers how to supply credentials to all three platforms safely.