Azure OpenAI Managed Identity statt API-Keys

Ein API-Key für Azure OpenAI landet fast immer an drei Stellen, an denen er nichts verloren hat: in einer .env-Datei, die irgendwann versehentlich committet wird, in einem CI/CD-Secret, das niemand mehr rotiert, weil niemand mehr weiß, welche drei Anwendungen ihn benutzen, und in einem Support-Ticket, in dem ein Entwickler ihn zur Fehlersuche „nur kurz” in den Chat kopiert. Keiner dieser drei Fälle ist böswillig. Genau das macht sie gefährlich.

Microsoft selbst formuliert die Konsequenz unmissverständlich: Für Produktivworkloads soll Microsoft Entra ID verwendet werden, nicht der API-Key. Technisch heißt das für Azure-gehostete Anwendungen meist Azure OpenAI Managed Identity - eine von Azure automatisch verwaltete Entra-ID-Identität, die ganz ohne gespeichertes Secret auskommt. Dieser Artikel zeigt, warum API-Keys für Azure OpenAI und Microsoft Foundry ein vermeidbares Risiko sind, wie Managed Identity technisch funktioniert, welche RBAC-Rolle Sie konkret zuweisen müssen - und das ist komplizierter, als die meisten Tutorials suggerieren - , wie die Umstellung im Code aussieht und wo diese Lösung an ihre Grenzen stößt.

Warum API-Keys für Azure-KI-Dienste ein Risiko sind

Microsoft beschreibt in der Foundry-Dokumentation zu Authentifizierung und Autorisierung API-Keys nüchtern als das, was sie sind: statische Secrets, die auf eine ganze Ressource skaliert sind. Sie sind einfach zu benutzen, sprachunabhängig und brauchen keinen Token-Abruf - genau deshalb landen sie so oft im Code. Die Kehrseite steht in derselben Dokumentation, als Einschränkung formuliert: Ein API-Key kann keine Benutzeridentität ausdrücken, lässt sich nur schwer granular scopen und ist schwer zu auditieren. Für Produktivworkloads in Unternehmen sei er generell nicht geeignet und werde von Microsoft nicht empfohlen.

Was das praktisch bedeutet, zeigt die Feature-Vergleichstabelle derselben Seite in aller Deutlichkeit. Bei „Least privilege mit Built-in- und Custom-Rollen” steht für den API-Key ein klares Nein - Keys sind pro Ressource alles oder nichts. Bei „Per-Request-Nutzerzuordnung” ebenfalls Nein: Ein Token enthält Tenant- und Objekt-ID des aufrufenden Prinzipals, ein Key enthält gar nichts davon. Und beim Widerruf ist der Unterschied besonders greifbar: Einen API-Key widerrufen Sie, indem Sie ihn rotieren - was jede Anwendung betrifft, die ihn (mit)benutzt. Eine Entra-ID-Berechtigung widerrufen Sie, indem Sie die Rollenzuweisung entfernen oder den Prinzipal deaktivieren - präzise, für genau eine Identität, ohne alle anderen Aufrufer zu unterbrechen.

Dazu kommt ein Punkt, der in Sicherheitsdiskussionen oft untergeht: Manche neueren Foundry-Funktionen bieten den API-Key gar nicht mehr als Option an. Der Agents Service, Evaluations und die Toolbox-Funktion sind laut Feature-Support-Matrix ausschließlich über Microsoft Entra ID nutzbar - der API-Key funktioniert dort schlicht nicht. Wer heute noch komplett auf Keys setzt, baut sich also bereits eine technische Sackgasse für Funktionen, die er morgen nutzen möchte.

Managed Identity: System-assigned oder User-assigned

Microsoft Entra ID ist die Identitätsplattform; jeder tokenbasierte Aufruf läuft über sie, unabhängig davon, welche Identität Sie verwenden. Eine Managed Identity ist eine bestimmte Art von Entra-Identität: Azure legt sie an, bindet sie an eine Azure-Ressource - etwa eine virtuelle Maschine oder eine Web-App - und rotiert ihre Credentials selbst. Es gibt kein Secret, das Sie speichern oder rotieren müssten; Zugriff auf die zugrunde liegenden Credentials haben Sie als Entwickler gar nicht.

Es gibt zwei Varianten, und der Unterschied liegt vor allem im Lebenszyklus:

