Wer hat diese Agents gebaut?

In einem Kundentenant mit 3.000 Usern haben wir im ersten Inventar 280 Agents gefunden. 170 davon hatten keinen Verantwortlichen mehr, der noch im Unternehmen war. Gebaut hat sie niemand Böses, sondern Fachabteilungen, die schnell etwas lösen wollten. Genau so sind vor zehn Jahren die Service Principals entstanden, die heute noch keiner aufgeräumt hat. Agents wiederholen dieses Muster, nur schneller und in größerer Zahl.

Was eine Lizenz nicht kann

E7 bündelt E5, Copilot, die Entra Suite und Agent 365. Was im Paket steckt, ist inzwischen hinreichend beschrieben. Eine Lizenz räumt aber keinen Tenant auf. Sie gibt uns Werkzeuge, um Agents zu sehen, zu identifizieren und zu kontrollieren. Ob ein Agent da sein sollte, wer für ihn geradesteht und worauf er zugreifen darf, entscheidet sie nicht.

Dazu kommt das Tempo. Agents entstehen heute dort, wo früher Excel-Makros entstanden sind: in den Fachbereichen, schnell und ohne Ticket. Das ist gewollt, und wir finden das auch gut so. Es heißt aber, dass die Zahl der nicht-menschlichen Konten im Verzeichnis schneller wächst als jede andere Gruppe.

Was die Registry zeigt und was nicht

Agent 365 sammelt Agents aus Microsoft 365, Copilot Studio, Power Platform und Foundry an einer Stelle. Defender for Endpoint findet zusätzlich lokal installierte KI-Agents auf den Clients, inklusive der konfigurierten MCP-Server. Beides landet im Advanced Hunting und lässt sich per KQL zusammen auswerten. Shadow AI im wörtlichen Sinn.

Mit dieser Abfrage schauen wir uns an, welche Agents tatsächlich aufgerufen werden und welche Werkzeuge sie dabei nutzen:

CloudAppEvents
| where ActionType in ("InvokeAgent", "InferenceCall", "ExecuteToolBySDK", "ExecuteToolByGateway")
| extend RawEventData_parsed = parse_json(RawEventData)
| extend
    Workload          = coalesce(tostring(RawEventData_parsed["Workload"]), "Unknown"),
    TargetAgentName   = coalesce(tostring(RawEventData_parsed["TargetAgentName"]), "Unknown"),
    AgentName         = coalesce(tostring(RawEventData_parsed["AgentName"]), "Unknown"),
    AgentBlueprintId  = coalesce(tostring(RawEventData_parsed["AgentBlueprintId"]), "Unknown"),
    PlatformAgentType = coalesce(
        tostring(RawEventData_parsed["PlatformAgentType"]),
        tostring(RawEventData_parsed["CopilotEventData"]["PlatformAgentType"]),
        "Unknown"
    )
| project-away RawEventData_parsed
| summarize count() by ActionType, Workload, TargetAgentName, PlatformAgentType, AgentName, AgentBlueprintId

Dazu gehört eine Einschränkung: Die Abfrage zeigt nur einen Teil des Bilds, nämlich vor allem Microsoft-eigene Agents und solche, die auf Microsoft-Plattformen gebaut wurden. Was daneben läuft, sieht man hier nicht.

Für die lokalen Agents auf den Clients reicht Defender for Endpoint Plan 2:

AgentsInfo
| where Platform == "LocalAgents"
| summarize arg_max(Timestamp, Name, Version, LifecycleStatus, RawAgentInfo) by AgentId
| where LifecycleStatus !in~ ("Deleted", "Uninstalled")
| extend AgentMetadata = RawAgentInfo.localAgentMetadata
| extend Vendor = tostring(AgentMetadata.vendor),
         Device = tostring(AgentMetadata.deviceName)
| summarize DeviceCount = dcount(Device) by Agent = Name, Vendor
| sort by DeviceCount desc

Ein Agent, der im Auftrag eines Users handelt, erbt dessen Rechte. Hat dieser User Zugriff auf eine viel zu weit freigegebene SharePoint-Bibliothek, hat der Agent das auch. Er ist dabei nur schneller und gründlicher als jeder Mensch.

Ein autonomer Agent mit eigener Identität arbeitet mit eigenen Berechtigungen. Der braucht jemanden, der verantwortlich ist, ein sauberes Berechtigungsprofil und ein Ablaufdatum, wie jedes andere Konto, das an Unternehmensdaten kommt.

Die Registry zeigt, was da ist. Ob es da sein sollte, muss jemand bewerten, und diese Bewertung wird nie fertig.

Agents brauchen Identitäten, keine Ausnahmen

Agents, die mit Entra Agent ID gebaut werden, bekommen eine eigene, verwaltete Identität. Über Agent Blueprints lässt sich festlegen, wie ein Agent gebaut ist und welche Rechte er bekommt, bevor es ihn überhaupt gibt. Und mit Entra ID Governance laufen Zugriffsprüfungen und Lebenszyklus auch für Agents: anlegen, freigeben, Verantwortliche zuweisen, regelmäßig prüfen, ablaufen lassen.

Conditional Access lässt sich auf Agent-Identitäten und Blueprints anwenden, aber nicht eins zu eins wie bei Menschen. Policies für „alle Benutzer“ erfassen Agent-Konten nicht, und wer per API-Key zugreift, läuft an Entra komplett vorbei. Diese Lücken muss man kennen, bevor man sich auf die Policy verlässt.

Klingt selbstverständlich. Ist es in der Praxis leider nicht. Wir sehen in vielen Tenants schon heute, wie schwer das bei klassischen App-Registrierungen und Service Principals fällt. Verwaiste Secrets, Berechtigungen aus irgendeiner Testphase, Verantwortliche, die längst woanders arbeiten. Agents machen das nicht besser, weil sie in größerer Zahl und von viel mehr Leuten gebaut werden.

