Microsoft 365 liefert Agent Inventory, keine Observability
Die neue Agent-Registry im Microsoft 365 Admin Center (MAC) inventarisiert Copilot-Agenten so, wie eine IT-Asset-Datenbank Laptops inventarisiert. Sie sagt Ihnen, dass der Laptop existiert, wem er gehört und welche Software installiert ist. Sie sagt Ihnen nicht, was der Laptop am Dienstag um 3 Uhr morgens getan hat. Jedes Governance-Deck für Copilot Studio in 2026 spricht über Policy. Fast keines spricht über die Zeilenanzahl in der Agent-Inventory-Tabelle, also das, worauf Ihr Auditor tatsächlich zeigen wird. MAC liefert jetzt diese Tabelle, eine Freigabe-Queue, eine an Azure gebundene Billing-Oberfläche und drei Hebel, die festlegen, wer in Ihrem Tenant Agenten erstellen, konsumieren und teilen darf. Dieser Teil der Geschichte ist real und ungewöhnlich gut umgesetzt.
Für einen Tenant mit ein oder zwei Copilot-Agenten ist die Observability-Lücke akzeptabel. Für eine Flotte ist sie der gesamte Job.
Die Klippe liegt bei der Observability. Die Leute, die echte Agent-Flotten betreiben, und nicht jene, die sie auf der Ignite vorführen, verbringen ihre Nächte an deren Fuß.
In diesem Artikel
- Was Microsoft tatsächlich ausgeliefert hat
- Warum das für die offensichtlichen Probleme funktioniert
- Wo das Modell bricht
- Die Lifecycle-Lücke, die die meisten Posts übersehen
- Was Sie Montagmorgen tun sollten, wenn Sie eine Agent-Flotte betreiben
- Offene Fragen
Microsoft 365 liefert Agent Inventory, keine Observability
Was Microsoft tatsächlich ausgeliefert hat
Die Governance-Oberfläche in MAC besteht aus drei Hebeln, einer Registry, einer Billing-Plane, einer Freigabe-Queue und einer SKU für 15 USD pro Nutzer und Monat. Jedes Teil landet heute an einer konkreten Stelle in der UI. Das Webinar der Microsoft Power Platform Community vom 22.04.2026, "Govern your Copilot agents in the new Admin Center" (Aufzeichnung), führt drei Product Manager live durch die Oberfläche: einer zu Agent-Risiko, einer zu MAC-Lifecycle, einer zu Cost Management. Sie versprechen keine Vision, sie demonstrieren sie. Die Kennzahl, die den Rest der Ökonomie rahmt, steht vorne: der Microsoft Security Blog bestätigt, dass Agent 365 standalone 15 USD pro Nutzer und Monat kostet oder mit E7 gebündelt ist. Tenants auf E3 ohne den Copilot-Stack erhalten eine dünnere Oberfläche. Jeder Business Case startet hier, nicht bei der Registry-Tour.
Hebel eins ist wer. Agent-Extensibility ist ein einzelner Schalter unter Microsoft 365 Admin Center > Copilot > Settings, der Erstellungs-, Konsum- und Sharing-Rechte gemeinsam regelt. Standard sind alle Copilot-lizenzierten Nutzer. Sie können vor jedem gebauten Agenten auf Security Groups oder benannte Personen einschränken. Hebel zwei ist was. Sie können erlaubte Agent-Typen auf beliebige Kombinationen aus Microsoft-zertifizierten Public Agents, Multi-Tenant-ISV-Agenten und internen Line-of-Business-Agenten einschränken. Hebel drei ist wie weit. Nutzer, die nicht auf der freigegebenen Sharing-Liste stehen, sehen die Option "Mit allen in der Organisation teilen" ausgegraut; ihnen bleiben "einige Nutzer" und "nur ich" als einzige Sharing-Optionen. Diese ausgegraute Checkbox ist der Existenzgrund der gesamten Admin-Queue.
Die Registry selbst lebt unter MAC > Agents > All Agents. Microsofts eigene Learn-Dokumentation bestätigt vier Agent-Klassen (Microsoft-built, External Partner, Published by your org, Shared by creator) und drei Zähler, die beim Laden ins Auge fallen: Total Agents, Agents without owners und Unmanaged Agents. Der Zähler für Unmanaged Agents ist der interessanteste. Er ist ein erstklassiges Signal dafür, dass etwas in Ihrem Tenant mit Ihren Daten spricht, ohne dass es im Schutzbereich von Agent 365 läge. Klicken Sie auf eine Zeile und Sie sehen Beschreibung, Knowledge Sources, Entra-gewährte Permissions und die APIs, die der Agent aufruft.
Die Billing-Plane ist Azure, kein separater Metering-Service. Sie erstellen eine Billing Policy, indem Sie ein Azure-Subscription und eine Resource Group verlinken (Sie benötigen Owner oder Contributor auf beiden), sie an User Groups binden, ein optionales Cap setzen und Budget-Alert-Schwellen zum Beispiel bei 50 % des Caps wählen. Die in der UI eingebaute ökonomische Logik ist schärfer, als sie wirkt: 2.000 Copilot-Credits in 30 Tagen entsprechen ungefähr der 30-USD-Unlimited-Copilot-Lizenz. Überschreitet ein Nutzer diese Schwelle, erhält der Admin eine Empfehlung, ihn von variablem PAYG auf eine feste Lizenz umzustellen. Das Pin-Limit liegt bei drei Agenten pro Nutzer. Prepaid-Capacity-Packs (je 25.000 Credits) werden zuerst aufgebraucht, dann übernimmt PAYG, sofern Sie das Fallback nicht explizit deaktivieren. Der Tenant-weite Cap für Credit Policies liegt bei 10. Alle numerischen Limits in diesem Abschnitt stammen von Microsoft Learn, sofern nicht anders angegeben.
Die Freigabe-Queue schließt den Kreis. Maker in Copilot Studio reichen statt direktem Sharing einen "Publish to Tenant"-Request ein. Admins prüfen ausstehende Requests in MAC: Agent-Funktion, Daten und Tools, Security-Posture, benötigte Entra-Permissions. Bei Freigabe wählt der Admin die Empfänger-Nutzer oder -Gruppen und kann den Agenten vorinstallieren, sodass er ohne manuelle Beschaffung in der linken Copilot-Navigation der Nutzer erscheint. Microsofts Copilot-Studio-Update vom April 2026 hat das zum dokumentierten Default gemacht, nicht das direkte Maker-Sharing.
Das ist, was ausgeliefert wurde. Wer genau liest, merkt, dass die Oberfläche intern konsistent ist: Identity, Lifecycle, Distribution und Billing sind an denselben Tenant, dieselben Entra-Principals und dasselbe Azure-Subscription gebunden. Drittanbieter-Tools können diese Bindung nicht replizieren, weil sie nicht die Runtime besitzen.
Warum das für die offensichtlichen Probleme funktioniert
Das Entra-gegroundete Permission-Modell tötet die Panik vor Daten-Leaks durch breites Sharing. Ein geteilter Agent kann nicht erreichen, was sein Aufrufer nicht erreichen kann. Der Agent läuft mit den Permissions des Aufrufers plus dem, was Entra explizit zusätzlich an die Agent-Identity vergeben hat. Das ist die wichtigste Governance-Tatsache der Oberfläche und die, die beim Einstieg am häufigsten falsch verstanden wird.
💡 Agenten erben die Entra-Permissions des Aufrufers plus alles, was der Agent-Identity explizit gewährt wurde. Breites Sharing hört in dem Moment auf, ein Datenleak zu sein, in dem Ihre ACLs korrekt sind, und beginnt eines zu sein, sobald sie es nicht sind.
Entra Agent ID ist am 01.05.2026 GA gegangen. Es ersetzt das Single-App-Registration-Muster durch eine dreistufige Hierarchie: Agent Blueprint als Template, Blueprint Principal als Per-Tenant-Identity, Agent Instance als Runtime. Copilot Studio erstellt pro neuem Agenten automatisch eine Entra-Agent-Identity, sobald das Environment-Feature aktiviert ist. Permissions auf dieser Identity sind nach Provisionierung unveränderlich. Petris Berichterstattung zu Identity als neuer Control Plane liest das korrekt: Identity ist von einer Security-Schicht zur Control Plane für Agenten geworden. Die MAC-Registry liegt downstream dieser Bewegung.
Die Freigabe-Queue schließt das zweite Risiko: Tenant-weite Publikation ohne Review. Die Default-Welt ohne sie, laut Microsofts eigenem (vom Hersteller selbst berichteten) Security-Blog: 80 % der Fortune 500 betreiben aktive AI-Agenten, die mit Low-Code-Tools gebaut wurden, und 29 % der Mitarbeitenden haben unautorisierte Agenten für Arbeit genutzt. Behandeln Sie beide Zahlen als von Microsoft attribuierte Trendaussage, nicht als unabhängig verifiziert. "Mit allen in der Organisation teilen" als Default ist unabhängig von der genauen Häufigkeit ein Ein-Klick-Datenleck. Publikation über eine Admin-Queue zu leiten, mit Entra-Permission-Inspection zum Review-Zeitpunkt, ist die kleinste Intervention, die ein kontinuierliches Risiko in ein diskretes verwandelt.
Billing schließt das dritte: ungedeckelten Konsum. Capacity Packs als Prepaid-Buffer, PAYG als gemeterter Fallback, Budget-Alerts bei 50 % des Caps. Die Roadmap für April 2026 (Agent-level Billing Restrictions, One-Click-Lizenzwechsel und Standalone-Capacity-Pack-Policies mit harten Cutoffs ohne PAYG-Fallback) erweitert die Oberfläche von Per-Tenant auf Per-Agent und von weichen zu harten Caps.
Für einen Tenant, der von null auf zwanzig Copilot-Agenten geht, reicht diese Oberfläche. Die Control Plane ist identitätsgebunden, die Cost Plane ist gemetert, die Publikationsebene ist gegated. Sie können mit dem, was heute in MAC steht, ein Audit bestehen.
Wo das Modell bricht
Die Registry sagt Ihnen, dass ein Agent existiert. Sie sagt Ihnen nicht, was der Agent getan hat. Sobald Sie von "wir haben Agenten" zu "Agenten erledigen Arbeit, die zählt" wechseln, sinkt die Sichtbarkeitsdecke schnell, und fast keines der öffentlichen Materialien ist ehrlich darüber, wo sie liegt.
Beginnen Sie bei der Observability-Lücke. Die Risk Taxonomy in MAC ist konkret (Shadow Agent, No Owner, Excessive Permissions, Security Misconfiguration, Prompt Injection, Sensitive Data Access, Conditional Access Violation, Pending Approval, Operational Exceptions, Compliance Gap) und sie verschmilzt Signale aus Defender, Entra und Purview. Die Latenz der Risk-Spalte beträgt bis zu eine Stunde, und nur hochpriore Events rollen auf. Blockierte oder gefilterte Interaktionen tauchen als generische ContentFiltered-Telemetry auf. Der Admin sieht, dass etwas blockiert wurde, nicht warum, nicht was versucht wurde, nicht welche Daten beinahe ausgelaufen wären. Es gibt kein Per-Request-Prompt-Log, keinen Per-Decision-Diff, keinen Reasoning-Trace. Gartners Dennis Xu scherzt halb darüber, Copilot freitagnachmittags einzuschränken, weil Nutzer Outputs zum Wochenende nicht validieren. Der Witz funktioniert nur, weil das System selbst sie ebenfalls nicht validieren kann.
Das Entra-Permission-Grounding ist korrekt und tragend, und es ist gleichzeitig begrenzt durch das, was Entra weiß. Wenn Ihre SharePoint-Landschaft bereits übergeteilt ist (2toLeads Governance-Übersicht 2026 beziffert das auf 15 % oder mehr der geschäftskritischen Dateien), wird der Agent treu ein Permission-Set respektieren, das selbst das Problem ist. Die Registry visualisiert die Agenten. Sie tut nichts an den darunterliegenden ACLs, die die eigentliche Leak-Quelle sind. Die IBM-Zahl "Cost of a Data Breach 2025" (zusätzliche 670.000 USD pro Breach in Umgebungen mit hoher Shadow-AI-Nutzung) ist das, wie die kaputte-ACL-Welt aussieht, wenn Agenten darauf gerichtet sind.
Der nächste Bruch sind Shadow Agents, die die Registry nicht sehen kann. Das ist nicht dasselbe wie die Microsoft-Statistik "29 % unautorisierte Agenten", denn diese Zahl umfasst jede unautorisierte Nutzung, einschließlich ChatGPT im Browser für eine Arbeitsaufgabe, von denen die meisten nie zu einem persistenten Agenten werden. Die engere Kategorie ist das, was die Registry strukturell niemals enumerieren kann: alles, was auf einer Nicht-Agent-365-Oberfläche gebaut wurde, alles, was über einen generischen Azure-OpenAI-Endpoint mit einem Service Principal verdrahtet ist, alles, was per API-Key zu einem externen LLM geroutet wird. Die zwei Populationen überlappen sich; sie sind nicht identisch. Der MAC-Unmanaged-Agent-Zähler misst die Teilmenge, die Microsoft innerhalb seiner eigenen Runtime erkennen kann. Alles außerhalb dieser Runtime ist nach Kategorie unsichtbar, nicht aus Versehen.
Gegen reine AI Gateways stellt sich das Bild auf den Kopf. Cloudflare AI Gateway, Portkey und LiteLLM arbeiten auf Request-Ebene. Sie loggen Prompts, routen nach Modell, redigieren PII, erkennen Jailbreaks, erzwingen Per-Key-Budgets und produzieren Audit Trails, was gesendet wurde und was zurückkam. Keiner von ihnen weiß, was eine SharePoint-Permission ist. Der Trade ist symmetrisch und es lohnt sich, ihn zu benennen:
| Fähigkeit | MAC / Agent 365 | AI Gateway (Portkey, Cloudflare, LiteLLM) | AWS Bedrock Guardrails |
|---|---|---|---|
| Tenant-weites Agent Inventory | Ja, vier Klassen, Shadow Detection | Nein, nur Per-App-Proxy | Nein |
| Per-Request-Prompt/Response-Log | Nein | Ja | Teilweise, mit Audit |
| Entra-gegroundete User-Permission-Vererbung | Ja | Nein | Nein |
| Content Moderation / Jailbreak Detection | Schwach (ContentFiltered) | Stark | Stark (von AWS berichtete 88 % Block Rate) |
| Cost Caps mit Admin Alerts | Ja, 50 %-Schwelle, Per-Policy-Budgets | Per-Key-Budgets | Ja |
| Lifecycle (Owner Reassignment, Soft Delete) | Teilweise, Soft Delete weiterhin Roadmap | Nein | Nein |
Microsoft besitzt die Identity-und-Lifecycle-Spalte. Gateways besitzen die Per-Request-Forensik-Spalte. Bedrock besitzt die Content-Safety-Spalte. Der ernsthafte Agent-Operator betreibt alle drei und behandelt sie als orthogonal.
Die Lifecycle-Lücke, die die meisten Posts übersehen
Hard Delete in MAC entfernt den Agenten und seine Dateien. Es dreht nichts zurück, was der Agent außerhalb des Tenants geschrieben hat. Das ist der Governance-Bruch, nach dem Enterprise-Audit-Teams tatsächlich fragen, und er liegt eine Schicht unter dem, wo die meisten Launch-Posts aufhören.
Ein Agent, der Tickets nach Jira, Zeilen in ein externes CRM oder Dateien in seinen eigenen Data Container geschrieben hat, lässt all das zurück, wenn die Registry die Agent-Identity löscht. Das Audit im nächsten Quartal wird gegen eine Runtime rekonstruiert, die nicht mehr existiert. Der Admin kann zeigen, dass der Agent deprovisioniert wurde; er kann nicht zeigen, was der Agent vor der Deprovisionierung getan hat oder welche Downstream-Zeilen jetzt einen verwaisten Autor haben. Cross-Tenant-Federation macht es schlimmer: Ein ISV-gebauter Agent, der aus einem Partner-Tenant in Ihren reicht, hinterlässt Seiteneffekte in Ihren Systemen, Audit Trail in ihren, und die Lifecycle-Ownership ist zwischen beiden mehrdeutig. Soft Delete ist auf der Roadmap. Side-Effect Rollback ist es nicht und kann es strukturell vermutlich auch nicht sein, weil der Agent keine transaktionale Sicht auf jedes externe System hat, das er berührt hat.
Der pragmatische Schritt ist anzunehmen, dass jeder Agent, der extern schreibt, ein kleiner ETL-Job in Verkleidung ist. Loggen Sie seine ausgehenden Writes so, wie Sie die einer Pipeline loggen würden, außerhalb von MAC, bevor Sie ihm Write-Scopes geben.
Was Sie Montagmorgen tun sollten, wenn Sie eine Agent-Flotte betreiben
Behandeln Sie MAC als Inventory-Schicht und nehmen Sie an, dass die Request-Forensik-Schicht Ihr Problem ist. Die Falle besteht darin, die Launch-Posts zu lesen und zu schließen, Governance sei gelöst. Ist sie nicht. Die Verdrahtung, die einen echten Audit Trail erzeugt, liegt weiterhin bei Ihnen. Die nachfolgende Reihenfolge nimmt einen Tenant an, in dem Copilot-Lizenzen bereits ausgerollt und mindestens ein Copilot-Studio-Agent live ist.
1. Auditieren Sie zuerst die Registry
Melden Sie sich als AI Admin oder Global Admin unter https://admin.microsoft.com an, gehen Sie zu Copilot > Agents > All Agents. Lesen Sie die drei Zähler oben auf der Seite laut vor. Wenn "Unmanaged Agents" oder "Agents without owners" ungleich null ist, ist das Ihr Tag-Eins-Backlog. Exportieren Sie die vollständige Liste nach Excel; laut Microsoft Learn deckt der Excel-Export bis zu eine Minute Registry-Daten pro Lauf ab, machen Sie es also einmal sauber und versionieren Sie die Datei.
Erwarteter Output: eine CSV mit einer Zeile pro Agent, der Vier-Klassen-Taxonomy, dem Owner-Entra-Principal, Knowledge Sources, gewährten Permissions und Risk-Signalen. Alles, was als Unmanaged oder No owner markiert ist, bekommt am selben Tag ein JIRA-äquivalentes Ticket.
2. Schließen Sie die drei Hebel, bevor Sie Adoption öffnen
Unter MAC > Copilot > Settings schränken Sie Agent Extensibility auf eine Pilot-Security-Group ein, statt auf alle Copilot-lizenzierten Nutzer. Beschränken Sie erlaubte Agent-Typen auf Microsoft-zertifiziert plus interne LOB; verschieben Sie Multi-Tenant-ISV-Agenten, bis Sie einen Inspektionsprozess haben. Schalten Sie organisationsweites Sharing für alle außerhalb der Pilot-Gruppe ab.
# Listet nur Unmanaged Agents, die Teilmenge, die MAC als außerhalb der Schutzhülle markiert
# Diff diesen Output zwischen Läufen; Wachstum in der Unmanaged-Menge ist das eigentliche Signal
curl -H "Authorization: Bearer $TOKEN" \
"https://graph.microsoft.com/beta/copilot/admin/packages?\$filter=class eq 'Unmanaged'" \
| jq '[.value[] | {id, displayName, owner: .owner.userPrincipalName, riskFlags}]'
Erwarteter Output: ein JSON-Array, das nur Unmanaged Packages enthält, ein Objekt pro Agent, mit Owner-UPN und Risk Flags. Wenn die Liste leer ist, aber die MAC-UI Agenten unter "Unmanaged" zeigt, fehlt dem Token der Scope AgentRegistry.Read.All oder die AI-Admin-Rolle. Datieren Sie die Datei und persistieren Sie sie; der Diff Woche über Woche ist das operative Signal, nicht der absolute Zählerstand.
3. Verdrahten Sie die Freigabe-Queue mit einem echten Review
Die Queue ist nur so gut wie der Reviewer. Definieren Sie eine schriftliche Checkliste, bevor der erste Request landet: Welche Daten berührt der Agent, welche Entra-Permissions fordert er über den Aufrufer hinaus an, welche externen APIs ruft er auf, wem gehört er nach Launch. Behandeln Sie den Freigabeschritt wie ein Code Review, nicht wie einen Daumen hoch. 2toLeads Governance-Forschung 2026 berichtet, dass 73 % der befragten Organisationen in regulierten Branchen Governance-Lücken als Hauptgrund für pausierte Copilot-Rollouts nennen; die vier obigen Fragen sind die, die ihre Reviewer für einzelne Agenten konsistent nicht beantworten konnten.
4. Stellen Sie Request-Level-Logging außerhalb von MAC bereit
Das ist der Schritt, den die Plattform nicht für Sie übernimmt. Routen Sie Copilot-Studio-Agenten, die externe APIs aufrufen, über ein AI Gateway (Portkey, LiteLLM self-hosted oder ein Application Gateway mit Logging) für den Per-Prompt-Audit-Trail. Für Agenten, die innerhalb des Microsoft Graph bleiben, ist das nächstgelegene verfügbare Primitive Purview Audit Logs plus Defender for Cloud Apps Activity. Keines zeigt den Prompt-Body, aber zusammen rekonstruieren sie den Request Envelope. Planen Sie eine Zukunft, in der Prompt-Level-Logging Ihre Verantwortung ist, nicht Microsofts.
# Beispiel-Portkey-Konfiguration für ein Copilot-Studio-Outbound-Tool
gateway:
audit:
log_requests: true
log_responses: true
redact_pii: true
budget:
monthly_usd_cap: 500
alert_at_pct: 50
routing:
primary: azure-openai-gpt-4o
fallback: claude-sonnet-4-7
Erwarteter Output: jeder ausgehende LLM-Call wird mit Prompt, Response, Latenz, Kosten und PII-Flags erfasst. Sie können "was hat Agent X um 14:32 zu Nutzer Y gesagt?" beantworten, ohne ein Microsoft-Support-Ticket einzureichen.
5. Binden Sie die Billing-Plane, bevor Sie PAYG einschalten
Erstellen Sie eine Billing Policy unter MAC > Copilot > Billing, verknüpft mit einem Azure-Subscription und einer Resource Group, auf denen Sie Contributor oder Owner haben. Setzen Sie einen monatlichen Cap. Setzen Sie die E-Mail-Alert-Schwelle auf 50 % des Caps, nicht auf 80 %. Aktivieren Sie Capacity Packs als primäre Konsumquelle, falls Sie welche gekauft haben (25.000 Credits pro Pack pro Monat), mit PAYG als Fallback. Sobald die Standalone-Credit-Policies aus April 2026 in Ihrem Tenant verfügbar sind, schalten Sie die Policies, die Prepaid nicht überschreiten sollen, in den Hard-Cap-Modus. Der Cap von 10 Policies pro Tenant ist die bindende Restriktion dafür, wie granular Ihre Gruppenstruktur sein kann.
6. Planen Sie für Shadow Agents, die Sie nie sehen werden
Der MAC-Unmanaged-Agent-Zähler ist ein Floor für eine Kategorie, die die Registry strukturell sehen kann; alles in der weiteren unautorisierten-Nutzung-Population (Browser-ChatGPT, BYO-API-Keys, Nicht-Microsoft-Plattformen) liegt komplett außerhalb dieser Grenze. Ergänzen Sie eine Conditional-Access-Policy, die für jedes Azure-OpenAI-Deployment in Ihrem Tenant benannte Service Principals verlangt, und routen Sie DNS für bekannte Drittanbieter-LLM-Endpoints über einen Logging Proxy. Das ist keine Microsoft-Feature-Lücke; es ist eine Kategoriengrenze. Die Registry kann nur sehen, was sie besitzt.
7. Wiederholen Sie Schritte 1 bis 6 alle 30 Tage
Forresters Daten zur Enterprise-Copilot-Adoption verorten die meisten Enterprise-Tenants 12 bis 18 Monate von skaliertem Produktiv-Deployment entfernt, also der Lücke zwischen "Copilot-Lizenzen gekauft" und "Agenten leisten sinnvolle Arbeit unter verteidigbarer Governance". Forresters Rahmung ist schärfer als die Zeitachse: Governance entscheidet, wer skaliert und wer stehen bleibt. Die Registry-Sicht driftet. Ownership ändert sich. Neue Agent-Klassen werden ausgeliefert. Behandeln Sie Governance als wiederkehrenden Batch Job, nicht als Launch-Aufgabe. Die Teams, die in Woche 6 bis 12 stehen bleiben, sind die Teams, die das einmal gemacht haben. Einmal ist ein Launch, kein Programm.
Offene Fragen
Drei Unsicherheiten liegen direkt unter der Oberfläche dessen, was ausgeliefert wurde, und der ehrliche Befund ist, dass keine davon vor Ende 2026 aus öffentlichem Material aufgelöst wird.
Erstens: Prompt-Body-Logging. Microsoft hat nicht gesagt, ob der Per-Request-Prompt- und -Response-Payload jemals als erstklassiger Log-Typ in MAC oder Purview landen wird. Die aktuelle ContentFiltered-Telemetry deutet darauf hin, dass die Architekturentscheidung bewusst war. Bleibt das so, wird das AI-Gateway-als-zweite-Schicht-Muster aus Schritt 4 permanent, nicht transitorisch. Die Gegenwette ist, dass regulatorischer Druck (Hochrisiko-Klassifikation des EU AI Act, Audit-Mandate auf US-Bundesstaatenebene) die Oberfläche bis Mitte 2027 ins Produkt zwingt. Beide Ausgänge schreiben die Buy-vs-Wire-Entscheidung neu.
Zweitens: die dreistufige Entra-Agent-ID-Hierarchie unter Cross-Tenant-Federation. Blueprint, Principal und Instance sind innerhalb eines Tenants sauber. In dem Moment, in dem ein ISV-gebauter Agent aus einem Partner-Tenant in Ihren reicht, muss das Identity-Modell antworten, wessen Conditional-Access-Policies gelten, wessen Audit Log das Event fängt und wessen Lifecycle die Seiteneffekte besitzt. Die Docs decken den Single-Tenant-Fall detailliert ab. Der föderierte Fall fehlt. Jeder, der ein ernsthaftes ISV-Ökosystem betreibt, wird das treffen, bevor Microsoft es dokumentiert.
Drittens: der Bedrock- und Google-Cloud-Agent-Registry-Sync, den Microsoft als Public Preview angekündigt hat. Wenn er in GA-Qualität ausgeliefert wird, wird MAC zum De-facto-Cross-Cloud-Agent-Inventory, und die Vergleichstabelle in diesem Post muss neu geschrieben werden. Wenn er dünn ausgeliefert wird (Read-Only, keine Lifecycle-Aktionen, keine Risk Fusion), hält die Tabelle. Die Roadmap der Lifecycle-Aktionen (Start, Stop, Delete auf Drittanbieter-Agenten) ist der Indikator. Beobachten Sie das, nicht das Marketing.
Takeaways.
- Die MAC-Governance-Oberfläche ist real, intern konsistent und für ein Microsoft-Feature dieses jungen Alters ungewöhnlich gut an Identity und Billing gebunden.
- Entra-gegroundete Permissions lösen die Panik vor Daten-Leaks durch breites Sharing; Agenten erben Aufruferrechte und nichts darüber hinaus.
- Die Registry inventarisiert Agenten; sie loggt nicht, was sie getan haben. Per-Request-Forensik ist weiterhin Ihre Aufgabe.
- Hard Delete entfernt den Agenten, nicht seine Seiteneffekte. Behandeln Sie jeden extern schreibenden Agenten als ETL Job und loggen Sie seine ausgehenden Writes außerhalb von MAC.
- Der Unmanaged-Agent-Zähler ist ein Floor für die Teilmenge, die Microsoft erkennen kann; die breitere unautorisierte-Nutzung-Population liegt strukturell außerhalb der Sicht der Registry.
- Für echte Flotten: betreiben Sie MAC für Lifecycle, ein AI Gateway für Per-Request-Logs und Content Guardrails als dritte Schicht; behandeln Sie sie als orthogonal.
Wenn Sie eine Copilot-Agent-Flotte betreiben, die die Linie von "wir haben ein paar" zu "wir haben eine Registry, die scrollt" überschritten hat, werden die operativen Fragen schnell scharf. Wo landen Ihre Prompt Logs? Welche Ihrer bestehenden SharePoint-Permissions werden im nächsten Quartal durch einen freigegebenen Agenten verstärkt? Jemand ist Rufbereitschaft, wenn der Unmanaged-Agent-Zähler um 2 Uhr morgens hochzählt, und diese Person braucht ein Runbook. Ich arbeite mich aktuell mit Teams, die in Microsoft-Tenants ausliefern, durch die gleichen Fragen. Melden Sie sich, wenn Sie Notizen abgleichen möchten, besonders mit Gegenbeweisen zur Observability-Lücke. Der schnellste Weg, mein Denken zu aktualisieren, ist ein konkretes Beispiel eines Audits, das Ihr Team allein mit MAC bestanden hat, mit Zahlen, was Ihre Reviewer verlangt haben und was die Registry darauf geliefert hat.