"Grounding" means tying a model's answers to trusted sources instead of its general training. On Azure, the muscle-memory pattern is wiring a deployment to Azure AI Search (the managed retrieval service) via an "on your data"-style integration. If you go looking for that pattern for Claude in Microsoft Foundry, you will not find it: Microsoft's Claude models documentation contains no mention of Azure AI Search, knowledge tools, or "on your data" integration for Claude deployments. The documented agent-side support is limited to the Microsoft Agent Framework being able to create agents that use Claude models, and building with the Claude Agent SDK. As with Vertex (a similar story), the precise claim is "not documented," not "prohibited" — but you cannot build a supported architecture on an undocumented integration.
What Foundry actually exposes for Claude
Microsoft's documented API surface for Claude in Foundry is the Anthropic Messages API itself — POST /v1/messages at https://{resource}.services.ai.azure.com/anthropic/v1/* — plus token counting. And the capabilities table is genuinely useful for grounding work: it lists "Citations: Ground Claude's responses in sources, including search_result content blocks," PDF support (base64 or URL), prompt caching, and the 1M-token context window. Per Microsoft's live page (updated June 2026), the Hosted-on-Azure Claude models — Opus 4.8, Sonnet 5, Haiku 4.5 — are GA, and those grounding-relevant capabilities carry no preview marks.
In other words: the grounding features Claude has everywhere are present on Foundry. What's absent is the Azure-native retrieval plumbing.
The BYO-retrieval pattern on Foundry
The working design is the same inversion as on Vertex: your code retrieves, Claude grounds. Nothing stops your retrieval layer from being Azure AI Search used directly by your application — you query the index yourself, then hand the results to Claude as search_result blocks with citations enabled:
from anthropic import AnthropicFoundry
client = AnthropicFoundry(api_key="...", resource="my-resource")
blocks = [{"type": "search_result", "source": d.url, "title": d.title,
"content": [{"type": "text", "text": d.text}],
"citations": {"enabled": True}} for d in my_search(query)]
msg = client.messages.create(
model="claude-sonnet-5", max_tokens=1024,
messages=[{"role": "user",
"content": blocks + [{"type": "text", "text": query}]}])
Claude's answer comes back with search_result_location citations pointing at your blocks — block-level granularity, so split content into paragraph-sized text blocks (mechanics in the search_result deep dive). For document-heavy grounding, citation-enabled document blocks and PDF support work too; large static corpora pair naturally with prompt caching via cache_control on the source blocks.
Which grounding features depend on the hosting mode
Claude in Foundry has two hosting options — Hosted on Azure (inference on Azure infrastructure; Opus 4.8, Sonnet 5, Haiku 4.5) and Hosted on Anthropic (all Foundry Claude models) — and several retrieval-adjacent features split along that line. On a Hosted-on-Azure deployment these return a 400 error:
| Feature | Hosted on Azure | Hosted on Anthropic |
|---|---|---|
| Citations, search_result blocks, PDF, prompt caching, 1M context | ✓ | ✓ |
| Server-side tools (web search, web fetch, code execution, tool search) | ✗ (400) | ✓ |
| Files API (beta) | ✗ (400) | ✓ |
| MCP connector, Agent Skills, structured outputs, programmatic tool calling | ✗ (400) | ✓ |
So the core BYO grounding pattern runs on either hosting mode, but live grounding — Anthropic's web search and web fetch tools — and Files API-based document reuse require Hosted on Anthropic. The Message Batches API is unavailable on Foundry in both modes. Details on the split are in Foundry hosting modes and Foundry feature parity.
Where to go next
Set up the client via the Foundry SDK guide, and see the citation-grounding pattern for the end-to-end design this article sketches.