Ein Agent ist eine Integration. Hundert sind ein Governance-Problem.

Die interessante Frage zu Agenten ist längst nicht mehr, ob sie funktionieren. In den Projekten, die wir sehen, funktioniert ein Agent, der die E-Mail eines Lieferanten liest und die passende Bestellung vorschlägt, gut genug, um ihn zu behalten. Die interessante Frage ist, was an dem Tag geschieht, an dem es vierzig davon gibt, gebaut von vier Teams, von denen drei längst an etwas anderem arbeiten.

Das ist kein KI-Problem. Jeder einzelne Teil davon ist ein Problem, das die Branche bereits beim Namen kennt: Identität, Zuweisung von Zugriffen, Auditierung, Kostenzuordnung, Reichweite eines Fehlers, Änderungskontrolle. Die Schwierigkeit ist, dass sie alle gleichzeitig auftreten, angehängt an etwas, das selbst entscheidet.

Drei Wellen, und nur die dritte ist schwer

Die erste Welle drehte sich um Modelle. Welches, wie groß, zu welchem Preis pro Million Token. Sie wirkte damals entscheidend und erwies sich als die am wenigsten dauerhafte: Das Modell, das heute in Produktion läuft, wird zweimal ersetzt sein, bevor dieser Artikel alt ist.

Die zweite Welle drehte sich um Agenten. Wie man einen an ein reales System anbindet, wo die Linie zwischen dem verläuft, was er entscheidet, und dem, was Code ausführt. Über diese Linie haben wir in Agenten entscheiden, Code führt aus geschrieben, und die Antwort hält: Urteil auf der einen Seite, Garantien auf der anderen.

Die dritte Welle dreht sich nicht um bessere Agenten. Sie dreht sich um eine Menge von ihnen. Und eine Menge verhält sich völlig anders als eine Integration, weil sich der Fehlermodus ändert. Ein Agent, der eine Berechtigung falsch setzt, ist ein Defekt. Vierzig Agenten, die sich einen Service Principal teilen, sind ein Vorfall ohne jede Möglichkeit festzustellen, welcher davon gehandelt hat.

Was sich im letzten Jahr wirklich geändert hat

Zwei Dinge sind geschehen, die es lohnt, genau zu benennen, denn die Genauigkeit ist das Argument.

Agenten haben eine echte Identität bekommen. Microsoft Entra Agent ID führt vier neue Objekttypen ein: ein agent identity blueprint, ein blueprint principal, eine agent identity und einen agent user. Eine agent identity ist ein Konto in Entra ID, verwaltet mit derselben Lebenszyklus-Maschinerie wie eine Person: Zugriffspakete, Berechtigungsverwaltung, bedingter Zugriff auf Blueprint-Ebene, damit alle daraus erzeugten Agenten die Richtlinie erben, und Risikosignale aus Identity Protection.

Der Teil dieses Entwurfs, der eine Pause verdient, ist der Sponsor. Jede agent identity hat einen Menschen, der für ihren Zugriff und ihren Lebenszyklus verantwortlich ist. Verlässt diese Person die Organisation, geht die Patenschaft automatisch an ihre Führungskraft über. Es antwortet immer jemand für den Agenten, konstruktionsbedingt, und das System weigert sich, diesen Jemand niemanden sein zu lassen.

Agenten haben keine stabile Art bekommen, ihr Handeln aufzuzeichnen. Die semantischen GenAI-Konventionen von OpenTelemetry, das herstellerneutrale Vokabular für Agenten-Traces, wanderten mit der Version v1.42.0 vom 12. Juni 2026 in ein eigenes Repository und bleiben vorstabil. Es gibt kein 1.0. Die Form ist bereits gut und wird breit ausgegeben, und sie bleibt ausdrücklich änderungsanfällig.

Nebeneinandergelegt ist die Asymmetrie die ganze Geschichte:

Wir können inzwischen sagen, wer ein Agent ist, was er berühren darf und wer für ihn einsteht. Genau zu sagen, was er getan hat, in einem Format, das nächstes Jahr noch lesbar ist, ist der Teil, der fehlt. Wer dieses Jahr eine Agentenmenge plant, plant um diese Lücke herum, ob bemerkt oder nicht.

Das Protokoll hat sich eine Governance-Struktur gegeben

Es gibt einen zweiten Beleg, und er ist keine Analogie.

