Das Wichtigste in Kürze
- Eine Anmeldegruppe (zum Beispiel eine Gruppe für App-Nutzer) schützt nur die Shell. Sie steht nicht für jede Produktberechtigung.
- App-Rollen der Backend-API regeln den Zugriff auf Agents und auf Wissenskategorien. Prüfe sie bei jedem sensiblen Aufruf.
- Ein einziges Autorisierungsmodul bedient Agent-Liste, Chat, Browse und das Lesen von Inhalten.
- Die SPA nutzt Capability-Endpunkte. Sie liest keine Rollen aus dem JWT.
- Zitate und Downloads folgen denselben Pfadregeln wie der Chat. Etwas in der UI auszublenden ist keine Grenze.
- Dokumentiere und teste Ableitungsregeln (Verwalten kann Nutzen einschließen), auch für Nutzer, die nur Basisrollen haben.
Die meisten Demos von KI-Apps packen drei verschiedene Fragen in einen einzigen Login-Button:
- Darf diese Person die Shell öffnen?
- Mit welchen Agents darf sie sprechen?
- Welches Wissen darf sie sehen, herunterladen oder als Grundlage für Antworten nutzen?
In einer echten Agent-Webapp im Unternehmen sind das drei verschiedene Kontrollebenen. Wer sie als eine behandelt, bekommt entweder eine Sicherheitslücke oder einen Albtraum im Support.
App-Zugriff beantwortet Authentifizierung und Anwesenheit. Agent-Zugriff beantwortet Autorisierung und Umfang.
Benanntes Modell: Eingang · Katalog · Korpus
- Eingang (App-Zugriff): Microsoft Entra entscheidet, ob du dich bei der SPA anmelden darfst (Gruppenzuweisung, Conditional Access, Netzwerkregeln). Das beweist nur, dass du ins Gebäude darfst.
- Katalog (Agent-Zugriff): Die API entscheidet, welche Agents erscheinen und welche Chat-Streams erlaubt sind. Das gehört in App-Rollen (oder gleichwertige Claims) auf der Ressourcen-API.
- Korpus (Wissenszugriff): Browse, Download, Upload, Reindex und das Abrufen von Zitaten folgen denselben Berechtigungsregeln wie der Chat.
- Vertrag: ein Autorisierungsmodul. Die SPA zeigt die Fähigkeiten, die die API bereits gefiltert hat. Anmelden ist notwendig. Es reicht nicht aus.
Abbildung 1. Eingang, Katalog, Korpus. App-Zugriff ist Anwesenheit. Agent-Zugriff ist Umfang. Wissen ist kein unverbindlicher Hinweis in der UI.
Kontext und Rahmenbedingung
Das Muster gilt für jeden Eingang zu Agents. Die Chat-Oberfläche wirkt so einfach wie eine Consumer-App. Das Berechtigungsmodell muss sich trotzdem wie ein Unternehmenssystem verhalten.
Wenn der Chat gesperrt ist, der Download von Inhalten aber jedem angemeldeten Nutzer offensteht, hast du keine Wissensgrenze. Du hast einen Vorschlag in der UI. Abbildung 1 ist die Aufteilung, die ich in einem Architektur-Review verteidigen würde. Abbildung 2 ist die Erinnerung aus Learn, dass ein Token aus der SPA nicht das Ende der Autorisierung ist.
Abbildung 2. Eine SPA ruft eine Web-API auf. Die Authentifizierung bringt dir ein Token, die Autorisierung muss trotzdem auf der API passieren. Quelle: Microsoft Learn: Authentifizierungsflows und App-Szenarien.
Design
1. Eine Anmeldeprüfung für die Shell
Halte eine klare Zuweisung für "wer darf die App überhaupt nutzen" (oft eine einzige Anmeldegruppe auf der SPA). Dynamische Gruppen sind in Ordnung, wenn die Regel für die ganze Organisation gilt. Überlade diese Gruppe nicht mit jeder eingeschränkten Berechtigung. Ihre Aufgabe ist der Eingang.
2. App-Rollen auf der Backend-API für das, was du tun darfst
Ordne Rollen Fähigkeiten zu, nicht Bildschirmen:
- Rollen, die "darf Agent A nutzen" bedeuten
- Rollen, die "darf Wissenskategorie A verwalten" bedeuten
- ein Break-Glass-Admin, der beides einschließt, wo das gewollt ist
Setze das auf der API durch. Filtere GET /api/agents, damit der Katalog, den die UI zeigt, schon ehrlich ist. Gib beim Chat 403 zurück, wenn jemand an Agent-IDs herumspielt. Blende nicht nur den Button aus und nenne das Sicherheit. Abbildung 3 zeigt die Produktoberfläche, auf der diese Rollen deklariert werden. Abbildung 4 zeigt die Aufteilung der Zuständigkeit, die die Durchsetzung auf der API hält.
Abbildung 3. Deklariere App-Rollen in der App-Registrierung der API und weise sie dann Nutzern oder Gruppen zu. Quelle: Microsoft Learn: App-Rollen hinzufügen.
Abbildung 4. Ein ehrlicher Katalog. Die API filtert. Die SPA zeigt an. Nur in der UI auszublenden, während die API offen ist, ist Sicherheitstheater.
3. Das Frontend spricht in Fähigkeiten, nicht in JWTs
Die SPA sollte die API fragen "was darf ich verwalten oder durchsuchen?" und genau das anzeigen. Rollen im Browser zu dekodieren dupliziert die Richtlinie, und die Kopien laufen auseinander. Ein Zugriffs-Payload ist besser als drei Kopien von Rollen-Konstanten in React.
4. Verwalten kann Nutzen einschließen, aber bewusst
Wer eine eingeschränkte Wissenskategorie verwalten darf, braucht meist auch den passenden Agent. Lege das als ausdrückliche Ableitung in einem einzigen Autorisierungsdienst fest, nicht als Stammeswissen. Nutzer mit nur Basisrollen dürfen eingeschränkte Kategorien nie sehen, weder beim Browsen noch beim Download noch im Umfang des Retrievals.
5. Zitate sind ein Zugriffsweg
Nutzer öffnen das Dokument, das das Modell zitiert hat. Wenn dieser Blob-Endpunkt die Pfadregeln von Browse ignoriert, ist deine Geschichte vom "eingeschränkten Wissen" Theater. Schütze das Lesen von Inhalten so, wie du den Chat schützt. Abbildung 5 zeigt die gemeinsame Prüfung.
Abbildung 5. Chat, Browse und zitierte Blobs folgen denselben Berechtigungsregeln. Browse offen und Chat gesperrt heißt: dieselben Daten durch eine andere Tür.
Häufige Fehler
Angemeldet = vertrauenswürdig. Alle, die sich anmelden können, können die App öffnen, also sehen alle jeden Agent und jeden Ordner. Das ist der Stand einer Demo, nicht der Stand für Produktion.
Überall Gruppen, nirgends Rollen. Verschachtelte Entra-Gruppen für jede Kategorie wirken flexibel, bis Graph-Abfragen, Token-Größe und "warum wird mein Zugriff nicht aktualisiert" das Backlog beherrschen. Nimm für Produktfähigkeiten lieber App-Rollen auf der API und nutze Gruppen, um diese Rollen zuzuweisen.
Filtern nur in der UI. Die Agent-Auswahl blendet Optionen aus, die API akzeptiert aber weiterhin jede Agent-ID. Rechne mit einem neugierigen Nutzer und einem Proxy. Abbildung 4 macht genau diesen Fehler sichtbar.
Browse offen, Chat gesperrt. Du hast einen eingeschränkten Agent gesperrt, aber Liste und Download für alle angemeldeten Nutzer offen gelassen. Dieselben Daten, eine andere Tür. Abbildung 5 ist die Warnung.
Verwalten ohne Abrufen (oder umgekehrt), ohne es zu sagen. Entscheide, ob "darf diese Kategorie verwalten" auch "darf den Agent nutzen, der sie liest" bedeutet. Dann schreib es auf und teste es.
So übernehmen oder anpassen
So übernehmen
- Anmeldegruppe = nur die Shell.
- App-Rollen der Backend-API = Agents + Wissenskategorien.
- Ein einziges Autorisierungsmodul für Agent-Liste, Chat, Browse und Inhalte.
- Die SPA nutzt Capability-Endpunkte, keine Auswertung von Rollen im Browser.
- Automatisierte Tests für "nur Basisrollen kann eingeschränkte Pfade weder durchsuchen noch abrufen".
- Ausdrückliche Ableitungsregeln (Verwalten kann Nutzen einschließen), dokumentiert und mit Unit-Tests abgesichert.
Vor dem Einsatz anpassen
Strengere Rollen bedeuten mehr Arbeit in Entra und mehr Testmatrizen (nur Basisrollen, nur Kategorie A, Admin, Break-Glass). Du wirst mit den Verantwortlichen für Identität aushandeln, wer App-Rollen anlegt und wer Gruppen zuweist.
On-behalf-of und Token für mehrere Ressourcen bringen zusätzliche bewegliche Teile. Eine unvollständige Einwilligung zeigt sich als "zufällige" Plattformfehler, die wie Fehler im Modell aussehen.
Netzwerkkontrollen (Private Endpoints, IP-Allowlists) schützen die Ebene. Sie ersetzen nicht die Autorisierung pro Agent. Beide Schichten zählen, sie lösen unterschiedliche Bedrohungen.
Wichtigste Quellen: Microsoft Learn zu Entra App-Rollen, SPA, die eine Web-API aufruft, und zum Prüfen von Scopes und App-Rollen. Nutze die aktuellen Namen von Microsoft Foundry, wenn dein Eingang zu Agents unter diesem Dach liegt.
Eingang. Katalog. Korpus. Drei Fragen. Drei Antworten.