KI-Agenten: Identität, Berechtigungen und Aktionen nachvollziehbar prüfen

Mit einem nachvollziehbaren Aktionsnachweis beginnen

Wenn du bei KI-Agenten Identität, Berechtigungen und einen Auditnachweis prüfen möchtest, beginne mit einer einzelnen Aktion: Wer hat sie angefordert, welche Identität hat gehandelt und was lässt sich am Ziel tatsächlich nachweisen? Eine erfolgreiche Anmeldung oder eine überzeugende Agentenantwort beantwortet diese Fragen noch nicht vollständig.

Illustratives Beispiel für eine manuelle Dokumentation, kein tatsächlicher Systemeintrag: Lea bittet die Projektassistenz, einen bestimmten Projektplan zu lesen und einen Antworttext vorzubereiten. Die Nachricht soll nicht gesendet werden. Nora verantwortet den Zugriff auf die Ablage. Die folgenden fünf Felder bündeln die Angaben, ohne Auftraggeberin, ausführenden Agenten und freigebende Person gleichzusetzen.

Unter „P-104-Lesen“ hältst du beispielsweise die Zielreferenz des Plans und das beobachtete Leseergebnis fest. „P-104-Antwort“ verweist auf den vorgeschlagenen Text. Dass dieser Text vorliegt, belegt keinen Versand und auch keinen gespeicherten Entwurf im Postfach. Dafür wäre ein eigener Schritt mit eigenem Ergebnis erforderlich.

Der Name im Chat erklärt die Absicht, authentifiziert aber noch keinen Zugriff. Ein Zugangsnachweis beschreibt, womit sich die ausführende Identität ausweist; die Berechtigung begrenzt ihre Möglichkeiten. Die Freigabe betrifft die konkrete Handlung. Der Aktionsnachweis trennt schließlich den Versuch vom Ergebnis. Verwende vorhandene Kennungen oder kennzeichne selbst vergebene Referenzen als solche. Kopiere weder geheime Tokens noch unnötige Dokumentinhalte in die Aufzeichnung.

Identität und Berechtigung für die Ressource festlegen

Auftraggeber, ausführende Identität und freigebende Person können bei einer einfachen Aufgabe zusammenfallen, müssen es aber nicht. Eine Agenteninstanz kann im Auftrag einer Mitarbeiterin handeln, während eine Administratorin die Anwendung grundsätzlich für eine Ressource autorisiert. Halte beide Entscheidungen auseinander: den verfügbaren Zugriff und die Erlaubnis für den konkreten Auftrag.

Die Microsoft-Entra-Dokumentation zur Autorisierung von Agentenidentitäten unterscheidet delegierte Berechtigungen von Anwendungsberechtigungen. Delegierter Zugriff erfolgt im Namen eines Nutzers innerhalb der gewährten Rechte. Anwendungsberechtigungen können administrativ gewährten Zugriff ohne diesen Nutzerkontext ermöglichen. Für Agentenidentitäten bestehen zudem Einschränkungen bei hoch privilegierten Rollen und API-Berechtigungen. Diese Regeln sind Entra-spezifisch, keine allgemeine Eigenschaft jeder Agenten-App.

Prüfe zuerst die Zielressource. Azure-Ressourcenrollen, Verzeichnisrollen und Microsoft-Graph-Berechtigungen steuern unterschiedliche Zugriffe. Eine Berechtigung für eine Azure-Ressource ersetzt nicht automatisch eine Graph-Berechtigung für eine andere Aufgabe. Auch die administrative Verwaltung einer Identität ist etwas anderes als deren Recht, ein Dokument zu lesen.

Für Leas Auftrag genügt der erforderliche Lesezugriff auf den Plan beziehungsweise die passende Ressource. Schreibrechte oder eine breite Administratorrolle wären durch diesen Auftrag nicht begründet. Eine erteilte OAuth-Zustimmung ist außerdem keine Genehmigung für jede spätere Nachricht, Dateiänderung oder Veröffentlichung.