Eigenschaft	System-assigned	User-assigned
Erstellung	Direkt als Teil einer Azure-Ressource	Als eigenständige Azure-Ressource
Lebenszyklus	An die Ressource gebunden - wird die Ressource gelöscht, verschwindet auch die Identität	Unabhängig - muss explizit gelöscht werden
Nutzung durch mehrere Ressourcen	Nein, genau eine Ressource	Ja, dieselbe Identität kann mehreren Ressourcen zugewiesen werden
Typischer Einsatzfall	Eine Workload auf genau einer Ressource	Mehrere Ressourcen, die dieselbe Berechtigung teilen sollen, oder Berechtigungen, die vor dem Anlegen der eigentlichen Ressource vergeben werden müssen

Microsoft empfiehlt User-assigned Managed Identities explizit als bevorzugten Typ für Microsoft-Dienste, weil sie unabhängig vom Compute bereitgestellt werden und mehreren Ressourcen zugewiesen werden können. In der Praxis heißt das: Wenn drei Azure Functions, eine Container-App und ein AKS-Workload alle auf dieselbe Foundry-Ressource zugreifen sollen, ist eine gemeinsame User-assigned Identity einfacher zu verwalten als drei separate System-assigned Identities mit jeweils eigenen Rollenzuweisungen. Für eine einzelne, klar abgegrenzte Workload auf genau einer Ressource ist System-assigned dagegen oft die schlankere Wahl - sie verschwindet automatisch, wenn die Ressource gelöscht wird, und hinterlässt keine verwaisten Identitäten.

Technisch funktioniert Managed Identity über dieselbe Mechanik für alle unterstützten Compute-Ressourcen: Azure App Service und Azure Functions (Ressourcentyp Microsoft.Web/sites), Azure Container Apps (Microsoft.App/containerApps), virtuelle Maschinen (Microsoft.Compute/virtualMachines) und Azure Kubernetes Service (Microsoft.ContainerService/managedClusters) unterstützen laut der Entra-ID-Dokumentation zu Managed Identities alle sowohl System- als auch User-assigned Identitäten. Der Code, der die Identität nutzt, unterscheidet sich zwischen diesen Hosts kaum - dazu gleich mehr.

Cognitive Services User oder Cognitive Services OpenAI User: die richtige RBAC-Rolle finden

Hier liegt der Teil, an dem viele Rollouts hängen bleiben, weil die Rollenlandschaft in Azure OpenAI und Foundry über die Zeit gewachsen ist und mehrere, ähnlich benannte Rollen existieren.

