When you deploy a Claude model on Microsoft Foundry, the portal hands you two strings under the deployment's Details tab: the Target URI (your endpoint) and the Key. That key is a bearer credential — anyone who holds it can call your deployment and spend your tokens, with no per-user identity attached. The moment it lands in a source file, a .env checked into git, or a CI log, you have a standing exposure. Azure Key Vault, Azure's managed secret store, is the standard fix: the key lives in the vault, applications fetch it at runtime under their own identity, and every read is access-controlled and auditable.
First, ask whether you need a key at all
Foundry supports two authentication methods on the same endpoint: API keys and Microsoft Entra ID tokens. If your caller runs on Azure compute, managed identity with Entra ID removes the key entirely — nothing to store, rotate, or leak, and it is the only supported method for the gated Claude Mythos models anyway. Key Vault is the right pattern for the remainder: callers outside Azure, third-party tools that only speak API keys, or transitional architectures. Treat this article as the "when keys must exist" playbook.
Putting the key in, and getting it out
Store the key from the deployment's Details tab as a Key Vault secret (a sensible name: foundry-claude-api-key). From there, applications have two consumption patterns.
Pattern 1 — app-config references. Azure App Service and Azure Functions can populate an app setting from a Key Vault secret by reference: the setting's value points at the secret's URI, the platform resolves it at startup using the app's managed identity, and your code reads a plain environment variable. No secret string ever appears in your configuration files or deployment templates — the config holds only a pointer. The exact reference syntax and its behaviors (such as how updates propagate) are App Service platform features; check the current Azure App Service documentation when wiring it up.
Pattern 2 — fetch in code. Applications elsewhere use a Key Vault client library with their own credential to read the secret at startup, then construct the Claude client with it.
Either way, the last hop is identical, because the anthropic SDK auto-reads the ANTHROPIC_FOUNDRY_API_KEY and ANTHROPIC_FOUNDRY_RESOURCE environment variables — populate those and the client needs no arguments at all:
import os
from anthropic import AnthropicFoundry
# ANTHROPIC_FOUNDRY_API_KEY was resolved from Key Vault by the
# platform (app-config reference) — never written in code or .env.
client = AnthropicFoundry(
api_key=os.environ["ANTHROPIC_FOUNDRY_API_KEY"],
resource=os.environ["ANTHROPIC_FOUNDRY_RESOURCE"],
)grep your repo and find the key, the setup is wrong.Operating the vault well
Lock down reads. Grant secret-read access only to the identities that genuinely call Claude — per-application, not a blanket "all our apps" grant. The vault's audit trail then tells you exactly which identity read the key and when, which is invaluable during an incident.
Plan rotation before you need it. Rotation is: obtain a new key from the Foundry deployment, write it as a new version of the secret, and let consumers pick it up (a restart for reference-based apps, a re-fetch for code-based ones). Rehearse it once in staging so a suspected leak triggers a runbook, not a scramble. Also rotate on personnel and vendor changes, not only on incidents.
Keep secrets out of telemetry. Never log the key, and scrub it from error reports; the SDK never requires you to print it. If you suspect exposure, rotate first and investigate second.
One scope note: Key Vault protects the credential; it does nothing about who can reach the endpoint or what the key holder may do. Pair it with private endpoints for network isolation and prefer Entra-based auth wherever possible so RBAC applies per identity.
Where to go next
Eliminate keys where you can with managed identity, review Foundry API key basics, or start at the quickstart if you have not made a first call yet.