Agent-365-Q&A: Wo die Basis endet, beantwortet

Agent 365: The Good, the Bad, and the Ugly warf viele Fragen auf, teils live, teils über das Q&A-Panel. Dies ist das vollständige schriftliche Protokoll, mit dem Kontext hinter jeder Antwort.

In der Session sind wir Agent 365 auf einem Live-Tenant durchgegangen, mit dem Blick der Geschäftsführung auf das Risiko und dem Blick eines Architekten auf den Betrieb. Unsere ehrliche Einschätzung: Microsoft hat sich schnell und in die richtige Richtung bewegt. Für Agenten, die nativ zu Microsoft gehören und neu gebaut sind, ist Agent 365 bereits eine starke Basis, und das sagen wir bewusst deutlich, denn die anschließenden Fragen waren detailliert und drehten sich meist um die Ränder statt um den Kern.

Diese Fragen gruppierten sich um eine Handvoll praktischer Themen: welche Admin-Rollen Sie wirklich brauchen, wie Dritt- und Alt-Agenten abgedeckt sind, wie Identität und Lizenzierung funktionieren und wie Sie Agenten im großen Maßstab bereinigen. Der rote Faden ist klar. Agent 365 ist am stärksten für native, neu gebaute Agenten, und es gibt mehr zu planen, wo Agenten älter sind, von normalen Nutzern gebaut wurden oder auf anderen Plattformen laufen. Die folgenden Antworten sollen Ihnen helfen, das Beste aus Agent 365 herauszuholen und für die Bereiche zu planen, die es noch nicht erreicht.

Wenn Sie zuerst die zugrunde liegende Argumentation möchten, lesen Sie den Deep-Insights-Rückblick und nutzen Sie diese Seite dann als praktische Referenz. Sie können die vollständige Session on demand erneut ansehen.

Admin-Rollen und Zugriff

Welche Admin-Rolle brauchen Sie wirklich, um Agent 365 zu nutzen? Reicht eine KI-Admin-Rolle?

Sie brauchen weder eine neue Lizenz noch eine neue Rolle, um mit Agent 365 zu beginnen. Es nutzt die Rollen wieder, die Sie bereits haben.

Um zu sehen, was in Agent 365 steckt, genügt ein Global Reader. Auf dieser Ebene erhalten Sie die Registry und das Inventory, sodass Sie sehen können, welche Agenten existieren, wie sie gebaut wurden und mit wem sie geteilt sind, ohne die Konfiguration anzufassen. Um etwas zu konfigurieren, das tatsächlich eine Kontrolle anwendet, etwa eine Conditional-Access-Richtlinie für Agenten, verwenden Sie dieselbe Entra-Administratorrolle, mit der Sie schon heute Conditional-Access-Richtlinien erstellen dürfen. Alles Purview-Bezogene, etwa das Verhalten der Data Loss Prevention, nutzt Ihre bestehenden Purview-Rollen. Kurz gesagt: Ihre grundlegenden Microsoft-365-Adminberechtigungen, Lesen, Schreiben und Zuweisen, decken die Zuweisung von Richtlinien an Agenten ab.

Der Vorbehalt betrifft den Ort, an dem diese Konfiguration stattfindet. Alles jenseits der einfachen Ansicht wird weiterhin direkt in den Portalen von Defender, Entra und Purview eingerichtet, nicht in Agent 365 selbst. Das ist die Kehrseite davon, keine neuen Rollen zu brauchen. Weil Agent 365 ein Front-End über Back-End-Diensten ist, brauchen die Personen, die es betreiben, weiterhin echtes Fachwissen über alle drei zugrunde liegenden Produkte hinweg. Wenn Ihr Wissen zu Entra, Purview und Defender bei verschiedenen Personen liegt oder bei niemandem in der Tiefe, ist das eine Lücke, die Sie schließen sollten, bevor Sie sich bei der täglichen Governance auf Agent 365 verlassen.