Für den klassischen Azure-OpenAI-Endpunkt (https://<resource>.openai.azure.com) gibt es vier relevante eingebaute Rollen. Cognitive Services OpenAI User erlaubt Inferenz-API-Aufrufe mit Microsoft Entra ID sowie das Ansehen von Ressource, Deployments und Modellen - aber weder das Anlegen von Deployments noch den Zugriff auf Keys. Cognitive Services OpenAI Contributor erweitert das um Fine-Tuning, Deployment-Verwaltung und Zugriff auf gespeicherte Completions. Cognitive Services Contributor wirkt auf den ersten Blick mächtiger - er darf Ressourcen anlegen und Keys einsehen und regenerieren - , erlaubt aber laut der offiziellen Rollentabelle keine Inferenz-API-Aufrufe mit Microsoft Entra ID. Und Cognitive Services Usages Reader ist eine reine Kontingent-Anzeigerolle, die nur auf Subscription-Ebene existiert.

Das ist der Punkt, an dem Fehlkonfigurationen entstehen: Wer einem Deployment-Team die Owner- oder Contributor-Rolle gibt, weil „die sollen doch alles dürfen”, verschafft ihm damit noch keinen Entra-ID-Inferenzzugriff. Die Berechtigungsübersicht der klassischen Azure-OpenAI-Dokumentation hält das ausdrücklich fest: Für Cognitive Services Contributor steht in der Spalte „Make inference API calls with Microsoft Entra ID” ein klares Nein - trotz Ressourcen-, Deployment- und Key-Verwaltungsrechten. Für Inferenzaufrufe mit Microsoft Entra ID ist stattdessen explizit die Rolle Cognitive Services OpenAI User (oder eine höhere Rolle mit denselben Berechtigungen) nötig.

Für den neuen, vereinheitlichten Foundry-Models-Endpunkt (https://<resource>.services.ai.azure.com), über den neben Azure-OpenAI-Modellen auch Drittanbietermodelle wie Claude oder DeepSeek laufen, gilt eine andere Standardrolle: Cognitive Services User. Diese Rolle ist älter und breiter als die OpenAI-spezifischen Rollen - sie deckt alle Cognitive-Services-Datenebenen ab. Die Troubleshooting-Dokumentation zur Entra-ID-Konfiguration von Foundry-Modellen weist ausdrücklich darauf hin: „Cognitive Services OpenAI User grants only access to OpenAI models” - für Claude-Modelle über die Anthropic-Messages-API in Foundry führt an Cognitive Services User kein Weg vorbei. Wer bereits Azure OpenAI mit Entra ID abgesichert hat und dieselbe Rollenzuweisung unverändert für ein Claude-Deployment in Microsoft Foundry übernimmt, bekommt an dieser Stelle einen 403 - nicht weil etwas falsch konfiguriert ist, sondern weil es die falsche Rolle ist.

Für die Rollenzuweisung selbst braucht der Ausführende Microsoft.Authorization/roleAssignments/write- und -/delete-Berechtigungen, typischerweise über die Rolle Owner oder User Access Administrator auf der Zielebene. Zugewiesen wird über Access Control (IAM) am Foundry- bzw. Azure-OpenAI-Resource, per Azure CLI:

az role assignment create \
  --assignee-object-id $OBJECT_ID \
  --role "Cognitive Services User" \
  --scope $RESOURCE_ID

Rollenzuweisungen können laut Microsoft bis zu fünf Minuten brauchen, bis sie greifen - Änderungen an der Mitgliedschaft einer Security Group dagegen wirken sofort. Deshalb empfiehlt Microsoft, Rollen möglichst an Security Groups statt an einzelne Prinzipale zu vergeben: leichter zu pflegen, sofort wirksam bei Personalwechseln.

Eine letzte Unterscheidung ist für Admins wichtig: Control-Plane- und Data-Plane-Operationen laufen über unterschiedliche Token-Scopes. Inferenzaufrufe (Data Plane) brauchen einen Token mit Scope https://ai.azure.com/.default, Management-Operationen wie das Anlegen von Deployments oder das Auflisten verfügbarer Modelle (Control Plane) brauchen https://management.azure.com/.default - ein Token für den einen Scope funktioniert nicht beim anderen. Entsprechend brauchen Sie für Control-Plane-Aufgaben eine andere Rolle (etwa Cognitive Services Contributor) als für Data-Plane-Inferenz.

Von API-Key zu Managed Identity: die Umstellung im Code

Der eigentliche Code-Umbau ist überschaubarer, als die Rollenfrage vermuten lässt - vorausgesetzt, die richtige Rolle ist zugewiesen. Zentral ist die Klasse DefaultAzureCredential aus der azure-identity-Bibliothek (in praktisch jeder Azure-SDK-Sprache verfügbar: Python,.NET, JavaScript, Java). Sie probiert eine feste Kette von Credential-Quellen der Reihe nach durch - zuerst Umgebungsvariablen für einen Service Principal, dann Workload Identity, dann eine Managed Identity, danach verschiedene lokal angemeldete Entwickler-Tools (Visual Studio, VS Code, Azure CLI, Azure PowerShell, Azure Developer CLI) - und verwendet die erste, die einen Token liefert.

Das ist der Grund, warum derselbe Code lokal und in Azure funktioniert, ohne dass Sie unterscheiden müssen: Auf Ihrem Entwicklungsrechner greift DefaultAzureCredential auf Ihre az login-Sitzung zurück, auf einer Azure-VM oder in einer Container-App findet sie automatisch die dort aktivierte Managed Identity.

from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(),
    "https://ai.azure.com/.default"
)

client = OpenAI(
    base_url="https://<resource>.openai.azure.com/openai/v1/",
    api_key=token_provider,   # Name aus Kompatibilitätsgründen beibehalten
)

response = client.chat.completions.create(
    model="<deployment-name>",
    messages=[{"role": "user", "content": "Hallo"}],
)

Dass hier weiterhin ein Parameter namens api_key befüllt wird, verwirrt fast jeden beim ersten Mal. Die offizielle Dokumentation adressiert das direkt: api_key akzeptiert sowohl einen String als auch ein Callable. Übergeben Sie das Callable, ruft es der Client vor jedem Request auf, holt einen aktuellen Entra-ID-Token und sendet ihn als Bearer-Token im Authorization-Header - es wird kein Key erzeugt, gespeichert oder übertragen. get_bearer_token_provider übernimmt dabei Caching und Refresh, Sie müssen die Token-Lebensdauer nicht selbst verwalten.

Für die Anthropic-Messages-API von Claude-Modellen in Foundry gilt exakt dasselbe Muster, nur mit dem AnthropicFoundry-Client statt der OpenAI-SDK-Klasse:

from anthropic import AnthropicFoundry
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(), "https://ai.azure.com/.default"
)

