Wer fragt da? Identität vor die App.
Bevor ein Agent mit einer Anwendung spricht, sollte klar sein, wer ihn schickt. Die wichtigere Anschlussfrage: Was darf er nach der Anmeldung tatsächlich tun?
Die Anwendung muss nicht jede Anfrage zuerst selbst sehen
Öffentlich erreichbare Anwendungen bekommen auch Anfragen von Akteuren, die dort nichts zu suchen haben. Eine vorgelagerte Identitätsprüfung kann diese direkte Erreichbarkeit begrenzen. Damit wird eine Schwäche in der Anwendung nicht automatisch bedeutungslos. Es entsteht aber eine zusätzliche Grenze vor dem eigentlichen Dienst.
JPMorganChase beschreibt diesen Ansatz im Beitrag „200 days into the frontier“. Eine unabhängige Schicht soll schädliche Anfragen abfangen, die Anmeldung mit Mehrfaktor-Verfahren prüfen und nur erlaubte Zugriffe durchlassen. Ebenso wichtig ist dort die Betriebsseite: Diese Schutzschicht soll redundant ausgelegt sein und einen getesteten Ausweichweg haben. Eine zusätzliche Grenze darf nicht zur einzigen Sollbruchstelle werden.
Ein bekannter Agent braucht eine begrenzte Aufgabe
Bei KI-Agenten hilft eine Anmeldung dabei, Handlungen einer Identität zuzuordnen. Sie beantwortet noch nicht, ob die einzelne Aktion zur Aufgabe passt. Ein Agent kann korrekt angemeldet sein und trotzdem zu weitreichende Berechtigungen besitzen. Ein geteilter technischer Zugang macht die Zuordnung zusätzlich schwierig.
Der JPMorganChase-Beitrag empfiehlt ausdrücklich aufgabenbezogene Rechte, identifizierbare Agenten, nachvollziehbare Aktionen und die Möglichkeit, einen Agenten rasch einzuschränken oder zu stoppen. Für die Umsetzung würde ich daraus einen konkreten Auftrag ableiten: Welche Daten braucht der Agent, welche Änderung darf er ausführen und an welcher Grenze endet seine Sitzung? Diese Grenzen müssen im Zielsystem wirksam sein.
Die zweite Tür steht hinter dem Login
Ein hilfreicher Test beginnt mit einer gültigen Anmeldung. Darf der Agent danach fremde Datensätze lesen, eine andere Rolle annehmen oder einen weiteren Dienst aufrufen? Wenn das funktioniert, lag das Problem nicht im fehlenden Login. Es lag in der Berechtigung hinter dem Login.
Ich würde technische Identitäten deshalb an eine begrenzte Aufgabe und einen benannten Verantwortlichen binden. Sitzungen brauchen eine passende Laufzeit. Besonders folgenreiche Änderungen brauchen eine zusätzliche Entscheidung, die der Agent nicht einfach selbst erzeugen kann. Ob eine Kontrolle trägt, zeigt ein Test mit den tatsächlich vergebenen Rechten. Eine Rollenbeschreibung im Konzept reicht dafür nicht.
Abschalten muss zur Architektur gehören
Ein Stopp-Schalter ist erst dann nützlich, wenn klar ist, was er beendet. Wird nur die Oberfläche geschlossen oder verliert der Agent auch seine laufenden Sitzungen und nachgelagerten Zugänge? Welche Aktionen sind schon ausgelöst, welche können noch zurückgenommen werden? Diese Fragen gehören vor den produktiven Einsatz.
Für mich gehören daher Zugang, Berechtigungen, Protokollierung und Wiederanlauf zusammen. An der Kante wird entschieden, wer überhaupt bis zur Anwendung kommt. Dahinter wird jede Aufgabe auf ihre notwendigen Rechte begrenzt. Im Vorfall muss nachvollziehbar bleiben, was tatsächlich passiert ist und welche Zugriffe weiterhin bestehen. Genau daraus entsteht eine kontrollierbare Agenten-Architektur.