Die tägliche Realität des Betriebs von Agent 365 ist mit Ihren bestehenden Identitäts- und Zugriffsprozessen verwoben. In einem gut geführten Tenant werden Rollen oft just in time vergeben, statt als dauerhafte Berechtigungen gehalten, sodass diejenigen, die Agent 365 betreiben, die richtige Aktivierung benötigen, bevor sie etwas sehen oder ändern können. Das ist gute Hygiene. Es ist auch eine Erinnerung, vor dem Rollout festzuhalten, wer über Entra, Purview und Defender hinweg welche Rollen innehat, damit die zentrale Ansicht nicht zur Suche danach wird, wer eine Änderung überhaupt vornehmen kann.

Darunter liegt eine Designentscheidung, die man benennen sollte. Agent 365 wird als eine einzige Kontrollebene beschrieben, in der Praxis sind es jedoch vier Portale: Agent 365 selbst plus die drei Lösungsportale für Entra, Purview und Defender. Das Rollenmodell folgt dieser Form. Nichts Neues zuweisen zu müssen ist bequem, doch der Betriebsaufwand verteilt sich auf drei Produkte, die Ihr Team gut kennen muss. Wenn Sie die Verantwortung planen, planen Sie sie über alle vier Bereiche hinweg, nicht nur über das Agent-365-Front-End, und seien Sie ehrlich, wo Ihre Fachtiefe heute tatsächlich liegt.

Dies war der aktivste Strang im Q&A, und es lohnt sich, offen zu sagen, was dabei zutage trat. Mehrere Teilnehmer wandten ein, dass die Rolle AI Administrator allein nicht ausreichte. Einer berichtete, dass er als AI Admin Teile des Menüs, das wir zeigten, gar nicht sehen konnte, konkret die Bereiche Tools, Devices und Marketplace. Es gilt also zwar das Prinzip, dass keine neue Rolle erforderlich ist, doch die praktische Realität ist, dass die AI-Admin-Rolle allein für die volle Sichtbarkeit nicht ausreicht, und Sie werden wahrscheinlich einen umfassenderen Tenant-Admin-Kontext brauchen, um alles zu sehen und zu konfigurieren. Die genaue Mindestrolle für jeden Teil der Erfahrung festzunageln, sollten Sie in Ihrem eigenen Tenant testen, denn Microsoft hat sie noch nicht sauber dokumentiert.

Was Agent 365 plattformübergreifend abdeckt

Sind Foundry-Agenten in Agent 365 sichtbar?

Ja, Foundry-Agenten sind sichtbar, mit einer Bedingung. In unserem Demo-Tenant erschienen sie nicht, weil wir derzeit nicht am Foundry-Programm teilnehmen. Wenn Sie Teil der Preview sind, tauchen Ihre Foundry-Agenten in Agent 365 auf, und Sie können sie mit denselben Defender-, Entra- und Purview-Funktionen verwalten, die für andere native Agenten gelten.

Das ergibt Sinn, sobald man betrachtet, wo Agent 365 seine Grenzen zieht. Foundry steht neben Microsoft 365 Copilot und Copilot Studio in der nativen Ebene, und genau diese native Ebene ist der Bereich, in dem Agent 365 wirklich stark ist. Native Agenten erhalten eine tiefe Integration, Data Loss Prevention in Echtzeit, native Richtlinienvorlagen und Blueprints, und sie synchronisieren sich ohne zusätzlichen Aufwand automatisch in die Agent-365-Registry. Ein Foundry-Agent ist also überall dort ein vollwertiges Mitglied, wo der Preview-Zugang besteht, und nicht einer, den Sie nur aus der Ferne sehen können.

Die ehrliche Einschränkung ist das Wort Preview. Foundry, zum Zeitpunkt der Session an manchen Stellen noch unter seiner älteren Bezeichnung Azure AI Services geführt, ist noch nicht in einem gefestigten Zustand allgemeiner Verfügbarkeit für alle, und die Sichtbarkeit hängt von Ihrer Anmeldung ab. Wenn Sie auf Foundry aufbauen oder es planen, bestätigen Sie Ihre Preview-Anmeldung und prüfen Sie dann in Ihrem eigenen Tenant, dass die Agenten, die Sie steuern möchten, tatsächlich erscheinen und die von Ihnen benötigten Kontrollen erhalten. Die native Tiefe ist real, aber sehen Sie sie in Ihrer eigenen Umgebung wirken, bevor Sie von voller Abdeckung ausgehen.