client = AnthropicFoundry(
    resource="<resource-name>",
    azure_ad_token_provider=token_provider,
)

message = client.messages.create(
    model="<deployment-name>",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hallo"}],
)

Läuft der Code auf einer Ressource mit mehreren User-assigned Identities, muss der Code wissen, welche gemeint ist - sonst weiß auch DefaultAzureCredential es nicht. Entweder Sie übergeben die Client-ID explizit an ManagedIdentityCredential, oder Sie setzen die Umgebungsvariable AZURE_CLIENT_ID auf dem Host; DefaultAzureCredential liest sie automatisch aus.

Für Produktivumgebungen rät Microsoft ausdrücklich davon ab, die volle, „opinionated” Kette von DefaultAzureCredential unverändert zu belassen. Empfohlen wird stattdessen eine deterministische Lösung: entweder direkt ManagedIdentityCredential verwenden oder eine schlanke ChainedTokenCredential, die exakt auf die Zielumgebung zugeschnitten ist - etwa Managed Identity in Produktion und eine bestimmte Entwickler-Credential nur für lokale Umgebungen. Der Grund ist Vorhersagbarkeit: Wenn eine von neun möglichen Credential-Quellen in der Standardkette unerwartet greift, ist das schwerer zu debuggen als ein Fehlschlag mit klarer Fehlermeldung.

API-Keys deaktivieren: der letzte Schritt

Solange der Key-basierte Zugriff technisch weiter möglich ist, bleibt er ein Risiko - unabhängig davon, wie viele Anwendungen bereits auf Managed Identity umgestellt sind. Microsoft bietet dafür eine explizite Ressourceneinstellung, disableLocalAuth, per PowerShell:

Set-AzCognitiveServicesAccount -ResourceGroupName "<resource-group>" -Name "<resource-name>" -DisableLocalAuth $true

… oder als Bicep-/ARM-Property beim Deployment. Wer das organisationsweit erzwingen will, statt es Ressource für Ressource manuell zu setzen, kann die eingebaute Azure Policy „Foundry Tools resources should have key access disabled (disable local authentication)” auf Subscription- oder Resource-Group-Ebene zuweisen - als Audit- oder Deny-Regel. Das lässt sich mit derselben Policy-Governance kombinieren, die auch für Deployment-Typen sinnvoll ist.

Ein ehrlicher Hinweis gehört dazu, den viele Anleitungen weglassen: Das Deaktivieren wirkt nicht sofort. Die Änderung ist auf der Control-Plane-Ebene sofort sichtbar, aber das vorgeschaltete Gateway, das die Authentifizierung tatsächlich durchsetzt, kann laut Microsoft-Dokumentation noch länger zwischengespeicherte Keys akzeptieren - die Propagation dauert typischerweise wenige Minuten, kann je nach Region, Last und Gateway-Cache-Status aber auch mehrere Stunden in Anspruch nehmen. Wer Keys aus Sicherheitsgründen sofort sperren muss, sollte sich nicht allein auf disableLocalAuth verlassen, sondern zusätzlich die konkreten Keys regenerieren - und den Erfolg mit einem Testaufruf verifizieren, der den alten Key nutzt und einen 401-Fehler erwarten sollte.

Wo Managed Identity an ihre Grenzen stößt

Managed Identity ist an eine Azure-Compute-Ressource gebunden - sie existiert nicht außerhalb von Azure. Das hat drei praktische Konsequenzen, die vor dem Rollout klar sein sollten. Wichtig ist dabei auch, was Managed Identity nicht regelt: Sie klärt, wer sich authentifizieren darf, nicht, von wo aus überhaupt auf die Ressource zugegriffen werden darf - das ist eine separate, netzwerkseitige Kontrolle.

