Add Azure AI Foundry support for Anthropic (Claude) models in AI Agent connector

[mathieu-stennier]

Summary

The AI Agent connector cannot connect to Anthropic Claude models deployed on Azure AI Foundry (Microsoft Foundry). Neither the Anthropic provider nor the Azure OpenAI provider produces a working configuration when targeting an Azure-hosted Claude endpoint.

This is a significant gap for enterprise customers who are required to access Claude models through Azure due to data residency, compliance, or procurement constraints.

---

Problem

Azure AI Foundry hosts Anthropic Claude models behind endpoints that use the native Anthropic Messages API, served at:

https://<resource-name>.services.ai.azure.com/anthropic/v1/messages

The Camunda AI Agent connector (built on langchain4j) offers several model providers, but none of them can correctly target this endpoint:

Attempt 1: Anthropic provider

The Anthropic provider in the connector uses langchain4j-anthropic, which builds an AnthropicChatModel with a configurable baseUrl. Setting the base URL to https://<resource>.services.ai.azure.com/anthropic partially works — the URL path and protocol (Messages API) are correct — but authentication fails.

Root cause: langchain4j-anthropic sends credentials via the x-api-key header, which is the standard for the direct Anthropic API. Azure AI Foundry may expect the key in a different header (api-key) or require Microsoft Entra ID bearer tokens. There is no way to configure this through the Camunda connector's properties panel. Additionally, Azure Foundry may enforce stricter validation on headers like anthropic-version.

Attempt 2: Azure OpenAI provider

The Azure OpenAI provider uses langchain4j-azure-open-ai, which targets the OpenAI Chat Completions API at paths like:

/openai/deployments/<name>/chat/completions

Root cause: Claude models on Azure Foundry do not expose an OpenAI-compatible chat completions endpoint. They only respond to the Anthropic Messages API (/anthropic/v1/messages). Requests sent via the OpenAI protocol return 404 - Resource not found.

Attempt 3: OpenAI Compatible provider

The OpenAI Compatible provider also targets the OpenAI Chat Completions protocol (/v1/chat/completions), which is equally incompatible with Azure Foundry's Anthropic endpoint. Result: 404.

Summary

Provider	API Protocol	URL Path	Auth Mechanism	Result
Anthropic	Anthropic Messages ✅	/v1/messages ✅	x-api-key ⚠️	Auth header mismatch
Azure OpenAI	OpenAI Chat Completions ❌	/chat/completions ❌	Azure SDK ✅	404 — wrong protocol
OpenAI Compatible	OpenAI Chat Completions ❌	/v1/chat/completions ❌	Configurable	404 — wrong protocol

---

Root Cause in langchain4j

langchain4j treats Anthropic and Azure OpenAI as completely separate integration modules:

• langchain4j-anthropic — speaks the Anthropic Messages API but has no awareness of Azure authentication patterns.
• langchain4j-azure-open-ai — supports Azure authentication (API key + Entra ID) but only speaks the OpenAI Chat Completions protocol.

There is no langchain4j-azure-anthropic module that combines the Anthropic Messages API protocol with Azure-specific authentication and endpoint patterns. This is the fundamental gap.

This is a known cross-ecosystem issue. The same incompatibility has been reported in:

• Roo Code #9940 — First-class Azure AI Foundry support in Anthropic provider
• Roo Code #9467 — Unable to use Anthropic via Foundry (401 / URL mangling)
• Continue #9009 — Anthropic provider fails with Azure AI Foundry endpoints
• Continue #9352 — Azure AI Foundry Anthropic models generate incorrect URLs
• LiteLLM #16811 — Anthropic Support on Azure AI Foundry
• Microsoft Q&A — Anthropic models via Azure AI Foundry not supported with third-party tools

---

Expected Behavior

Users should be able to select an Azure AI Foundry (Anthropic) provider (or similar) in the AI Agent connector configuration, providing:

• Resource endpoint — e.g. https://<resource-name>.services.ai.azure.com/anthropic
• Authentication — either:
  • API key (sent via the header Azure expects)
  • Microsoft Entra ID / Client credentials
• Deployment name — the Azure deployment name (used as the model parameter)

The connector should then communicate using the Anthropic Messages API protocol against the Azure Foundry endpoint.

---

Proposed Solution

Option A: New provider type in the connector (recommended)

Add an "Azure AI Foundry (Anthropic)" provider option to the AI Agent connector element template. This provider would:

1. Use the Anthropic Messages API protocol (request/response format).
2. Construct the endpoint URL as https://<resource>.services.ai.azure.com/anthropic/v1/messages.
3. Support Azure-style authentication:
   • API key via the api-key header.
   • Client credentials / Entra ID via bearer token in the Authorization header.
4. Pass the anthropic-version header as required by the Azure Foundry endpoint.
5. Use the Azure deployment name as the model parameter.

This could be implemented as a thin adapter within the connector-agentic-ai module that configures langchain4j-anthropic's AnthropicChatModel with:

• baseUrl set to the Azure endpoint.
• A custom HTTP client or interceptor that adjusts authentication headers for Azure.

Option B: Upstream langchain4j enhancement

Contribute or request a langchain4j-azure-anthropic integration module upstream that natively handles Azure Foundry Anthropic endpoints. The Camunda connector could then consume this module as a new provider.

Option C: Extend the existing Anthropic provider

Allow the existing Anthropic provider in the connector to accept:

• A custom base URL (already partially supported).
• A configurable authentication method (API key header name, or Entra ID credentials).
• Custom headers (e.g. anthropic-version).

This is the least disruptive change but may not cover all Azure authentication scenarios (e.g. Entra ID token refresh).

---

Environment

• Camunda version: 8.8+
• Connector: connector-agentic-ai
• langchain4j version: (as bundled with connector — currently based on 1.x beta)
• Azure AI Foundry: Claude models deployed via Global Standard deployment
• Models tested: Claude Sonnet 4.5, Claude Haiku 4.5

---

Additional Context

Azure AI Foundry is increasingly the only permitted path to Anthropic models for enterprise customers operating under Azure-first procurement policies or EU data residency requirements. Without this integration, these customers cannot use the Camunda AI Agent connector with Claude models at all.

The Azure Foundry Anthropic endpoint is documented by both Microsoft and Anthropic:

• Microsoft: Deploy and use Claude models in Microsoft Foundry
• Anthropic: Claude in Microsoft Foundry

[deng-leon]

FYI: @mathieu-stennier just had a discussion and this seems to be an issue not only for Azure AI Foundry Anthropic models, but also OpenAI models are more and more moving from /chat/completions to /responses API, hiding models like codex and features like reasoning effort behind this new API format.

[maff]

Folded into #7218 as the Claude-on-Microsoft-Foundry backend (#8060). Closing.