Hinter diesem praktischen steckt ein strategischer Punkt. Die Bereiche, in denen Agent 365 am stärksten ist, Microsoft 365 Copilot, Copilot Studio und Foundry, sind zugleich die Bereiche, die Ihren Microsoft-nativen Fußabdruck vertiefen. Das ist in Ordnung, wenn eine reine Microsoft-Agentenstrategie wirklich das ist, was Sie wollen. Es lohnt sich innezuhalten, wenn Sie auch erwarten, Agenten auf anderen Plattformen zu betreiben, denn die Governance, die Sie für Foundry erhalten, erstreckt sich nicht in gleicher Weise auf sie. Starke native Abdeckung und Konzentration auf einen einzigen Anbieter sind zwei Seiten derselben Medaille, wägen Sie also die Tiefe gegen die Richtung ab, die Ihre Umgebung nehmen soll.

Können eigene Agenten, die außerhalb von Microsoft gebaut, aber Teil unserer eigenen Infrastruktur sind, von Agent 365 gesteuert werden?

Das ist die wichtigste Frage für Organisationen mit mehreren Plattformen, und die Antwort hängt vollständig von der Plattform ab, von der der Agent stammt.

Vier Drittanbieter-Plattformen werden von Haus aus unterstützt: Vertex, Bedrock, Databricks und Salesforce. Agenten dieser Plattformen lassen sich über Registry-Sync in Agent 365 holen, sodass sie auffindbar sind und bis zu einem gewissen Grad verwaltet werden können. Bei jedem anderen Anbieter hängt die Kontrolle von einem Software Development Kit ab. Das SDK ist kostenlos und framework-agnostisch, was wirklich gut ist, doch der Anbieter muss sich dafür entscheiden und es bei Microsoft veröffentlichen, damit seine Agenten an Ihre Kontrollebene angebunden werden können. Tut der Anbieter das, erhalten Sie Kontrolle. Tut er es nicht, bleibt Ihnen nur die Erkennung über Netzwerk und Endpunkt. Sie sehen, dass der Agent existiert, aber Sie können ihn nicht absichern oder Laufzeitkontrollen auf ihn anwenden.

Das bedeutet in der Praxis Folgendes. Die meisten Agenten da draußen sind heute wahrscheinlich überberechtigt, und ein großer Teil von ihnen liegt außerhalb dieser vier unterstützten Plattformen. Beliebte Optionen wie Gemini, Claude und Agenten auf OpenAI-Basis fallen in den reinen Erkennungsbereich, solange ihre Anbieter kein SDK veröffentlichen. Das ist eine strukturelle Folge davon, wie Laufzeitkontrolle funktioniert, kein vorübergehender Fehler. Kein Anbieter kann Laufzeit-Governance auf der Infrastruktur eines anderen Anbieters durchsetzen, also kann Microsoft nicht überwachen, was zur Laufzeit innerhalb eines Google- oder Anthropic-Agenten geschieht, und von außen kann das auch sonst niemand.

Es gibt hier auch einen Anbieter-Anreiz zu verstehen. Weil die Abdeckung von allem jenseits der vier unterstützten Plattformen davon abhängt, dass der Anbieter sich entscheidet, ein SDK zu veröffentlichen, sind Sie darauf angewiesen, dass ein Wettbewerber von Microsoft es in seinem Interesse sieht, sich an Microsofts Kontrollebene anzubinden. Manche werden es tun, manche nicht, und der Zeitpunkt liegt nicht in Ihrer Hand. Mehrere dieser Wettbewerber integrieren die Agent-Governance zudem in ihren eigenen Seat-Preis, statt sie separat zu berechnen, sodass ihr kommerzieller Anreiz darin besteht, die Governance in der eigenen Plattform zu behalten und sie nicht an Microsoft abzugeben. Diese Dynamik dürfte sich nicht schnell auflösen, weshalb der reine Erkennungsmodus ein dauerhafter Zustand ist, für den man planen sollte, statt einer Lücke, die sich von selbst schließt.