• Ordne die Agentenidentität einer verantwortlichen Person oder Stelle zu.
• Prüfe Ressource, erlaubte Operation und tatsächlich gewährten Umfang.
• Halte fest, wer zusätzliche Schreibrechte genehmigen dürfte.
• Überprüfe Ablauf und erneute Freigabe, soweit eure Richtlinie dies vorsieht.

Beim Projektende oder beim Ausscheiden einer Person müssen die zugehörigen Identitäten und Verbindungen erneut bewertet werden. Wie Unternehmensanforderungen gegenüber Geräterechten einzuordnen sind, vertieft Sicherheit von Enterprise-KI-Agenten: Warum lokale Phone Agents anders bewertet werden müssen.

Anmeldeereignisse mit tatsächlichen Aktionen verbinden

Microsoft Entra stellt Hinweise zur Zuordnung von Agentenidentitäten bereit. Laut der Microsoft-Hilfe zu Anmelde- und Auditprotokollen für Agenten können Auditereignisse unter anderem agentType und blueprintId enthalten. Aktivitäten einer Vorlage erscheinen als Anwendungsereignisse, Agentenidentitäten als Dienstprinzipalereignisse und Agenten-Nutzerkonten als Nutzerereignisse.

Mit mindestens der Rolle „Reports Reader“ können Berechtigte in Entra ID unter „Überwachung und Integrität“ die Anmeldeprotokolle öffnen und nach Agenten filtern. Die beschriebenen Microsoft-Graph-Abfragen für Agentenprotokolle verwenden /beta. Prüfe deshalb den tatsächlich verfügbaren Zugangsweg, statt jede gezeigte Abfrage als allgemein verfügbare Schnittstelle vorauszusetzen.

Diese Einträge helfen zu klären, welche Identität sich wann und für welche Ressource angemeldet hat. Sie beweisen allein nicht, dass der Projektplan gelesen, ein Antworttext erstellt oder eine Nachricht versendet wurde. Dafür brauchst du zusätzlich Nachweise der jeweiligen Anwendung oder eine überprüfbare Ergebnisreferenz.

1. Auftrag zuordnen: Suche die Auftragskennung und die ausführende Identität.
2. Zugriff prüfen: Vergleiche Zielressource, Zeitpunkt und das verfügbare Anmelde- beziehungsweise Autorisierungsergebnis.
3. Fachaktion suchen: Ordne die konkrete Operation anhand vorhandener Aktionskennungen und Zielreferenzen zu.
4. Ergebnis bestätigen: Prüfe den tatsächlichen Zielzustand oder eine geeignete Anwendungsaufzeichnung.

Bei „P-104“ könnte eine passende Anmeldung dem Dokumentzugriff vorausgehen. Erst der zugehörige Anwendungsnachweis würde den Lesevorgang stützen; der überprüfte Antworttext wäre ein weiterer Nachweis. Zeitliche Nähe allein reicht nicht, wenn mehrere Aufträge dieselbe Identität verwenden. Übernimm unterschiedliche Zeitzonen und Kennungen nachvollziehbar, ohne eine gemeinsame Kennung zu erfinden.

Fehlt der Zielnachweis, lautet das Ergebnis zunächst „nicht bestätigt“, nicht „erfolgreich“. Dokumentiere die Lücke und den nächsten Prüfschritt. Wer die Aufzeichnungen lesen darf und wie lange sie aufbewahrt werden, richtet sich nach den Regeln der Organisation. Ein vorhandenes Protokoll garantiert weder vollständige Fachaktionsabdeckung noch unveränderliche Aufbewahrung.

Erfolg, Ablehnung und unklare Ergebnisse unterscheiden

