Wer eine Bestellung liest, muss noch keine E-Mail versenden dürfen
Ein Kunde möchte wissen, wann Bestellung 4711 eintrifft. Für diese Übung verwenden wir eine erfundene Bestellung und folgen der Arbeit einer Servicekollegin, die diese Frage beantworten muss. Der vorgesehene Agent liest den freigegebenen Datensatz und bereitet eine Antwort vor. Die Kollegin kann den Status prüfen, bevor sie dem Kunden schreibt.
Zum Prüfen des Entwurfs braucht die Kollegin den hinterlegten Lieferstatus. Um ihn vorzubereiten, muss der Agent weder das Systempasswort kennen noch die Bestellung ändern oder an eine andere Adresse schreiben dürfen. Ein großzügig angebundenes Werkzeug könnte ihm trotzdem all das erlauben. Deshalb würden wir zuerst vereinbaren, welche Unterstützung die Kollegin braucht, und anschließend nur die erlaubte Arbeit dieser Rolle anbinden.
OWASP empfiehlt, Funktionen und Rechte von Werkzeugen zu begrenzen und Berechtigungen außerhalb des Sprachmodells zu prüfen.[S1] Im Beispiel muss das Bestellsystem einen unberechtigten Zugriff also auch dann ablehnen, wenn der Agent überzeugend danach fragt.
Eine Agentenidentität ist etwas anderes als ein Passwort im Chat
Drei Fragen werden leicht vermischt: Wer handelt? Wie meldet sich die Verbindung an? Was darf die einzelne Anfrage auslösen? Eine Identität macht den Aufrufer für das System und seine Administratoren erkennbar. Ein Passwort, Token oder API-Schlüssel dient zur Anmeldung. Berechtigungen bestimmen den anschließenden Zugriff. Keine dieser Entscheidungen ersetzt die anderen.
Copilot Studio erstellt und verwaltet Agentenidentitäten automatisch, wie Microsoft dokumentiert.[S2] Das erklärt, wie die Plattform ihre Agenten erkennt; es legt noch nicht die Rechte jeder Verbindung fest. Für die Bestellanfrage würden wir die Anmeldung von der Verbindung übernehmen lassen, ohne deren Geheimnisse im Chat oder in lesbaren Dateien des Modells offenzulegen.[S3] Die tatsächlichen Zugriffe muss die systemverantwortliche Person trotzdem prüfen. Ein eigenes Benutzerkonto für jeden Agenten ist keine allgemeingültige Vorgabe.
Lassen Sie die IT für die Übung einen einzelnen Bestellabruf nachvollziehen. Welche Verbindung führt ihn aus? Mit wessen Rechten? Können die Werkzeuge des Agenten den Schlüssel aus einer Datei oder Variable auslesen? Könnte dieselbe Verbindung auch die Bestellung eines anderen Kunden abrufen? Halten Sie diese Antworten neben der Rollenbeschreibung fest. So sprechen Serviceleitung und Systemverantwortliche über denselben Zugriff.
Die Verbindung übernimmt die Anmeldung, der Auftrag bleibt begrenzt
Eine verwaltete Verbindung oder ein zentraler Zugangsdienst, oft Gateway genannt, kann die Anmeldung und den freigegebenen Aufruf übernehmen. Der Agent fragt nach dem Lieferstatus. Der Dienst prüft die Anfrage und spricht mit dem Bestellsystem. Das Modell erhält die nötigen Informationen für seinen Entwurf statt eines Passworts zur freien Verwendung.
Auch dieser Aufbau braucht passende Einstellungen. Microsoft unterscheidet Risiken durch eingebettete Geheimnisse, Anmeldungen über das Konto des Erstellers und dynamisch gewählte E-Mail-Empfänger.[S3] Sicher gespeicherte Zugangsdaten können weiterhin zu viele Rechte eröffnen. Wie eng ein Werkzeug namens „Bestellung lesen“ begrenzt ist, entscheidet seine tatsächliche Funktion samt Berechtigungen.
Die Kollegin sollte wissen, welche Unterstützung sie nach dem Abruf erwarten kann. Für Bestellung 4711 würden wir die folgenden Grenzen vereinbaren: Der Agent liest den erlaubten Status und legt einen Entwurf ab; den Versand behält die Kollegin. Die Grafik führt durch dieselben Aktionen.
| Angefragte Arbeit | Grenze in diesem Beispiel |
|---|---|
| Status von Bestellung 4711 lesen | Nach der Zugriffsprüfung den Status der erlaubten Bestellung liefern; keine fremden Datensätze offenlegen. |
| Antwort vorbereiten | Einen Entwurf für die Servicekollegin ablegen, mit Verweis auf den Bestelldatensatz. |
| An eine unbekannte Adresse senden | Die Anfrage stoppen. Die Kollegin prüft Empfänger und Inhalt; diese Rolle hat keine eigene Versandberechtigung. |
Auch ein erlaubtes Werkzeug kann Daten an den falschen Empfänger senden
Ein Passwort außerhalb des Chats sagt der Kollegin noch nicht, ob die Antwort an die richtige Person geht. Darf die Verbindung an beliebige Adressen senden, könnte eine eingeschleuste Anweisung diese Funktion missbrauchen. Prüfen Sie bei der Bestellanfrage deshalb neben den Werkzeugrechten auch, welche Daten weitergegeben werden dürfen und wer sie erhalten darf.
Die Sicherheitsleitlinie für OAuth empfiehlt, ein Zugriffstoken auf die nötigen Ressourcen und Aktionen zu beschränken.[S4] Für die Lieferauskunft heißt das: Die Verbindung darf den Status lesen. Die Antwort versendet eine Person im Service.
In unserer Bestellübung gilt eine unerwartete Anweisung im Kundentext deshalb niemals als Erlaubnis, einen Empfänger hinzuzufügen. Die vorgeschlagene Rolle bereitet vor; die Kollegin versendet. Möchte das Team später automatisch versenden lassen, braucht es dafür eine neue Entscheidung mit festgelegten Zielen, Inhaltsprüfungen und Tests.
Prüfen Sie, ob ein abgelehnter Zugriff tatsächlich unterbleibt
Vor der Übergabe würden wir den Ablauf mit freigegebenen Testdaten prüfen. Beginnen Sie mit dem normalen Abruf. Versuchen Sie anschließend einen Datensatz außerhalb der vereinbarten Rechte, eine Bestelländerung und einen Versand an eine nicht freigegebene Adresse. Die prüfende Person schaut nach, was das Zielsystem tatsächlich getan hat. Die Erfolgsmeldung des Agenten reicht als Nachweis nicht aus.
Unterbrechen Sie danach die Verbindung und versuchen Sie es erneut. Klären Sie, ob bereits erteilte Zugänge noch funktionieren, wo der fehlgeschlagene Versuch erscheint und wer den Zugriff wiederherstellen kann. Im Abnahmeprotokoll steht, was angefragt wurde, was geschah und welcher Beleg das zeigt. Dies sind vorgeschlagene Prüfungen für die Übung, keine von uns gemessenen Ergebnisse.
Vereinbaren Sie außerdem einen einfachen Ersatzweg: Scheitert der Zugriff oder lässt sich die Bestellung nicht eindeutig zuordnen, übernimmt eine Person im Service. Unser Leitfaden zur Prüfung vor dem Produktiveinsatz hilft, daraus eine praktische Abnahme zu machen. Was später laufend dokumentiert werden sollte, erläutert der Leitfaden zum Audit-Trail.
Vereinbaren Sie die Zugriffe mit den Verantwortlichen für Aufgabe und System
Beginnen Sie mit einer freigegebenen oder anonymisierten Frage zum Lieferstatus. Gehen Sie diese mit Serviceleitung, Systemverantwortlichen und der für den Agenten zuständigen Person durch. Benennen Sie die benötigten Bestelldaten, die abrufende Verbindung, die Person, die die Antwort prüft und versendet, und den Weg zum Entzug des Zugriffs. Damit hat die IT eine konkrete Rolle zum Einrichten und das Serviceteam einen Ablauf zum Prüfen.
Bei MING würden wir diese Vereinbarung in die Einführung des Agenten ins Team aufnehmen. Für ein Gespräch über eine erste Rolle reichen zunächst eine wiederkehrende Aufgabe und die beteiligten Systeme. Passwörter und Kundendatensätze gehören nicht in die erste Anfrage.
Belege und Grenzen
- Bestellung, Grafik und Abnahmeübung sind illustrative Vorschläge, kein Kundenergebnis und kein Sicherheitsaudit.
- Öffentliche Quellen tragen die erläuterten Unterscheidungen und Risiken. Produktspezifische Kontrollen müssen im tatsächlichen Aufbau geprüft werden.
- Diese Überarbeitung ersetzt frühere Aussagen über die gesamte MING-Flotte durch einen Gestaltungsansatz. Sie belegt weder einen aktuellen flottenweiten Aufbau noch feste Rotationsintervalle oder einen garantierten Schutz.