Das Model Context Protocol war im ersten Jahr eine Beschreibungsschicht: Dieses Werkzeug existiert, so ruft man es auf. Die folgenden Revisionen drehten sich fast ausschließlich um Kontrolle. Die Revision vom Juni 2025 stufte MCP-Server als OAuth-2.0-Resource-Server ein, machte die Metadaten geschützter Ressourcen nach RFC 9728 verbindlich und verlangte, dass der Client jedes Token über den Ressourcenparameter aus RFC 8707 an einen konkreten Server bindet. Die Revision vom November 2025 ergänzte inkrementelle Scope-Zustimmung über den WWW-Authenticate-Header, Client-ID-Metadatendokumente für die Registrierung und einen experimentellen tasks-Mechanismus für dauerhafte Anfragen, mit Abfrage und späterem Abholen des Ergebnisses.

Letzteres wiegt schwerer, als es aussieht. Tasks existieren, weil Agenten begonnen haben, Arbeit zu verrichten, die eine Anfrage überdauert. Arbeit, die eine Anfrage überdauert, braucht einen Zustand, einen Eigentümer und einen Weg, abgebrochen zu werden, und das ist die Definition von etwas, das man verwalten muss.

Und dann tat das Protokoll, was Infrastruktur tut, sobald sie tragend wird: Es formalisierte seine eigene Governance. Arbeitsgruppen, Interessengruppen, eine dokumentierte Struktur, ein Stufensystem für SDKs mit Wartungszusagen. Protokolle, die Spielzeug bleiben, gründen keine Gremien.

Was eine Agentenmenge verlangt, und wem jeder Teil gehört

Die neun Themen unten sind die, die wir schieflaufen sahen. Sie so zu gruppieren ist nützlich, weil es zeigt, dass fast keines dem KI-Team gehört.

Nur die letzte Zeile ist neu, und neu nur in dem Sinne, dass die Branche die Gewohnheit noch nicht ausgebildet hat.

Eine Identität pro Agent, und warum die Abkürzung teuer wird

Die häufigste Abkürzung, die wir sehen, ist ein Service Principal, den sich alle Agenten eines Teams teilen. Das ist einfach, funktioniert am ersten Tag und zerstört drei Eigenschaften auf einmal.

Die Zuordnung geht verloren: Das Auditprotokoll hält den Principal fest, nicht welcher Agent ihn benutzt hat, und die Antwort auf "welcher war es" wird zu einer Rekonstruktion aus Anwendungsprotokollen, die es womöglich nicht gibt. Das geringste Privileg geht verloren: Der geteilte Principal sammelt die Vereinigung aller Berechtigungen, die irgendein Agent brauchte, sodass der neueste und am wenigsten geprüfte Agent die Rechte des ältesten und bewährtesten erbt. Und die Widerrufbarkeit geht verloren: Den kompromittierten Agenten abzuschalten schaltet alle ab.

Die Form, die überlebt, ist langweilig und vertraut:

Ein Blueprint trägt die Richtlinie. Jeder Agent erhält daraus seine Identität. Zugriff kommt in einem Paket mit Genehmiger und Enddatum, statt als dauerhafte Gewährung, die das Projekt überlebt, das sie brauchte.

Das Detail, das eine Entscheidung verdient, keine Voreinstellung

Entra Agent ID erlaubt einer agent identity, ein Zugriffspaket programmatisch im eigenen Namen anzufordern, indem sie eine Zuweisungsanfrage erstellt. Auch der Sponsor kann im Namen des Agenten anfordern, und ein Administrator kann direkt zuweisen.

Es lohnt sich, den ersten Weg noch einmal zu lesen. Ein Agent kann mehr Zugriff verlangen.

Das ist kein Fehler. Es ist die richtige Primitive für ein System, in dem Arbeit zur Laufzeit entdeckt wird, und die Anfrage landet weiterhin in einem Genehmigungsablauf mit menschlichem Genehmiger. Aber es ist eine echte Architekturweiche, und sie sollte eine Entscheidung sein, die die Organisation bewusst trifft, statt etwas, das sie in einem Audit entdeckt.

Unsere Position, aus derselben Überlegung, die wir auf jeden Weg zur Rechteerhöhung anwenden: Anfragen zu dürfen ist vertretbar, die Genehmigung darf nie automatisch sein, und der Genehmiger muss jemand sein, der versteht, was diese Ressource ist. Ein Genehmigungsablauf, der zu einer Person führt, die die Anfrage nicht beurteilen kann, ist ein Stempel mit besserem Protokoll.

Die Genehmigung gehört an den unumkehrbaren Schritt

Der Instinkt, sobald ein Team begreift, wie viel ein Agent kann, ist, vor alles einen Menschen zu setzen. Das scheitert binnen zwei Wochen: Wer prüft, liest irgendwann nicht mehr, und man hat Latenz hinzugefügt, ohne Urteil hinzuzufügen.