Die folgenden vorgeschlagenen Einträge zeigen vier unterschiedliche Ergebnisse. Sie sind Beispiele für deine manuelle Prüfliste, keine beobachteten Testresultate. Übernimm in jedem Fall Auftraggeber, ausführende Identität und Zugangsnachweisreferenz aus dem zugehörigen Auftrag; ergänze Umfang, Freigabe, Versuch und tatsächlichen Befund.

Beim erfolgreichen Lesen sollte die Ergebnisreferenz zeigen, dass das richtige Dokument betroffen war. Eine Agentenantwort über irgendeinen Projektplan reicht nicht. Beschränke die Dokumentation auf die erforderlichen Referenzen und überprüften Angaben, statt den ganzen Plan zu vervielfältigen.

Bei ausstehender Freigabe ist ein vorbereiteter Auftrag noch keine Ausführung. Wird die Freigabe später erteilt, ergänze Zeitpunkt und freigebende Person. Halte weiterhin getrennt fest, ob der Schreibschritt tatsächlich begann und welches Ergebnis er lieferte. „Genehmigt“ bedeutet nicht „angelegt“.

Bei einer Ablehnung beschreibst du den tatsächlichen Grund möglichst konkret: fehlende Berechtigung, deaktiviertes Werkzeug oder verweigerte Freigabe. Eine unveränderte Zielansicht ist eine zusätzliche Beobachtung, aber kein Beweis für alle denkbaren Zugriffe. Benenne deshalb das geprüfte Konto, die Ressource und den Umfang deiner Kontrolle.

Beim unklaren Schreibversuch darf keine automatische Wiederholung aus der fehlenden Antwort folgen. Suche zuerst den Termin im vorgesehenen Kalender und vergleiche Titel, Datum und Uhrzeiten. Ist er vorhanden, ergänze den Nachweis und wiederhole ihn nicht. Bleibt der Zustand unklar, pausiere die Aufgabe. Ein bestätigter Lesevorgang und ein unbestätigter Schreibvorgang können innerhalb desselben Auftrags unterschiedliche Statuswerte behalten.

Dieselben Fragen auf dem Android-Handy stellen

Bei FoneClaw kannst du das Fünf-Felder-Schema als manuelle Prüfliste für eine Telefonaufgabe nutzen. Unser ausgewähltes Standardmodell oder kompatibles konfiguriertes Modell interpretiert und plant; aktivierte Android-Werkzeuge führen unterstützte Schritte aus. Die Prüfliste ist deine Dokumentationsmethode, kein nativer Enterprise-Auditexport oder eine Entra-Verbindung.

Für „Zeige meinen Akkustand und den Energiesparmodus“ nutzt das unterstützte Werkzeug device_battery_status eine reine Statusabfrage. Es ändert keine Einstellungen. Notiere die anfragende Person, die aktive Konfiguration, die Werkzeugaktivierung, die geltende Freigaberegel und die tatsächlich zurückgegebenen Werte mit dem Abfragezeitpunkt. Eine plausible Modellschätzung ersetzt kein Werkzeugergebnis.

Die Werkzeugklassifikation beschreibt Risiko und voreingestellte Freigabe. Unser globaler Freigabemodus und Einstellungen je Werkzeug bestimmen das tatsächliche Verhalten. Deshalb folgt aus einer lesenden Aufgabe nicht zwangsläufig eine zusätzliche Nachfrage; umgekehrt ersetzt eine frühere Freigabe nicht die Prüfung eines neuen Schreibauftrags.

Ein vorgeschlagener Kalenderauftrag könnte lauten: „Lege am 15. Oktober 2026 von 14:00 bis 14:30 Uhr einen Termin Projektbesprechung im ausgewählten Kalender an, mit Erinnerung zehn Minuten vorher.“ Für calendar_create_event müssen fehlende Zeit- und Erinnerungsangaben zuerst geklärt werden. Halte Datum, Zeitzone, Kalender und die tatsächlich angewandte Freigabe fest.