Der praktische Schritt hier ist ein ehrliches Audit Ihrer eigenen Agentenlandschaft. Sortieren Sie Ihre Plattformen in drei Kategorien: nativ abgedeckt, über ein veröffentlichtes SDK abdeckbar und nur erkennbar. Allein diese Übung zeigt Ihnen, wie viel Ihrer tatsächlichen Umgebung Agent 365 steuern kann und wie viel davon eine andere Antwort braucht. Für die meisten Unternehmen ist die Kategorie der nur erkennbaren Agenten größer als erwartet, und genau das ist die Lücke, die eine anbieterneutrale Governance-Ebene schließen soll.

Wie handhabt Agent 365 die Governance von Agent-Builder-Agenten?

Agent-Builder-Agenten sind auffindbar, sie erscheinen also in Ihrem Inventory, doch Sie können auf sie keine Kontrollen aus Entra, Defender oder Purview durchsetzen. Das Durchsetzen dieser Kontrollen erfordert eine Entra Agent ID, und deklarative Agenten, wozu sowohl Agent-Builder-Agenten als auch SharePoint-Agenten gehören, erhalten keine.

Es gibt hier auch einen Lizenzierungsaspekt, der weiter unten behandelt wird. Agent-Builder-Agenten sind genau der Fall, in dem Sie, um sie über Rencore zu steuern, eine einzige Agent-365-Lizenz benötigen. Es sind auch die Agenten, die am ehesten von gewöhnlichen Nutzern statt von Power-Usern gebaut werden, weshalb sie genau für das Risiko von Oversharing und Schatten-KI relevant sind und genau dort, wo Sie Absicherung über die native Ebene hinaus wünschen.

Identität und die Entra Agent ID

Erfüllt das Verschieben eines Agenten von einer Umgebung in eine andere die Anforderung, ihn für eine Agent ID neu zu erstellen?

Um die Kontrolle über einen Agenten zu übernehmen, brauchen Sie eine Entra Agent ID, und bestehende Agenten tragen keine. Das ist die Wurzel der Anforderung zur Neuerstellung, und diese Frage drehte sich darum, ob ein Umgebungswechsel als Neuerstellung zählt.

Bei einem einfachen Copilot-Studio-Agenten sollte das Neuerstellen oder erneute Veröffentlichen genügen und ihn mit einer Identität in den Geltungsbereich bringen. Das Verschieben eines Agenten von einer Umgebung in eine andere ist weniger eindeutig, denn es hängt davon ab, was der Wechsel tatsächlich überträgt. Das wahrscheinliche Verhalten ist, dass der Agent depubliziert und dann in der neuen Umgebung erneut veröffentlicht wird, und genau dieser Schritt des erneuten Veröffentlichens würde ihm eine neue Identität geben. Ein Übergang zwischen Umgebungen kann die Anforderung also erfüllen, aber nur insoweit, als er ein echtes erneutes Veröffentlichen auslöst und nicht ein bloßes Kopieren des bestehenden Objekts.

Einen Teil können wir nicht bestätigen. Agentenfähigkeiten, die in Power-Platform-Lösungen verschachtelt sind, wurden während der Session nicht getestet, sodass unbestätigt ist, ob eine über eine Lösung geerbte Agentenfähigkeit beim Übergang eine Agent ID erhält. Behandeln Sie diesen konkreten Fall als etwas, das Sie selbst prüfen sollten, statt es anzunehmen.

Das hängt mit einem der größeren Abdeckungsprobleme zusammen. Die Anforderung zur Neuerstellung ist ein realer Migrationsaufwand, und sie trifft genau die Agenten am härtesten, von denen Sie bereits abhängen. Custom-Engine-Agenten, die vor der Existenz der Agent ID gebaut wurden, müssen neu erstellt werden, um überhaupt in den Geltungsbereich zu kommen. Deklarative Agenten, einschließlich SharePoint-Agenten, können selbst nach der Neuerstellung keine Entra Agent ID erhalten, sie bleiben also sichtbar, aber ungeregelt. Inventarisieren Sie daher zuerst Ihre bestehenden Agenten, trennen Sie die, die sich für eine ID neu erstellen lassen, von denen, bei denen das nie gelingt, planen Sie die Neuerstellungsarbeit für die einen und entscheiden Sie, wie Sie die anderen steuern werden, denn Agent 365 allein wird es nicht tun.

