<\/p>\n
Microsoft Foundry Agents mit Token Control unter Kontrolle<\/p>\n
<\/h1><\/div>
Inhalt<\/p>\n\n\n\n
- \n
- Warum Regeln unterhalb der Modellauswahl liegen m\u00fcssen<\/a><\/li>\n\n\n\n
- Prompt Agents \u00fcber ein admin-connected Modell<\/a><\/li>\n\n\n\n
- Kontrollebene als Code statt als Klick<\/a><\/li>\n\n\n\n
- Hosted Agents und eigene Agents<\/a><\/li>\n\n\n\n
- Was Sie damit steuern<\/a><\/li>\n\n\n\n
- Ihr n\u00e4chster Schritt<\/a><\/li>\n<\/ul>\n\n\n\n
Microsoft Foundry hat die Einstiegsh\u00fcrde f\u00fcr KI-Agenten so weit gesenkt, dass Agenten heute nicht mehr nur in Entwicklungsteams entstehen. Prompt Agents<\/a> sind deklarative Agenten: Modell, Instructions und Tools werden beschrieben, nicht programmiert. Das ist die Geschwindigkeit, die Fachbereiche brauchen, und einer der Gr\u00fcnde, warum wir Foundry in Kundenprojekten regelm\u00e4\u00dfig empfehlen.<\/p>\n\n\n\n
Bei einer selbst entwickelten Anwendung ist die Antwort auf Governance und FinOps einfach, denn der Endpunkt steht im Code. Bei einem deklarativ beschriebenen Agenten gibt es keinen Code. F\u00fcr ihn gelten dennoch dieselben Budgets, dieselben Limits und dieselbe Nachweispflicht wie f\u00fcr jede andere KI-L\u00f6sung im Unternehmen.<\/p>\n\n\n
\n![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/infografik-agent-laufzeiten-1024x576.png\")
<\/a><\/figure>\n<\/div>\n\n\nToken Control<\/a> ist eine KI-Kontrollebene zwischen Ihren Anwendungen und Ihren Modellen, in der Budgets, Zugriffsregeln und Nachweise zusammenlaufen. In diesem Beitrag zeigen wir, wie Sie damit alle Agenten in Microsoft Foundry steuern, unabh\u00e4ngig davon, ob sie deklarativ beschrieben oder selbst entwickelt sind.<\/p>\n\n\n\n
Warum Regeln unterhalb der Modellauswahl liegen m\u00fcssen<\/h3>\n\n\n\n
Wenn Teams ihre KI-Nutzung ordnen wollen, nennen sie fast immer dieselben f\u00fcnf Anforderungen: zuverl\u00e4ssiger Modellzugriff, Kostentransparenz in Echtzeit, feste Budgetgrenzen, Zuordnung pro Entit\u00e4t und eine Integration, die bestehende L\u00f6sungen nicht anfasst.<\/p>\n\n\n\n
Mit Agenten werden diese Anforderungen dringlicher. Eine klassische KI-Funktion verbraucht Token pro Nutzeranfrage. Ein Agent verbraucht Token pro Arbeitsschritt, und wie viele Schritte ein Auftrag ben\u00f6tigt, entscheidet der Agent zur Laufzeit. Aus einer planbaren Kostenposition wird eine variable, und eine variable Position braucht eine Grenze, die vor dem Aufruf greift.<\/p>\n\n\n\n
Entscheidend ist, an welcher Stelle diese Grenze sitzt. Wer einen Agenten deklarativ beschreibt, w\u00e4hlt ein Modell aus einer Liste und formuliert Instructions. Es gibt keine Anwendungskonfiguration, in die ein Plattformteam einen Endpunkt eintragen k\u00f6nnte, und keinen Build-Prozess, in den sich eine Richtlinie einh\u00e4ngen lie\u00dfe. Die Regeln m\u00fcssen deshalb unterhalb der Modellauswahl liegen, damit sie den Agenten erreichen.<\/p>\n\n\n\n
Derselbe Ma\u00dfstab gilt regulatorisch. EU AI Act und DSGVO fragen nicht danach, ob ein Agent entwickelt oder konfiguriert wurde. Sie fragen, wer ihn genutzt hat, mit welchem Modell, in welcher Region und mit welchem Ergebnis. Diese Auskunft muss aus der Plattform kommen, nicht aus dem einzelnen Agenten.<\/p>\n\n\n\n
Prompt Agents \u00fcber ein admin-connected Modell<\/h3>\n\n\n\n
Microsoft Foundry erlaubt es, ein eigenes Modell-Gateway als Connection zu registrieren. Das Ergebnis hei\u00dft bei Microsoft admin-connected model<\/a> und wird im Foundry Portal angelegt.<\/p>\n\n\n\n
Hinterlegt werden dabei zwei Dinge: der Endpunkt von Token Control als Ziel der Connection und der zugeh\u00f6rige API-Key. Foundry ruft den Endpunkt anschlie\u00dfend selbst auf und erg\u00e4nzt den Pfad der Chat Completions, sodass nur der Basispfad eingetragen wird. Die Modelle, die \u00fcber diese Connection nutzbar sein sollen, werden dabei explizit benannt.<\/p>\n\n\n
\n![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/foundry-admin-connected-models-1024x593.png\")
<\/a><\/figure>\n<\/div>\n\n\nDas registrierte Modell erscheint anschlie\u00dfend als Deployment im Modell-Picker jedes Agenten im Projekt, adressiert als
<connection-name>\/<model-name><\/code>.<\/p>\n\n\n\n![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/foundry-modell-picker-1024x593.png\")
<\/a><\/figure>\n<\/div>\n\n\nMehr braucht es nicht. Wer einen Agenten beschreibt, w\u00e4hlt ein Modell aus einer Liste. Steht in dieser Liste ein Modell hinter Token Control, gelten Budget, Limit und Nachweis ab dem ersten Aufruf, ohne dass der Autor des Agenten etwas konfiguriert oder davon wissen muss.<\/p>\n\n\n\n
Kontrollebene als Code statt als Klick<\/h3>\n\n\n\n
F\u00fcr den ersten Agenten gen\u00fcgt das Portal. F\u00fcr mehrere Umgebungen und mehrere Teams geh\u00f6ren Verbindung und Agent in Code, sonst bleibt die Kontrollebene ein einmaliger Klick und wird kein \u00fcberpr\u00fcfbarer Zustand.<\/p>\n\n\n\n
Die Connection ist eine Control-Plane-Ressource. Wir legen sie mit dem AzAPI<\/a> Terraform Provider<\/a> an, der ARM-Ressourcen direkt anspricht:<\/p>\n\n\n\n
resource \"azapi_resource\" \"token_control\" {\n type = \"Microsoft.CognitiveServices\/accounts\/projects\/connections@2025-04-01-preview\"\n name = local.names.token_control_connection\n parent_id = azurerm_cognitive_account_project.main.id\n\n body = {\n properties = {\n category = \"ModelGateway\"\n target = var.token_control.base_url\n authType = \"ApiKey\"\n isSharedToAll = false\n metadata = {\n deploymentInPath = \"false\"\n models = jsonencode([{\n name = var.token_control.deployment_name\n properties = {\n model = {\n name = var.token_control.model_name\n version = var.token_control.model_version\n format = \"OpenAI\"\n }\n }\n }])\n }\n }\n }\n\n sensitive_body = {\n properties = {\n credentials = { key = var.token_control_api_key }\n }\n }\n}<\/code><\/pre>\n\n\n\nZwei Angaben sind dabei wesentlich.
isSharedToAll = false<\/code> begrenzt die Verbindung auf ein Projekt statt auf alle Projekte des Accounts und h\u00e4lt die Kontrollebene damit pro Umgebung trennbar. Der API-Key von Token Control gelangt ausschlie\u00dflich \u00fcber eine Umgebungsvariable in dassensitive_body<\/code> und nie in eine tfvars-Datei.<\/p>\n\n\n\nAus derselben Ressource folgt die Rollentrennung. Das Anlegen erfordert laut Microsoft Foundry User oder h\u00f6her auf dem Projekt und Contributor auf der Resource Group<\/a>. Die Verbindung liegt damit bei der Administration, die Agenten bleiben bei den Fachteams. Genau diese Trennung suchen Plattformteams, wenn sie Governance einf\u00fchren wollen, ohne selbst zum Nadel\u00f6hr zu werden.<\/p>\n\n\n\n
Auf der anderen Seite steht der Agent. Im Foundry SDK<\/a> bleibt er eine gew\u00f6hnliche Definition, und die Modellreferenz ist die einzige Stelle, die den Unterschied ausmacht:<\/p>\n\n\n\n
RELEASE_NOTES_WRITER_SPEC = PromptAgentSpec(\n name=\"release-notes-writer\",\n description=(\n \"Turns a raw change list into structured release notes, running on an \"\n \"admin-connected model governed by Token Control.\"\n ),\n instructions=RELEASE_NOTES_WRITER_INSTRUCTIONS,\n smoke_prompt=RELEASE_NOTES_WRITER_SMOKE_PROMPT,\n validate_smoke=validate_smoke,\n connected_model_env_var=\"FOUNDRY_CONNECTED_MODEL_DEPLOYMENT_NAME\",\n)<\/code><\/pre>\n\n\n\nDie deklarierte Variable hat Vorrang vor dem regul\u00e4ren Deployment-Namen. Derselbe Agent l\u00e4uft mit einer anderen Variable auf einem anderen Modell, ohne dass Instructions oder Logik sich \u00e4ndern.<\/p>\n\n\n\n
export FOUNDRY_CONNECTED_MODEL_DEPLOYMENT_NAME=\"$(\n terraform -chdir=infra output -raw connected_model_deployment_name\n)\"\nuv run deploy-agent release-notes-writer<\/code><\/pre>\n\n\n\nTerraform besitzt damit die Verbindung, das SDK besitzt die Agenten-Definition. Kontrollebene und Agent sind gemeinsam versioniert und \u00fcber alle Umgebungen hinweg identisch.<\/p>\n\n\n\n
Hosted Agents und eigene Agents<\/h3>\n\n\n\n
F\u00fcr selbst entwickelte Agenten gilt dieselbe Kontrollebene, angeschlossen \u00fcber die Konfiguration des Agenten.<\/p>\n\n\n\n
Hosted Agents sind Container, die Foundry f\u00fcr Sie betreibt. Sie greifen nicht auf die Connection aus dem vorigen Abschnitt zu, sondern erhalten Endpunkt und Schl\u00fcssel \u00fcber ihre eigene Konfiguration. Die Base URL ist eine gew\u00f6hnliche Umgebungsvariable, der API-Key geh\u00f6rt in eine Foundry-Projekt-Connection und wird \u00fcber einen Platzhalter zur Laufzeit aufgel\u00f6st<\/a>:<\/p>\n\n\n\n
services:\n release-notes-writer:\n host: azure.ai.agent\n env:\n OPENAI_BASE_URL: https:\/\/<ihr-token-control-host>\/api\/v1\/openai\n OPENAI_API_KEY: ${{connections.token-control.credentials.key}}<\/code><\/pre>\n\n\n\nDer Schl\u00fcssel liegt damit weder im Container-Image noch im Repository. Erg\u00e4nzend injiziert Foundry zur Laufzeit unter anderem
FOUNDRY_PROJECT_ENDPOINT<\/code>,FOUNDRY_AGENT_NAME<\/code> und die Verbindung zu Application Insights, sodass Ihr Code die eigene Identit\u00e4t und das Ziel f\u00fcr Telemetrie kennt, ohne sie selbst zu verwalten.<\/p>\n\n\n\nDasselbe Muster gilt f\u00fcr Azure Container Apps, Azure Kubernetes Service, Azure Functions und die lokale Entwicklungsumgebung, dort mit einem eingeschr\u00e4nkten API-Key je Arbeitsplatz.<\/p>\n\n\n\n
Was Sie damit steuern<\/h3>\n\n\n\n
An dieser Stelle laufen beide Wege zusammen. Der deklarativ beschriebene Prompt Agent und der selbst entwickelte Agent erreichen dieselbe Kontrollebene, und ab dort gelten f\u00fcr sie dieselben Regeln, verwaltet von denselben Personen.<\/p>\n\n\n\n
Budgets, die vor dem Aufruf greifen.<\/strong> Sie hinterlegen Budgets und Limits in Euro pro Entit\u00e4t, also pro Nutzergruppe, Abteilung, Kostenstelle oder KI-L\u00f6sung. Anfragen werden blockiert, bevor ein Limit \u00fcberschritten wird. Ein Rate-Limit auf Tokens pro Minute sch\u00fctzt die Performance einer Plattform, ein Euro-Budget sch\u00fctzt das Budget einer Abteilung.<\/p>\n\n\n
\n![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/tokencontrol-budgets-kostenstellen-1024x599.png\")
<\/a><\/figure>\n<\/div>\n\n\nZugriff, der einer L\u00f6sung zugeordnet ist.<\/strong> Jede L\u00f6sung, jedes Projekt und jedes Team erh\u00e4lt einen eigenen, eingeschr\u00e4nkten API-Key, dessen Nutzung und Kosten getrennt nachverfolgt werden. Ein rotierter oder gesperrter Schl\u00fcssel betrifft damit genau eine L\u00f6sung und nicht die gesamte KI-Nutzung. Ein TPM-Limit pro Anwendung stellt zus\u00e4tzlich sicher, dass keine Anwendung die Kapazit\u00e4t dominiert, und der Zugriff bleibt auf die von Ihnen freigegebenen Modelle beschr\u00e4nkt.<\/p>\n\n\n\n
Nachweise, die einer Pr\u00fcfung standhalten.<\/strong> Jede Anfrage wird \u00fcber eine Correlation-ID protokolliert, mit Tokens, Modell, Region, Zeitstempel und Kosten.<\/p>\n\n\n\n
Prompt- und Antwortinhalte werden dabei nicht gespeichert, Verarbeitung und Speicherung finden in der EU statt. Das Compliance-Dashboard zeigt zus\u00e4tzlich die regionale Verteilung der genutzten Modelle und den Status der Content-Filter. Damit entsteht eine pr\u00fcff\u00e4hige Grundlage, die die Transparenzanforderungen des EU AI Act unterst\u00fctzt, ohne dass Sie Gespr\u00e4chsinhalte Ihrer Nutzer archivieren.<\/p>\n\n\n
\n![\"\"](\"https:\/\/whiteduck.de\/wp-content\/uploads\/tokencontrol-request-log-1024x512.png\")
<\/a><\/figure>\n<\/div>\n\n\nDie Sicht aus Foundry bleibt dabei vollst\u00e4ndig erhalten. L\u00e4ufe, Schritte, Latenz und Fehler sind weiter \u00fcber Traces und den Monitor-Tab<\/a> sichtbar, angebunden an Ihre Application-Insights-Ressource.<\/p>\n\n\n\n
Ihr n\u00e4chster Schritt<\/h3>\n\n\n\n
Die Kontrollebene wird einmal eingerichtet. Danach stehen alle Agenten Ihres Projekts unter denselben Regeln, unabh\u00e4ngig davon, wo sie laufen und ob sie deklarativ beschrieben oder selbst entwickelt sind.<\/p>\n\n\n\n
In einer 30-min\u00fctigen Demo<\/a> zeigen wir Token Control an Ihrem Szenario und beantworten die Fragen, die f\u00fcr Ihre Organisation z\u00e4hlen. Alle Funktionen im Detail stehen auf der Produktseite<\/a>.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
- Prompt Agents \u00fcber ein admin-connected Modell<\/a><\/li>\n\n\n\n