Nach dem Anlegen vergleichst du die zurückgegebenen Werte actualStart und actualEnd mit dem Auftrag und öffnest den betreffenden Kalender. Prüfe dort auch Titel und Erinnerung. Eine Erfolgsmeldung ohne passenden Eintrag am vorgesehenen Ziel ist noch kein vollständig bestätigtes Ergebnis. Die FoneClaw-Funktionsseite erläutert unsere unterstützten Telefonaktionen.

Android-Berechtigungen, aktivierte Werkzeuge und Modellanbieter-Zugangsdaten bleiben getrennte Kontrollpunkte. Ein API-Schlüssel verwaltet keine Android-Rechte. Ein Online-Modell kann bereitgestellten Kontext außerhalb des Telefons verarbeiten; der manuelle Nachweis einer Telefonaktion beschreibt diese Datenverarbeitung nicht vollständig.

Zugriff entziehen und den verbleibenden Zustand prüfen

Ein Zugriffsentzug soll künftige Handlungen begrenzen. Er löscht aber keinen bereits angelegten Termin und holt keine versendete Nachricht zurück. Behandle deshalb das Sperren weiterer Aktionen und die Prüfung vorhandener Änderungen als zwei Aufgaben.

Für eine harmlose eigene Kontrolle kannst du die nicht benötigte Akkuabfrage vorübergehend deaktivieren und erneut ausdrücklich eine Abfrage über dieses Werkzeug anfordern. Erwartet wird, dass das deaktivierte Werkzeug nicht ausgeführt wird und keine Geräteeinstellung verändert wird. Eine allgemeine Textantwort über Akkus ist kein Nachweis für den Werkzeugzugriff.

1. Notiere vorab die Werkzeugaktivierung und die geltende Freigaberegel.
2. Deaktiviere nur das ausgewählte lesende Werkzeug.
3. Stelle die begrenzte Anfrage ohne weitere Telefonaktionen.
4. Prüfe die Rückmeldung auf tatsächliche Ausführung oder Blockierung.
5. Halte das beobachtete Ergebnis fest und aktiviere den Zugriff nur bei Bedarf wieder.

Falls die Rückmeldung nicht erkennen lässt, ob das Werkzeug verwendet wurde, dokumentiere diese Unsicherheit statt eine erfolgreiche Sperre zu behaupten. Prüfe die konkrete Einstellung erneut. Das Verfahren ist ein vorgeschlagener Kontrollablauf, kein Bericht über eine von uns durchgeführte Prüfung.

Bei einem offenen Schreibauftrag kontrollierst du vor jedem erneuten Versuch zuerst die Ziel-App. Ein vorhandener Kalendereintrag braucht gegebenenfalls eine gesondert gewünschte Korrektur, keine zweite Erstellung. In Unternehmen sollte die verantwortliche Stelle außerdem ungenutzte Agentenidentitäten, Ressourcenzugriffe und Verbindungen prüfen. Offengelegte Zugangsdaten müssen beim zuständigen Dienst gesperrt oder ersetzt werden; eine lokale Werkzeugdeaktivierung genügt dafür nicht.

Überprüfe auch Freigabeausnahmen sowie den Zugriff auf die manuell gesammelten Nachweise. Aufbewahrung und Löschung sollten eurer eigenen Richtlinie folgen, nicht einer pauschalen Frist. Zusätzliche Skills benötigen eine Prüfung von Quelle und Laufzeitrechten, wie Sicherheit von KI-Agent-Skills: Warum Phone Agents Laufzeitprüfungen brauchen erklärt. Gespeicherte Agenteninformationen können vorgeschlagene Aktionen beeinflussen; Speichervergiftung bei KI-Agenten auf dem Handy behandelt diese getrennte Vertrauensfrage. Der abschließende Nachweis sollte zeigen, welcher Zugriff entzogen wurde, welcher Zielzustand bestehen bleibt und welche Aufgabe noch offen ist.