Lokale Entwicklung funktioniert nicht mit Managed Identity, weil auf einem Entwicklerlaptop schlicht keine Azure-Compute-Ressource läuft, an die eine Identität gebunden werden könnte. DefaultAzureCredential löst das, aber eben nicht mit Managed Identity, sondern mit Ihrer eigenen, per az login angemeldeten Entra-ID-Identität - technisch eine andere Credential-Quelle in derselben Kette, praktisch aber weiterhin Sie selbst, mit Ihren eigenen Rollen und Ihrer eigenen Audit-Spur. Für Automatisierung außerhalb von Azure - etwa selbstgehostete CI/CD-Runner oder lokale Batch-Jobs - bleibt der übliche Weg ein Service Principal mit Client Secret oder Zertifikat, optional über Workload Identity Federation, bei der eine Managed Identity als Federated Credential fungiert. Eine „echte” Managed Identity im engeren Sinn ist das nicht.

Drittanbieter-Tools und -SDKs unterstützen Entra ID nicht durchgängig. Ein konkretes, aktuell dokumentiertes Beispiel: Die offizielle Anthropic-Dokumentation zu Claude in Microsoft Foundry hält fest, dass Foundry nur von den SDKs für C#, Java, PHP, Python und TypeScript nativ unterstützt wird - die Go- und Ruby-SDKs unterstützen Foundry (Stand: August 2026) nicht nativ. Als Workaround empfiehlt Anthropic dort, das Standard-SDK mit manuell gesetztem Bearer-Token zu verwenden - mit der ausdrücklichen Warnung, dass ein automatischer Token-Refresh in diesem Workaround nicht eingebaut ist und Entra-ID-Tokens typischerweise nach einer Stunde ablaufen; die Anwendung muss sich selbst darum kümmern. Auch die ant-CLI hat eine dokumentierte Falle: Ein per --auth-token übergebener Entra-ID-Token wird stillschweigend von einer gesetzten Umgebungsvariable ANTHROPIC_API_KEY überstimmt - die CLI gibt dazu nur einen Hinweis auf der Konsole aus, keinen Fehler. Wer Managed Identity organisationsweit durchsetzen will, muss also pro Tool prüfen, ob und wie sauber Entra ID tatsächlich unterstützt wird, statt das pauschal vorauszusetzen.

Manche Modelle verlangen es inzwischen umgekehrt. Bei den als Research Preview geführten Claude-Mythos-Modellen in Foundry ist es nicht die Managed Identity, die fehlt, sondern der API-Key: Die Foundry-Dokumentation vermerkt für Claude Mythos 5 und Mythos Preview ausdrücklich, dass diese Modelle ausschließlich Microsoft-Entra-ID-Authentifizierung unterstützen - eine Bestätigung, dass Microsoft und Anthropic die Richtung, in die dieser Artikel zeigt, bei neueren Modellen bereits zur Voraussetzung machen.

Managed Identity und Entra Agent ID: zwei verschiedene Baustellen

Wer sich mit Identitäten für KI-Workloads beschäftigt, stößt derzeit auch auf Microsoft Entra Agent ID - ein Thema, das Sie leicht mit Managed Identity verwechseln können, weil beide unter demselben Entra-ID-Dach laufen. Der Unterschied liegt in der Ebene: Managed Identity beantwortet die Frage, wie ein Dienst oder eine Workload - Ihre Azure Function, Ihre Container-App - sich gegenüber Azure OpenAI oder Foundry authentifiziert. Entra Agent ID adressiert eine andere Frage: wie ein KI-Agent selbst, der eigenständig handelt, Entscheidungen trifft und dabei möglicherweise dynamisch entsteht und wieder verschwindet, als eigene, nachverfolgbare Identität im Tenant geführt, verwaltet und governt wird. Für den in diesem Artikel behandelten Fall - Ihre Anwendung ruft ein Modell auf - ist Managed Identity die richtige Antwort. Sobald ein Agent selbst zum handelnden Prinzipal wird, der etwa auf Postfächer oder andere Ressourcen zugreift, wird die Agent-ID-Ebene relevant. Die beiden Konzepte ergänzen sich, ersetzen sich aber nicht.