Wer seine Service Principals heute nicht im Griff hat, wird seine Agents morgen auch nicht im Griff haben.

Governance ist eine Daueraufgabe

Jede Woche kommen neue Agents dazu. Verantwortliche wechseln die Rolle oder das Unternehmen. Berechtigungen wachsen, Conditional-Access-Regeln bekommen Ausnahmen, Sensitivity Labels pflegt keiner. Nichts davon ist ein Projekt mit Go-live, es ist Betrieb.

Und genau so gehen wir es an. Mit Managed Entra betreiben wir Entra ID für unsere Kunden komplett als Code. Das klingt nach Technikdetail, ist aber der eigentliche Grund, warum der Betrieb verlässlich läuft.

Viele Unternehmen haben einen sauberen Change-Prozess nach ITIL. Im Ticket steht, was geändert werden soll, dann wird im Portal geklickt. Aber wer prüft, ob genau das angepasst wurde und nichts anderes?

Bei uns wird nicht die Beschreibung geprüft, sondern die Änderung selbst. Die Regeln liegen als Code vor. Vorher steht schwarz auf weiß fest, was sich ändert. Eine zweite Person gibt genau das frei, und nur das wird ausgerollt, mit Name und Datum. Geht trotzdem etwas schief, ist der letzte funktionierende Stand in Minuten wiederhergestellt und nicht in einer Nachtschicht.

Auch Ausnahmen laufen über diesen Weg. Braucht ein Kunde eine Abweichung vom Standard, steht sie im Repository und nicht in einer Excel-Liste oder im Kopf eines Admins. Sie ist sichtbar, versioniert und wird geprüft wie jede andere Änderung. Damit verwässert die Baseline nicht schleichend über die Monate, und beim nächsten Audit liegt der Nachweis, wie der Tenant konfiguriert ist und wer wann was geändert hat, schon fertig vor.

Und wir halten uns selbst an das, was wir für Agents fordern. Unsere eigene Automatisierung ist ja auch eine nicht-menschliche Identität. Sie meldet sich über föderierte Identitäten am Kundentenant an, ganz ohne gespeichertes Secret. Die Rechte sind getrennt: Eine Identität darf nur lesen und planen, eine andere darf schreiben. Kein Passwort, das abfließen kann, kein Zertifikat, das irgendwann still abläuft.

Bei den Agents selbst sind wir mittendrin. Conditional Access, Access Reviews und Entitlement Management laufen bei uns heute schon als Code. Woran wir gerade bauen, sind Agent-Vorlagen im Repository, mit Identität, Berechtigungen, Conditional Access, Verantwortlichen und Ablaufdatum, sowie automatische Prüfungen auf verwaiste Agent-Identitäten, etwa mit Maester-Checks aus der Community. Bei hunderten Agents ist das der Unterschied zwischen Überblick und Hoffnung.

Wie Purview die Daten schützt, die Agents lesen und weitergeben, und wie unser CSOC ihre Aktivität überwacht, beschreiben wir in einem eigenen Artikel zur KI-Governance.

Und die Agents in Azure?

Agent 365 sieht auch Agents, die in Microsoft Foundry laufen. Aber jemand muss die Plattform darunter bauen und betreiben: Modelle, Netzwerk, Datenanbindung, Evaluierung. Dafür haben wir die AI Foundation gebaut, komplett als Code, sodass jedes neue KI-Projekt mit denselben Leitplanken startet wie das letzte. Mehr dazu steht in unserem Artikel über die drei Foundations: The Holy Trinity.

Der wichtigste Punkt ist die Verbindung nach unten. Jeder Agent aus der AI Foundation bekommt eine eigene Identität im selben Entra wie der Rest der Landschaft, mit genau den Rechten, die er braucht. Handelt er im Auftrag eines Users, sieht er nur, was dieser User sehen darf. Und er hinterlässt eine Spur, die sich prüfen lässt. Kein Sonderweg mit eigenen Konten und eigenen Ausnahmen, nur weil der Agent in Azure läuft statt in Microsoft 365.

Drei Fragen für morgen früh

Wer wissen will, wo er steht, kann mit drei Fragen anfangen:

1. Welche Agents haben keinen aktiven Owner oder Sponsor mehr?
2. Welche Service Principals haben Secrets, die älter als zwölf Monate sind?
3. Welche Agents greifen per API-Key statt über Entra zu?

Wer auf alle drei schnell eine Antwort hat, ist weiter als die meisten.

Wo wir anfangen

Beim Ist-Zustand, denn die Agents sind ohnehin schon da. In unserem zweitägigen Agent 365 Workshop machen wir sichtbar, welche Agents in eurem Tenant laufen und woher sie kommen. Danach habt ihr ein Inventar, ein Risikobild und einen Governance-Plan mit klaren Verantwortlichkeiten.

Fazit

E7 packt ein echtes Problem an. Zu sehen, was läuft, heißt aber noch nicht, es im Griff zu haben. Dafür muss jemand jeden Tag hinschauen, Identitäten pflegen, Berechtigungen zurückschneiden und merken, wenn sich ein Agent plötzlich anders verhält als gestern.

Die Lizenz ist der Anfang. Der Betrieb entscheidet.

Ihr habt E7 schon im Einsatz oder merkt, dass sich bei euch die Agents vermehren? Und fragt euch, wer das eigentlich im Blick hat? Sprecht uns an. Wir schauen gemeinsam, was bei euch läuft und was davon bleiben darf. Den Einstieg unterstützt Microsoft über Förderprogramme. Ob das für euch passt, klären wir gemeinsam.