# Self-hosted Claude Managed Agents: the AKS and Foundry path

Anthropic's self-hosted Claude Managed Agents beta, opened 12 November 2026, puts the agent server, PostgreSQL session store and sandboxes on your own AKS cluster, with model calls routed to Microsoft Foundry under an Entra ID identity. Here is what you run, which hosted features disappear, why AKS accepts only publicInternet egress, how Foundry CCU billing replaces the $0.08 session-hour fee, and why the residency win covers storage but not inference.

- Published: 2026-11-14 · Category: AI & Cloud Infrastructure · Tags: Claude Managed Agents, Self-hosted, Microsoft Foundry, AKS, Pod Sandboxing, Entra ID, AI Agents, Data Residency, Anthropic, Azure
- Author: Technspire AB, Stockholm (https://technspire.com)
- Canonical: https://technspire.com/en/blog/self-hosted-claude-managed-agents-aks-foundry-path

On 12 November 2026 Anthropic opened a private beta of self-hosted Claude Managed Agents. The parts that until now ran only at Anthropic, the API server, the agent loop, the PostgreSQL store for sessions and the sandboxes where the agent's shell runs, now ship as a release archive with a Docker Compose stack and two Helm charts. Model calls can go to Microsoft Foundry, authenticated with a Foundry key or Microsoft Entra ID. For an Azure team this closes a gap open since Claude arrived in Foundry: Anthropic's own Foundry documentation lists Claude Managed Agents among the features not supported there. The self-hosted server is the first supported way to run Anthropic's agent harness against inference billed on your Azure invoice.

Access is by request through your Anthropic account team. The documentation is public and detailed enough to plan an AKS deployment before you have the archive.

## What ships in the archive

Self-hosted sandboxes, available since the spring, moved tool execution to your infrastructure while Anthropic kept running the service. The November release moves the service too. The same API is served, so the Anthropic SDKs and the ant CLI work against your server once you point ANTHROPIC_BASE_URL at it.

| Component | What it does | On AKS |
| --- | --- | --- |
| cma-server | Serves the API, runs the agent loop, calls the inference provider. Never runs the agent's shell. | Helm chart cma-server, two replicas behind a Service in namespace cma-server |
| Database | Agents, sessions and session history. Without it the server keeps data in memory and a restart erases it. | PostgreSQL 16 or later, outside both charts. Azure Database for PostgreSQL flexible server offers 16 through 18. |
| Dispatcher and sandboxes | Polls the server for work and gives each session its own sandbox pod, where a worker runs bash and file tools. | Helm chart cma-sandboxes in namespace cma, on a Pod Sandboxing node pool |
| Console | A web page on the server's address where people sign in through your OpenID Connect provider. | Entra ID as the issuer; groups map to developer or user roles |

Three credentials hold it together. The **server API key** is what your applications send, in the role a Claude API key plays with the hosted service. The **inference credential** is held by the server alone. The **environment key** is held by the workers that poll for sandbox work, and it can read events and post tool results in every session of its environment. So each session runs in a sandbox of its own with the environment key kept out of it. The charts do this; a hand-rolled worker must do the same. The Compose stack is for development only: plain HTTP, port 8400 on loopback, agent tools in containers on the host.

## Pointing the server at Foundry

The inference provider is a server setting with four values besides the default Claude API, foundry among them. Under any of them the server needs no Claude API key. Agents keep naming models by their Claude API IDs and the server translates, so an agent definition written against the hosted service runs unchanged.

```
inference:
  provider: foundry
  foundry:
    resource: my-foundry-resource   # the <resource> in <resource>.services.ai.azure.com
  #model_id_overrides:
  #  claude-opus-5-5: team-a-opus    # only if your deployment name differs
```

Authentication has two paths. Set ANTHROPIC_FOUNDRY_API_KEY and the server uses the Foundry key. Leave it unset and the server obtains an Entra ID token for a service principal, a managed identity, or a workload identity on AKS. The identity needs an Azure role on the Foundry resource that allows calls to its model deployments. On Kubernetes the server chart passes no Azure variables at all; you create a service account with the workload identity annotation, set server.serviceAccountName to it, and on AKS also set server.azureWorkloadIdentity to true. No key ever sits in a Secret.

A Foundry request names a deployment, and the server sends the Claude model ID as the deployment name; map it with model_id_overrides if your platform team chose another name. Which models you can reach is then a Foundry question with a wrinkle. Hosted on Azure covers Opus 5.5, Opus 5, Opus 4.8, Sonnet 5.5, Sonnet 5, Haiku 5.5 and Haiku 4.5. The Fable 5.x and Mythos 5.x models exist in Foundry only as Hosted on Anthropic, and Mythos accepts Entra ID authentication only. Haiku 4.5 retires on Foundry tomorrow, 15 November, as covered in [the retirement plan](/en/blog/foundry-retires-haiku-4-5-and-o-series-your-10-day-plan).

Three provider-dependent behaviours matter under foundry:

- **Web tools work.** web_search and web_fetch are offered to the model under anthropic, vertex and foundry, but not bedrock. They stay off until you enable web_tools in the server settings, and Azure-hosted deployments support only the basic tool versions.
- **Fast mode is Opus 5.5 only.** Under foundry the server's model catalog lists Claude Opus 5.5 alone, matching the pricing page.
- **inference_geo is refused.** Under foundry, geography is a property of the Foundry deployment type, not the agent.

## What AKS needs, and the one mode it accepts

Anthropic's Kubernetes walkthrough is written for GKE with gVisor nodes. AKS is a supported platform value with its own prerequisites: Kubernetes 1.30 or later, the upstream Agent Sandbox controller with its extensions, and a network plugin that enforces NetworkPolicy, named (cilium, calico or azure) in aks.networkPolicy.

Isolation on AKS comes from Pod Sandboxing, which runs each pod in a lightweight VM with its own guest kernel using Kata Containers on Hyper-V. The constraints are Microsoft's and they shape the node pool:

- Azure Linux only, on Generation 2 VM sizes with nested virtualization such as the Dsv3 series. No Arm64, no FIPS, no Trusted Launch on that pool.
- Microsoft Defender for Containers does not assess Kata runtime pods, so container-security evidence for the sandbox pool comes from elsewhere.
- Each Kata pod VM gets a fixed memory size from the pod's memory limit, defaulting to 512 MiB, and fractional CPU limits round up to a whole vCPU.

Label the pool cma.anthropic.com/sandbox-node=true and taint it with the same key. Then the values file:

```
platform: aks
aks:
  networkPolicy: cilium          # or calico, or azure
image:
  registry: myregistry.azurecr.io/cma
egress:
  mode: publicInternet           # the only mode the chart accepts on AKS
  clusterCIDRs:
    - 203.0.113.10/32            # the cluster's API endpoint
  cmaServer:
    pods:
      namespace: cma-server
      matchLabels:
        anthropic.com/role: server
    port: 8400
```

The egress line is the item to flag in your design review. The chart has three egress modes: closed, which lets sandboxes reach only your servers and the dispatcher; publicInternet; and gateway, which routes sandbox traffic through Anthropic's egress proxy to hosts you list and is also how environment_variable vault credentials get injected. On AKS, publicInternet is the only mode the chart accepts today. The sandbox pool can reach the internet, private ranges are blocked by the chart's NetworkPolicy, and the allowlisted-hosts control the launch article promotes is, for now, something you build with your own egress firewall. Anthropic's note is blunt: test the chart on your cluster before agents do real work on it.

Two operational facts round out the picture. Each session gets a 10 GiB volume for /workspace that survives the pod; set dispatcher.retentionDays or volumes accumulate forever. And the server speaks plain HTTP on 8400, so TLS termination sits in front of it, with the ingress requirements listed in the checklist below.

## What you lose against the hosted service, and what you gain

Nothing is copied from the hosted service; agents and vault credentials are recreated on your server. Beyond that, Anthropic's differences page reads like a migration punch list.

| Hosted feature | On your server | Workaround |
| --- | --- | --- |
| Cloud environments | 400 error; only self_hosted exists | Deploy workers for every environment |
| Files API and file session resources | Rejected; /v1/files does not exist | Stage files in the worker's working directory; send images and PDFs as base64 |
| mcp_oauth vault credentials | Rejected; no OAuth refresh flow | static_bearer credentials, rotated by you |
| Prebuilt docx, pdf, pptx, xlsx skills | Agent rejected | Upload them from the public skills repository as custom skills |
| Scheduled deployments, dreams | No routes | Your own scheduler, such as a CronJob. Dreams have no replacement. |
| Dynamic multiagent workflows, advisor | 400 error | Coordinator type with 1 to 20 predefined subagents |
| MCP servers | Only hosts in mcp.allowed_hostnames; exact match, empty by default | List each host. Private MCP servers need no tunnel. |
| MCP tool results | Cut at 100 KiB and the rest is lost | Raise mcp.max_result_bytes |

Four things exist only on your server, and an Azure identity team will care about all of them. Single sign-on through Entra ID, with roles derived from token groups. A secret manager of your choice for new vault credentials, so Key Vault can hold them instead of the server's database. Agent identity, where the server signs a short-lived token for each MCP call and your MCP server or gateway checks it against public keys you publish. And the inference provider choice itself. Agent identity is the practical answer to the question raised in [the agent guardrails post](/en/blog/six-agents-one-350-refund-your-azure-agent-guardrails): how does a downstream API know which agent, acting for which caller, is on the line.

## The cost picture

The hosted service bills tokens at list price plus a session runtime fee of $0.08 per session-hour, metered only while a session's status is running. Anthropic's worked example is a one-hour Opus 5.5 coding session with 50,000 input and 15,000 output tokens: $0.20 of input, $0.30 of output and $0.08 of runtime, $0.58 in total. Cache reads at 0.05x the input price drop it further.

Self-hosted removes the runtime line and replaces it with three others. First, Anthropic publishes no price for the server software. The pricing page says to contact your account team, and the licence that took effect on 12 November grants the code royalty-free but ties commercial terms to your model agreement. Budget for a negotiation, not a SKU. Second, AKS compute. A Pod Sandboxing pool costs the same whether sessions run or not, and because Kata rounds fractional CPU up to a whole vCPU and fixes VM memory from the pod limit, sandbox sizing is the lever. Third, the tokens, now metered through Foundry.

Claude in Foundry bills through Azure Marketplace in Claude Consumption Units at $0.01 per CCU. Anthropic rates your tokens at its standard per-model prices, applies any negotiated discount, converts to CCUs and reports hourly. The rates match the Claude API: Opus 5.5 at $4 and $20 per million input and output tokens, Sonnet 5.5 at $2 and $10, Haiku 5.5 at $0.10 and $0.50 for prompts up to 100,000 tokens. US Data Zone Standard adds a 1.1x multiplier. There is no Foundry equivalent of the session-hour fee; the compute is yours.

The comparison an Azure architect will be asked for is against Foundry hosted agents, Microsoft's own containerised runtime. Hosted agents bill container compute per vCPU-hour and GiB-hour during active sessions, in three sizes from 0.5 vCPU and 1 GiB to 2 vCPU and 4 GiB. The public pricing page shows the rates as placeholders, so a like-for-like number is not available in print. The structural difference is clear enough: pay-per-active-session with no cluster, against a cluster you pay for continuously in exchange for Anthropic's harness and your own storage.

## Three ways to run an agent harness on Azure

|  | Foundry hosted agents | Hosted Claude Managed Agents with self-hosted sandboxes | Self-hosted Claude Managed Agents |
| --- | --- | --- | --- |
| Who writes the agent loop | You, in any framework (Agent Framework, LangGraph, custom) | Anthropic | Anthropic |
| Where the harness runs | Microsoft-managed VM-isolated sandbox per session, Sweden Central available | Anthropic | Your AKS cluster |
| Where transcripts live | Foundry conversation store | Anthropic, until you delete them; not ZDR-eligible | Your PostgreSQL |
| Model choice | Any Foundry catalog model | Claude via Claude API, AWS or Google Cloud; not Foundry | Claude via Claude API, Bedrock, Google Cloud, Foundry or your gateway |
| Inference billing | Azure | Anthropic or marketplace | Azure Marketplace CCUs when provider is foundry |
| Runtime billing | vCPU-hour and GiB-hour, active sessions | $0.08 per session-hour plus your sandbox hosts | Your cluster, plus negotiated software terms |
| Status | Available | Beta | Private beta |

The decision rule is short. If you want Anthropic's harness and your compliance team needs transcripts on infrastructure you own, the self-hosted server is the only column that gives you both. If you are happy to write the loop yourself, Foundry hosted agents are simpler to run and already live in Sweden Central. The middle column is for teams that need tool execution inside their network but can accept transcripts at Anthropic.

## The Swedish and EU angle

**Storage residency is solved. Inference geography is not.** With the whole stack in Sweden Central, every byte of session history and every OpenTelemetry trace lands where you put it, with the retention you set. That is a clean answer for the storage rows of a GDPR Article 30 record. The model call is a different row. Claude deployments in Foundry come in Global Standard and US Data Zone Standard types; there is no EU data zone for Claude. For deployments hosted on Azure, Anthropic states that prompts and completions remain within Azure and only usage metadata and safety-flagged content egress to Anthropic. Within Azure is not within the EU. Write the record accordingly: an Anthropic-operated service on Azure infrastructure, global routing, Anthropic as independent processor under its data use terms.

**Zero data retention depends on the provider.** The hosted Managed Agents service is excluded from ZDR because Anthropic stores transcripts. The self-hosted server is the exception: you store them, so your ZDR arrangement covers the model calls when the Claude API is the provider. Under foundry, retention follows the Marketplace terms, and Microsoft's troubleshooting table notes that Anthropic-designated Covered Models require data retention and reject requests from subscriptions with ZDR enabled. Check your model list against that before promising ZDR in a procurement answer.

**One deployment per trust level.** Environments in one deployment do not keep trust levels apart: the server API key reaches every environment, and any caller with a role can run sessions in all of them. Each tenant, and each trust boundary within a tenant, needs its own deployment with its own database. For a shared service centre serving several kommuner, or a group IT function with regulated and unregulated subsidiaries, that multiplies namespaces and PostgreSQL servers. Plan it before the first helm install.

**The audit trail is yours to build.** The server emits traces and metrics only when the standard OpenTelemetry variables point somewhere. Point them at the Azure Monitor exporter and the session audit lands in Application Insights, the path described in [the Claude OTel traces post](/en/blog/claude-opentelemetry-traces-azure-monitor-foundry-gap). For an AI Act quality management system built against [EN 18286](/en/blog/en-18286-official-journal-ai-act-qms-plan), a per-session event log whose retention you control is a concrete artefact to point at.

**What still leaves the building.** Anthropic has no remote access to the server or its log, and issues none of the credentials it accepts. The licence does require that observability signals are not blocked or altered. On the wire, that amounts to a User-Agent naming the server version on Claude API calls and a fixed cma-server label in the metadata.user_id field on Foundry calls. Neither carries content. If your egress proxy rewrites metadata fields, every model call fails, so test that path early. For organisations that followed [Regeringskansliet's lead](/en/blog/regeringskansliet-blocked-chatgpt-claude-kept-copilot-azure-playbook) in blocking consumer AI tools while keeping Azure-contracted services, a harness in your subscription with inference billed through Azure Marketplace sits inside the posture they chose.

## Checklist before you ask for the archive

- **1. Confirm the model path.** Check each Claude model your agents need against the Foundry hosting table. Fable 5.x is Hosted on Anthropic only; Mythos needs Entra ID.
- **2. Decide the identity.** A user-assigned managed identity with workload identity federation on AKS, a role on the Foundry resource that permits model deployment calls, and ANTHROPIC_FOUNDRY_API_KEY left unset.
- **3. Build the sandbox pool.** Azure Linux on a Gen2 nested-virtualization size with the KataVmIsolation runtime, then label and taint it with cma.anthropic.com/sandbox-node=true.
- **4. Compensate for publicInternet egress.** If sandboxes must not reach arbitrary hosts, put an Azure Firewall allowlist in front of the pool and document it as the control.
- **5. Provision PostgreSQL in region.** Flexible server, version 16 or later, private endpoint, sslmode=require. Keep the credentials encryption key outside the cluster; a restored database is useless without it.
- **6. Front the server with TLS.** 32 MiB bodies, 2-minute default and 10-minute Git read timeouts, no POST retries, no caching, readiness on /cma-server/readyz.
- **7. Write the allowlists.** Every MCP host in mcp.allowed_hostnames, every Git host and push ref, web_tools enabled only if agents need it.
- **8. Count deployments and get the price.** One deployment per tenant and trust level, and the self-hosted commercial terms in writing alongside the archive.

## Conclusion

Self-hosted Claude Managed Agents gives Azure teams something they could not have last week: Anthropic's agent harness, transcripts in their own PostgreSQL, Claude called through Foundry under an Entra ID identity. The AKS path is real but narrower than the GKE path, with Kata rather than gVisor, publicInternet as the only egress mode, and a Defender gap on the sandbox pool. The residency win is storage, not inference, and the software price is a conversation rather than a number. Stand up one trust level in Sweden Central, measure it against Foundry hosted agents on the same workload, and have the Article 30 wording ready before anyone asks.

## Sources

- [Anthropic: Self-hosted Claude Managed Agents (12 November 2026)](https://claude.com/resources/articles/self-hosted-claude-managed-agents)
- [Claude Platform release notes, 12 November 2026 entry](https://platform.claude.com/docs/en/release-notes/overview)
- [Claude Platform docs: Self-hosted Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/self-hosted)
- [Claude Platform docs: Inference provider (Microsoft Foundry section)](https://platform.claude.com/docs/en/managed-agents/self-hosted/inference-provider)
- [Claude Platform docs: Deploy on Kubernetes (AKS notes)](https://platform.claude.com/docs/en/managed-agents/self-hosted/kubernetes)
- [Claude Platform docs: Differences from the hosted service](https://platform.claude.com/docs/en/managed-agents/self-hosted/differences)
- [Claude Platform docs: Data and access in self-hosted Claude Managed Agents](https://platform.claude.com/docs/en/managed-agents/self-hosted-data-and-access)
- [Claude Platform docs: Claude in Microsoft Foundry (hosting options, unsupported features)](https://platform.claude.com/docs/en/build-with-claude/claude-in-microsoft-foundry)
- [Claude Platform docs: Pricing (Managed Agents, Foundry CCUs, inference geography)](https://platform.claude.com/docs/en/about-claude/pricing)
- [Anthropic: Software License Agreement, Claude Managed Agents Server](https://www.anthropic.com/legal/self-hosted-managed-agents-license)
- [Microsoft Learn: Hosted agents in Foundry Agent Service](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/hosted-agents)
- [Azure: Foundry Agent Service pricing](https://azure.microsoft.com/en-us/pricing/details/foundry-agent-service/)
- [Microsoft Learn: Pod sandboxing with Azure Kubernetes Service](https://learn.microsoft.com/en-us/azure/aks/use-pod-sandboxing)
- [Microsoft Learn: Deploy and use Claude models in Microsoft Foundry](https://learn.microsoft.com/en-us/azure/foundry/foundry-models/how-to/use-foundry-models-claude)
- [Microsoft Learn: Supported PostgreSQL versions in Azure Database for PostgreSQL](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/concepts-supported-versions)

---

Technspire AB builds AI agents, Azure OpenAI solutions, and production web platforms for Swedish and EU enterprises. Book a call: https://calendly.com/technspire · hello@technspire.com · More articles: https://technspire.com/en/blog · Site overview for agents: https://technspire.com/llms.txt