Hier zeigt sich auch der Unterschied zwischen den beiden Ansätzen am deutlichsten. Agent 365 verlangt von Ihnen, Agenten in sein Modell zu bringen, was für Alt- und deklarative Agenten Neuerstellung bedeutet oder, im Fall von SharePoint-Agenten, gar keine volle Abdeckung. Eine Governance-Ebene oberhalb der Plattform beginnt andersherum und steuert die Umgebung, die Sie bereits haben, so wie sie ist, ohne dass Sie sie erst neu aufbauen müssen. Wenn ein großer Teil Ihrer Agenten älter ist als die Agent ID oder von gewöhnlichen Nutzern statt von Power-Usern gebaut wurde, ist dieser Unterschied im Ausgangspunkt nicht akademisch. Er entscheidet, wie viel unglamouröse Migrationsarbeit auf Ihr Team zukommt, bevor Sie überhaupt irgendeine Kontrolle erhalten.

Wenn in Gemini oder Claude gebaute Agenten Managed Identities aus Entra ID haben, sind sie im Microsoft Admin Center auffindbar?

Eine Managed Identity ist nicht dasselbe wie eine Entra Agent ID, und diese Unterscheidung ist die ganze Antwort. Ein Agent mit einer Managed Identity würde höchstwahrscheinlich als App in Ihrer Entra-ID-Registry erscheinen, aber er würde nicht in Agent 365 auftauchen, nur in Entra ID selbst.

Nach aktueller Erfahrung sind die einzigen Wege, einen Agenten in Agent 365 anzuzeigen und zu steuern, dass er eine Entra Agent ID trägt oder dass seine Drittanbieter-Plattform über das SDK angebunden ist. Irgendeine Form von Entra-Identität an einem Gemini- oder Claude-Agenten bringt ihn für sich genommen nicht in die Kontrollebene von Agent 365. Das ist dieselbe Drittanbieter-Grenze aus einem anderen Blickwinkel, und es lohnt sich, das gegen Ihre eigene Umgebung zu prüfen, wenn Sie sich auf Managed Identities verlassen, um Nicht-Microsoft-Agenten im Blick zu behalten.

Lizenzierung und Kosten

Welche Rencore-Funktionalität benötigt eine Agent-365-Lizenz, und welche Purview-Lizenzen braucht Rencore?

Diese Frage legt die Kostenposition fest, hier also genau. Ohne Purview haben Sie in Rencore keine Sensitivity Labels, doch davon abgesehen ist alles mit Standard-E3-Lizenzen verfügbar. Um speziell Agent-Builder-Agenten zu steuern, benötigen Sie eine einzige Agent-365-Lizenz. Für Copilot-Studio-Agenten und Microsoft-Foundry-Agenten ist Agent 365 überhaupt nicht erforderlich.

Die praktische Bedeutung ist erheblich. Sie müssen nicht jeden Nutzer für Agent 365 lizenzieren, um Agentendaten in Rencore zu holen. Eine einzige Agent-365-Lizenz deckt den Agent-Builder-Fall ab, die leistungsfähigeren Copilot-Studio- und Foundry-Agenten benötigen keine, und der Rest der Plattform läuft mit den E3-Lizenzen, die Sie ohnehin haben. Das ist der Unterschied zwischen kalkulierbaren, vorhersehbaren Kosten und dem uferlosen Lizenzierungswildwuchs, der Agent 365 für sich genommen schwer budgetierbar macht. Es ist auch der Grund, warum die beiden gut zusammenpassen, statt zu konkurrieren.

Die Arbeit mit Rencore neben Agent 365

Sind die Agentendaten, die Rencore anzeigt, in Echtzeit, oder stammen sie aus exportierten Berichten?

Rencore scannt täglich, wöchentlich oder monatlich über die Microsoft Graph API, und die Ergebnisse jedes Scans werden in das Rencore Inventory veröffentlicht. Die Daten sind nicht nahezu in Echtzeit, und das ist eine bewusste Designentscheidung, keine Einschränkung. Eine vollständige Echtzeitanzeige würde an die Bandbreitengrenzen der API stoßen, daher ist ein geplanter Scan der nachhaltige Weg, ein vollständiges Inventar über eine große Umgebung hinweg aktuell zu halten.