Aus unseren Projekten: Wir haben Azure-KI-Dienste in Projekten vollständig auf Managed Identity umgestellt - nicht aus Prinzip, sondern weil sonst API-Keys an Fachbereiche verteilt werden mussten. Genau das entfällt damit: Es gibt keinen Schlüssel mehr, der weitergegeben, in einer Konfigurationsdatei landen oder unbemerkt kopiert werden kann.

Häufige Fragen zu Managed Identity für Azure-KI-Dienste

Brauche ich für Azure OpenAI und für Claude in Foundry dieselbe RBAC-Rolle?

Nein. Für den klassischen Azure-OpenAI-Endpunkt reicht Cognitive Services OpenAI User für Inferenzaufrufe. Für den vereinheitlichten Foundry-Models-Endpunkt, über den auch Claude-Modelle laufen, ist stattdessen Cognitive Services User nötig - die OpenAI-spezifische Rolle gewährt dort laut Microsoft-Dokumentation ausdrücklich keinen Zugriff.

Warum bekomme ich trotz Cognitive Services OpenAI User einen 403-Fehler in Foundry?

Vermutlich rufen Sie den vereinheitlichten Foundry-Models-Endpunkt auf, nicht den klassischen Azure-OpenAI-Endpunkt - für Claude und andere Drittanbietermodelle ist das die Regel. Dafür reicht Cognitive Services OpenAI User nicht; nötig ist Cognitive Services User. Die Foundry-Rollenlandschaft ist derzeit noch im Fluss (Stand: August 2026), prüfen Sie die aktuelle Zuweisung also im Zweifel erneut.

Kann ich Managed Identity auch für lokale Entwicklung nutzen?

Nein, Managed Identity ist an eine Azure-Compute-Ressource gebunden. Lokal übernimmt DefaultAzureCredential stattdessen Ihre eigene, per az login angemeldete Entra-ID-Identität - derselbe Code funktioniert also in beiden Umgebungen, aber die zugrunde liegende Identität ist eine andere.

Wie lange dauert es, bis eine Rollenzuweisung wirkt?

Bis zu fünf Minuten, laut Microsoft-Dokumentation. Änderungen an der Mitgliedschaft einer Security Group wirken dagegen sofort - ein Grund, Rollen eher an Gruppen als an einzelne Prinzipale zu vergeben.

Wenn ich API-Keys deaktiviere, sind sie sofort ungültig?

Nicht garantiert sofort. Die Einstellung disableLocalAuth wird auf der Control-Plane-Ebene sofort übernommen, das vorgeschaltete Authentifizierungs-Gateway kann laut Microsoft aber je nach Region, Last und Cache-Status noch bis zu mehreren Stunden zwischengespeicherte Keys akzeptieren.

Ersetzt Managed Identity auch Service Principals in CI/CD-Pipelines?

Nur innerhalb von Azure. Für Runner und Pipelines außerhalb von Azure - etwa selbstgehostete GitHub-Actions-Runner - bleibt ein Service Principal mit Client Secret, Zertifikat oder Workload Identity Federation der übliche Weg, da dort keine Azure-Compute-Ressource existiert, an die eine Managed Identity gebunden werden könnte.

Fazit

Der API-Key ist für Azure OpenAI und Microsoft Foundry keine falsche, aber eine bewusst eingeschränkte Option - geeignet für schnelles Prototyping, ungeeignet für Produktivbetrieb mit mehreren Anwendungen, mehreren Teams und dem Anspruch, im Ernstfall nachvollziehen zu können, wer wann worauf zugegriffen hat. Managed Identity löst genau dieses Problem, ohne dass Entwicklerinnen und Entwickler ein einziges Secret verwalten müssen - vorausgesetzt, die Rollenzuweisung stimmt, und das ist bei mehreren ähnlich benannten Rollen der Punkt, an dem die meisten Rollouts zunächst scheitern. Wer heute noch mit Keys arbeitet, sollte die Umstellung nicht als Nice-to-have behandeln: Einzelne neuere Foundry-Funktionen und -Modelle setzen Entra ID inzwischen bereits voraus, nicht mehr nur als Empfehlung.

Quellen (Stand: August 2026, Abruf 20.08.2026):

Azure OpenAI Managed Identity: API-Keys für Azure-KI-Dienste richtig ablösen