Die Linie, die hält, ist dieselbe, die den Rest des Systems regiert. Verlangen Sie einen Menschen dort, wo die Aktion unumkehrbar oder nach außen sichtbar ist, und sonst nirgends.

Der Maßstab ist nicht, wie wichtig die Aktion wirkt. Er ist, ob sich ein unbemerkter Fehler am Montag noch korrigieren lässt.

Kosten sind eine Kontrolle, kein Bericht

Der Tokenverbrauch wird meist als Finanzthema behandelt, das am Monatsende auffällt. In einer Agentenmenge ist er ein Sicherheitsmechanismus, denn außer Kontrolle geratene Kosten und außer Kontrolle geratenes Verhalten sind dasselbe Ereignis aus zwei Blickwinkeln. Ein Agent, der in einer Wiederholungsschleife gegen ein ausfallendes Werkzeug feststeckt, erzeugt genau ein sichtbares Symptom, bevor jemand das Verhalten bemerkt: die Rechnung.

Das heißt, das Budget gehört zur Identität, nicht in ein Dashboard:

# Das Limit gehört zur Identität des Agenten, nicht in eine Monatsprüfung.
# Ein Agent in einer Schleife verbraucht sein eigenes Budget und stoppt.
# Er verbraucht nicht das des Teams und nicht das des Nachbaragenten.
def modell_aufrufen(agent: AgentIdentity, anfrage: Anfrage) -> Antwort:
    if budget.verbraucht(agent.id, heute()) >= agent.tageslimit:
        raise BudgetErschoepft(agent.id)         # schließt zu und meldet
    antwort = modell.aufrufen(anfrage)
    budget.erfassen(agent.id, antwort.tokens, antwort.kosten)
    return antwort

Limits je Agent liefern drei Dinge, die ein Monatsbericht nicht liefert: Die Schleife bremst sich selbst, der Fehler wird einem Agenten statt einem Team zugeordnet, und der Alarm schlägt an, solange die Ursache noch auf dem Bildschirm ist.

Audit, wenn der Grund eine Wahrscheinlichkeit ist

Klassische Auditierung beantwortet, was geschah und unter wessen Autorität. Bei Agenten gibt es eine dritte Frage, und sie wird im Raum unmittelbar nach einem Vorfall gestellt: Warum hat er das gewählt.

Diese Antwort kann keine Modellerklärung sein, denn eine nachträglich gelieferte Erklärung ist eine plausible Erzählung, keine Aufzeichnung. Aufzeichnen lässt sich alles, was die Entscheidung umgibt, und das genügt:

• die Identität des Agenten, nicht der geteilte Principal;
• die in jenem Moment verfügbaren Werkzeuge und ihre Versionen;
• die Eingaben, die der Agent tatsächlich erhielt, einschließlich dessen, was ein Suchschritt zurückgab;
• die Werkzeugaufrufe, der Reihe nach, mit ihren Parametern;
• die erteilten Genehmigungen, von wem und wann;
• das Modell und dessen Version, denn das Verhalten ändert sich dazwischen.

Stellt man das wieder her, reproduziert man die Entscheidung, und genau das will eine Prüferin oder ein Prüfer. Es ist zugleich genau die Fläche, die die GenAI-Konventionen von OpenTelemetry beschreiben, und genau deshalb ist ihr vorstabiler Zustand eine Planungsbeschränkung und keine Fußnote. Jetzt instrumentieren, die Version der Konvention fixieren und mit einer Migration rechnen.

Der unbequeme Schluss

Eine Organisation mit geordneter Identität, funktionierender Berechtigungsverwaltung, echter Auditierung und ehrlicher Kostenzuordnung bringt dieses Jahr eine Agentenmenge in Produktion. Eine Organisation ohne all das ist nicht langsam, weil ihr Agenten fehlen. Sie ist langsam, weil dieses Fundament nie gebaut wurde, und Agenten machen das Fehlen messbar, wie es nichts vor ihnen vermochte.

Ähnliches haben wir über den Assistenten, der nur liest, was der Benutzer lesen darf und über was vor dem Einschalten von Copilot zu ordnen ist geschrieben. Das Muster wiederholt sich, weil es im Kern nicht um KI geht. Jede Automatisierungswelle stellt einer Organisation dieselbe Frage, und stellt sie immer lauter: Wissen Sie, wer was tun darf, und können Sie belegen, was getan wurde?

Agenten sind bislang die lauteste Fassung dieser Frage. Sie sind auch die erste, die sie mehrere Hundert Mal am Tag wiederholen wird, ohne zu ermüden, bis jemand antwortet.