Für Governance ist das der richtige Kompromiss. Sie bauen ein fortlaufend gepflegtes Inventar und Entitätsmodell auf, über das Sie berichten und gegen das Sie Richtlinien schreiben können, nicht einen Live-Monitoring-Stream. Wenn Sie eine bestimmte Ansicht früher aktualisiert brauchen, ist die Scan-Frequenz konfigurierbar, sodass Sie einstellen können, wie oft jeder Dienst erfasst wird, passend dazu, wie schnell sich dieser Teil Ihrer Umgebung ändert.

Kann Rencore die Lebenszyklus-Bereinigung ungenutzter Agenten automatisieren, einschließlich ihrer App-Registrierungen, Berechtigungen und Identitäten?

Die Frage stellte zu Recht fest, dass die Massenbereinigung von Agenten in Agent 365 derzeit sehr begrenzt ist, und fragte, ob Rencore ein automatisiertes Lebenszyklus-Management bieten könnte, das ungenutzte Agenten und die zugehörigen Ressourcen anhand konfigurierbarer Governance-Kriterien erkennt und entfernt. Genau das wollte die Demo zeigen.

Rencore deckt den gesamten Lebenszyklus von der Erstellung bis zur Stilllegung ab, nicht nur den Einblick. Jede Ressource, ein Agent eingeschlossen, kann von einer Richtlinie erfasst werden, wenn sie gegen eine von Ihnen definierte Einstellung verstößt, und dieser Verstoß kann einen automatisierten Workflow auslösen. Für Agenten gehören zu den verfügbaren Aktionen das Blockieren oder Entsperren, das Depublizieren und das Neuzuweisen oder Übergeben der Verantwortung. Diese Workflows können vollautomatisch laufen oder einen menschlichen Schritt wie eine Genehmigung über eine Teams-App an den Besitzer des Agenten weiterleiten, die sich wie Teams anfühlt und aussieht. Konfigurierbare, richtliniengesteuerte Bereinigung ungenutzter oder nicht konformer Agenten ist also ein Kernbestandteil dessen, was Rencore zusätzlich zu Agent 365 bietet, und kein Feature auf einer Roadmap.

Was wir am Tag nicht klären konnten

Nicht alles ließ sich sauber klären, und es ist fair zu benennen, was offen blieb. Ein Teilnehmer, der nur die Rolle AI Administrator hatte, konnte Teile der Agent-365-Erfahrung, die wir vorführten, nicht sehen, darunter die Menüs Tools, Devices und Marketplace, und empfand den Durchlauf verständlicherweise als schwer nachvollziehbar ohne den richtigen Sicherheitskontext. Das ist ein berechtigter Einwand. Die ehrliche Antwort ist, dass wir die genaue Rolle, die für die volle Sichtbarkeit nötig ist, nicht auf der Stelle bestätigen konnten, und Microsoft hat sie noch nicht klar dokumentiert. Wir gehen dem direkt mit den Personen nach, die es angesprochen haben, und teilen, was wir herausfinden.

So nutzen Sie diese Antworten

Keine dieser Antworten ist ein Grund, Agent 365 zu meiden. Es ist eine vernünftige Basis, und für native und neu gebaute Agenten eine wirklich starke. Lesen Sie sie stattdessen als Karte davon, wo die Basis endet, damit Sie für die Bereiche planen können, die es nicht abdeckt, bevor diese zum Problem werden. Die Organisationen, die den Wildwuchs an Agenten gut in den Griff bekommen, sind jene, die heute wissen, welche ihrer Agenten nativ sind, welche Alt-Agenten, welche von Fachanwendern gebaut wurden und welche auf anderen Plattformen leben, und für jede einen Plan haben.

Jede dieser Antworten führt zurück zur selben Schlussfolgerung. Agent 365 ist eine starke Basis für native, neu gebaute Agenten, und es gibt mehr zu planen bei Alt-, von Fachanwendern gebauten und plattformübergreifenden Agenten. Für die vollständige Argumentation lesen Sie den Deep-Insights-Rückblick.

Zuletzt aktualisiert am 27. Juli 2026