Jeder KI-Agent braucht eine Identität
Ein Unternehmen gewährt einem KI-Agenten Zugriff auf sein gemeinsames Laufwerk, seine CRM-Plattform und sein E-Mail-System. Der Agent kann Kundendaten abrufen, Angebote erstellen, Verkaufschancen aktualisieren und Folge-E-Mails versenden. Er arbeitet anwendungsübergreifend und erledigt Aufgaben, für die zuvor ein Mitarbeiter erforderlich war. Dennoch fällt es dem Unternehmen möglicherweise weiterhin schwer, eine grundlegende Frage zu beantworten: Wer handelt, wenn der Agent die Arbeit erledigt?
Viele Organisationen richten Agenten als Erweiterungen eines Benutzerkontos, einer Softwareanwendung oder von Anmeldedaten für einen gemeinsam genutzten Dienst ein. Dies mag im Rahmen eines kontrollierten Pilotprojekts ausreichend sein. Gefährlich wird es jedoch, sobald der Agent beginnt, eigenständig zu agieren, auf sensible Informationen zuzugreifen oder Aktionen über mehrere Systeme hinweg auszulösen. Ein Unternehmensagent benötigt einen eigenen, identifizierbaren Platz innerhalb der Organisation. Das Unternehmen sollte wissen, was der Agent ist, wer ihn autorisiert hat, auf welche Ressourcen er zugreifen darf, welche Aktionen er ausführen darf und wann seine Berechtigungen ablaufen sollten. Ohne diese Identität kann der Agent zu einem leistungsfähigen digitalen Akteur mit weitreichendem Zugriff und geringer Rechenschaftspflicht werden.
Ein Agent ist mehr als nur eine weitere Anwendung
Herkömmliche Unternehmenssoftware folgt in der Regel vorhersehbaren Anweisungen. Eine Anwendung erhält eine definierte Eingabe, führt einen programmierten Prozess aus und liefert eine erwartete Ausgabe. Sicherheitsteams können ihre Verbindungen abbilden und die von ihr ausgeführten Vorgänge genau bestimmen.
KI-Agenten verhalten sich unterschiedlich. Sie interpretieren Ziele, wählen Zwischenschritte aus und greifen je nach Situation auf entsprechende Tools zurück. Ein Vertriebsmitarbeiter könnte beispielsweise einen CRM-Eintrag durchsuchen, frühere Korrespondenz einsehen, eine Preisliste prüfen, einen Angebotsentwurf erstellen und einen anderen Mitarbeiter bitten, die Konditionen zu überprüfen.
Die Reihenfolge kann sich von einer Aufgabe zur nächsten ändern. Diese Flexibilität macht einen Großteil des Nutzens von Agenten aus, erschwert jedoch auch die Zugriffskontrolle. Eine herkömmliche Anwendung benötigt möglicherweise die Berechtigung, eine kleine Anzahl vordefinierter Vorgänge auszuführen. Ein Agent kann potenziell mehrere legitime Berechtigungen auf eine Weise kombinieren, die zum Zeitpunkt der Erteilung dieser Berechtigungen niemand vorausgesehen hat.
Die Sicherheitsfrage stellt sich daher nun anders dar. Unternehmen müssen nicht nur feststellen, ob der Agent eine Verbindung zu einem System herstellen darf, sondern auch, ob er eine bestimmte Aktion an einer bestimmten Ressource zu einem bestimmten Zweck und im Auftrag einer bestimmten Person ausführen darf. Eine individuelle Identität bildet die Grundlage für die Beantwortung dieser Fragen.
Gemeinsam genutzte Zugangsdaten führen zu einem Verlust der Verantwortlichkeit
Die einfachste Möglichkeit, einen Agenten mit Unternehmenssystemen zu verbinden, besteht oft darin, ihm ein bestehendes Dienstkonto zuzuweisen oder ihm zu gestatten, mit den Anmeldedaten eines Mitarbeiters zu agieren.
Beide Ansätze bringen Probleme mit sich. Wenn mehrere Mitarbeiter dasselbe Dienstkonto nutzen, kann es vorkommen, dass in den Aktivitätsprotokollen zwar vermerkt ist, dass das Konto ein Dokument geöffnet oder einen Datensatz geändert hat, jedoch nicht ersichtlich ist, welcher Mitarbeiter die Aktion durchgeführt hat. Ermittler können zwar erkennen, dass etwas passiert ist, sind jedoch möglicherweise nicht in der Lage, den entsprechenden Arbeitsablauf nachzuvollziehen.
Wenn einem Agenten gestattet wird, die Identität eines Mitarbeiters zu übernehmen, entsteht eine andere Unklarheit. Das System erfasst möglicherweise den Mitarbeiter als Ausführenden, selbst wenn der Agent die Aktion eigenständig ausgewählt und ausgeführt hat.
Dies ist von Bedeutung, wenn ein Mitarbeiter einen fehlerhaften Zahlungsauftrag versendet, einen Kundendatensatz ändert oder vertrauliche Informationen weitergibt. Das Unternehmen muss feststellen, ob der Mitarbeiter die Maßnahme angefordert hat, ob der Mitarbeiter den Auftrag überschritten hat und welches System die Ausführung der Maßnahme ermöglicht hat.
Eine agentenspezifische Identität sorgt für einen übersichtlicheren Prüfpfad. Sie ermöglicht es dem Unternehmen, zwischen menschlichen Entscheidungen, delegierten Handlungen und autonomen Schritten zu unterscheiden, die im Rahmen eines genehmigten Arbeitsablaufs durchgeführt werden.
Diese Trennung unterstützt die Untersuchung von Vorfällen, Compliance-Prüfungen und die allgemeine operative Aufsicht. Außerdem verhindert sie, dass das Unternehmen jeden Fehler eines Vermittlers so behandelt, als hätte der zuständige Mitarbeiter ihn persönlich begangen.
Jeder Agent braucht einen verantwortlichen Paten
Einem Agenten eine technische Identität zuzuweisen, bedeutet noch nicht, dass er rechenschaftspflichtig ist. Die Organisation benötigt außerdem einen namentlich benannten menschlichen Verantwortlichen.
Ein Agent kann Aufgaben in mehreren Abteilungen ausführen, doch muss stets jemand für seinen Zweck, seine Berechtigungen und den fortlaufenden Betrieb verantwortlich sein. Dieser Verantwortliche sollte verstehen, was der Agent tut, welche Daten er verwendet und was passieren könnte, wenn er fehlerhaft arbeitet.
Der Auftraggeber muss nicht jede Routinehandlung genehmigen. Eine ständige Genehmigung würde den Nutzen der Automatisierung weitgehend zunichte machen. Der Auftraggeber sollte stattdessen die Grenzen festlegen, innerhalb derer der Agent agiert.
Dazu gehören die Beantragung von Zugriffsrechten, die Überprüfung ungewöhnlicher Berechtigungen, die Überprüfung, ob der Agent weiterhin einem legitimen Geschäftszweck dient, sowie die Entscheidung, wann das Unternehmen ihn aussetzen oder außer Betrieb nehmen sollte.
Die Zuständigkeit sollte nicht informell bleiben. Ein von einem Mitarbeiter erstelltes Pilotprojekt kann nach und nach zu einem Teil eines kritischen Prozesses werden, selbst wenn dieser Mitarbeiter die Position wechselt oder das Unternehmen verlässt. Der Beauftragte kann weiterhin über Zugriffsrechte verfügen und Aufgaben ausführen, ohne dass ein aktiver Verantwortlicher vorhanden ist.
Unternehmen stehen bereits vor diesem Problem mit aufgegebenen Anwendungen und Dienstkonten. Agenten können die Situation noch verschärfen, da sie nicht nur den Zugriff behalten, sondern diesen auch weiterhin nutzen können.
Berechtigungen sollten sich nach der Aufgabe richten
Ein Beauftragter sollte nicht denselben Zugriff erhalten wie sein Auftraggeber.
Ein Manager kann möglicherweise Vergütungsdaten einsehen, Ausgaben genehmigen und vertrauliche Vorstandsunterlagen lesen. Ein Beauftragter, der im Namen des Managers Besprechungen organisiert, benötigt diese Befugnisse nicht.
Unternehmen sollten Berechtigungen entsprechend der festgelegten Funktion des Mitarbeiters vergeben. Ein Terminplaner benötigt möglicherweise Zugriff auf die Kalenderverfügbarkeit, jedoch nicht auf den vollständigen Inhalt jeder Besprechung. Ein Einkäufer kann Lieferantenangebote vergleichen, ohne die Berechtigung zur Vertragsgenehmigung zu erhalten. Ein Support-Mitarbeiter kann Kontoinformationen abrufen, ist jedoch nicht in der Lage, Zahlungsdetails zu ändern.
Dies ist das Prinzip der geringsten Berechtigungen, angewandt auf agentenbasierte Systeme. Der Agent erhält nur die Zugriffsrechte, die zur Erfüllung seiner autorisierten Aufgabe erforderlich sind.
Das Prinzip kommt einem bekannt vor, doch Agenten erschweren die Durchsetzung. Entwickler fügen im Zuge der Projektausweitung möglicherweise neue Tools hinzu, Abteilungen binden neue Datenquellen ein und Nutzer fordern unter Umständen erweiterte Funktionen an. Der Agent sammelt nach und nach Berechtigungen an, die nicht mehr seinem ursprünglichen Zweck entsprechen.
Sicherheitsteams sollten die Überprüfung von Berechtigungen daher als fortlaufenden Prozess betrachten und nicht als einmalige Überprüfung der Bereitstellung.
Außerdem sollten sie zwischen dem Auslesen von Informationen und dem Ergreifen von Maßnahmen unterscheiden. Einem Agenten zu gestatten, eine Rechnung einzusehen, ist etwas anderes, als ihm zu gestatten, das mit dieser Rechnung verknüpfte Bankkonto zu ändern. Das Lesen eines Vertragsentwurfs ist etwas anderes, als diesen an die Gegenpartei zu senden.
Für die wichtigsten Vorgänge kann eine zusätzliche Sicherheitsmaßnahme erforderlich sein, beispielsweise eine manuelle Freigabe, eine strengere Authentifizierung oder eine Bestätigung über ein separates System.
Die Delegation muss sichtbar sein
Viele Agenten handeln nicht ausschließlich in eigenem Namen. Sie führen Aufgaben aus, die ihnen von einem Benutzer übertragen wurden.
Das Identitätssystem sollte diese Beziehung beibehalten.
Aus einer Aufzeichnung sollte hervorgehen, dass ein bestimmter Mitarbeiter einen bestimmten Mitarbeiter beauftragt hat, eine bestimmte Aufgabe auszuführen. Das System sollte dann zwischen den Handlungen, die unter diesen Auftrag fallen, und zusätzlichen Schritten, die der Mitarbeiter während der Ausführung selbst gewählt hat, unterscheiden.
Das ist wichtig, denn eine Befugnisübertragung ist keine uneingeschränkte Zustimmung.
Ein Mitarbeiter kann einen Beauftragten bitten, eine Liste überfälliger Rechnungen zu erstellen. Diese Aufforderung berechtigen den Beauftragten jedoch nicht zwangsläufig dazu, Kunden zu kontaktieren, Zahlungsbedingungen zu ändern oder Inkassomaßnahmen einzuleiten. Die Fähigkeit des Beauftragten, einen sinnvollen nächsten Schritt abzuleiten, sollte ihm nicht automatisch die Erlaubnis geben, diesen Schritt auch tatsächlich zu unternehmen.
Durch klare Delegationskontrollen können Unternehmen Eigenverantwortung mit festgelegten Befugnissen verbinden. Der Beauftragte kann entscheiden, wie er eine genehmigte Aufgabe ausführt, ohne jedoch den zulässigen Rahmen der Aufgabe überschreiten zu können.
Eine Befugnisübertragung sollte zudem zeitlich begrenzt sein. Ein Beauftragter, der vorübergehend Zugriff erhält, um ein Projekt abzuschließen, sollte diesen Zugriff verlieren, sobald das Projekt beendet ist. Eine vorübergehende Befugnis sollte nicht zu einer dauerhaften Berechtigung werden, nur weil niemand daran gedacht hat, sie zu widerrufen.
Identität macht die Überwachung sinnvoller
Unternehmen können keine Akteure steuern, die sie nicht unterscheiden können.
In einem Bestandsverzeichnis sollten alle eingesetzten Agenten, deren Träger, deren Funktion, die damit verbundenen Systeme sowie die ihnen zugewiesenen Berechtigungen erfasst werden. Die Organisation sollte außerdem wissen, ob der Agent aktiv, im Testbetrieb, gesperrt oder zur Stilllegung vorgesehen ist.
Dies schafft die Grundlage für eine aussagekräftige Überwachung.
Sicherheitsteams können ungewöhnliche Aktivitäten erkennen, wenn sie die normale Rolle eines Mitarbeiters kennen. Ein Forschungsmitarbeiter, der plötzlich versucht, Gehaltsdaten zu ändern, stellt eine offensichtliche Unstimmigkeit dar. Ein Kundendienstmitarbeiter, der eine ungewöhnlich große Menge an Datensätzen exportiert, erfordert möglicherweise eine sofortige Untersuchung.
Das Unternehmen kann zudem ähnliche Anwendungen vergleichen und Doppelungen aufdecken. Es kann vorkommen, dass verschiedene Abteilungen separate Tools entwickelt haben, die fast dieselbe Aufgabe erfüllen, dabei aber über unterschiedliche Benutzeroberflächen auf dieselben Daten zugreifen.
Ohne eine Bestandsaufnahme der Identitäten können sich diese Agenten schneller ausbreiten als die sie umgebende Governance-Struktur. Jeder neue Agent wird zu einem weiteren nicht-menschlichen Akteur, der auf Systeme zugreifen, Zugangsdaten besitzen und betriebliche Abhängigkeiten schaffen kann.
Die Transparenz sollte bereits während der Entwicklung beginnen, nicht erst nach der Bereitstellung. Low-Code-Plattformen ermöglichen es Geschäftsteams, Agenten zu erstellen, ohne auf ein zentrales Softwareprojekt warten zu müssen. Diese Schnelligkeit kann von Vorteil sein, doch der daraus resultierende Agent sollte dennoch den Identitäts- und Genehmigungsprozess des Unternehmens durchlaufen, bevor er Zugriff auf die Produktionsumgebung erhält.
Agenten brauchen einen Lebenszyklus
Mitarbeiter treten ein, wechseln ihre Position und scheiden aus. Ihre Zugriffsrechte sollten sich entsprechend anpassen.
Agenten benötigen einen entsprechenden Lebenszyklus.
Ein Unternehmen sollte festlegen, wie ein Agent seine Identität erhält, wer seine anfänglichen Berechtigungen genehmigt und wann diese Berechtigungen überprüft werden. Es sollte außerdem definieren, was geschieht, wenn der zuständige Mitarbeiter das Unternehmen verlässt, sich der zugrunde liegende Prozess ändert oder der Agent durch eine neuere Version ersetzt wird.
Ein aktualisierter Agent erfordert möglicherweise eine neue Bewertung, auch wenn er denselben Namen behält. Ein anderes Modell, eine andere Tool-Anbindung oder ein anderer Befehlssatz können sein Verhalten und die von ihm ausgehenden Risiken verändern.
Die Stilllegung verdient besondere Aufmerksamkeit. Durch das Deaktivieren der sichtbaren Benutzeroberfläche werden API-Schlüssel, Hintergrundprozesse, geplante Aufgaben oder Verbindungen zu anderen Agenten möglicherweise nicht entfernt. Das Unternehmen muss Zugangsdaten widerrufen, Zugriffspfade sperren und die für Audits oder Untersuchungen erforderlichen Aufzeichnungen aufbewahren.
Inaktive Agenten sollten nicht auf unbestimmte Zeit aktiv bleiben. Ein Agent, der über einen festgelegten Zeitraum keine berechtigte Aufgabe ausgeführt hat, sollte möglicherweise automatisch seine Zugriffsrechte verlieren, bis der Eigentümer bestätigt, dass er weiterhin benötigt wird.
Menschliche Zustimmung kann nicht alle Probleme lösen
Unternehmen reagieren häufig auf das Risiko durch Mitarbeiter, indem sie eine Person am Ende des Arbeitsablaufs einsetzen. Der Mitarbeiter bereitet die Maßnahme vor, und der Angestellte klickt auf „Genehmigen“.
Diese Kontrollmaßnahme kann insbesondere bei Zahlungen, Verträgen, der externen Kommunikation und Änderungen an sensiblen Datensätzen hilfreich sein. Für sich allein genommen reicht sie jedoch nicht aus.
Mitarbeiter genehmigen Anfragen möglicherweise schnell, da der Agent in der Regel zufriedenstellende Ergebnisse liefert. Sie erkennen möglicherweise nicht, auf welche Daten der Agent zugegriffen hat, wie er zu seiner Schlussfolgerung gelangt ist oder ob eine scheinbar routinemäßige Anfrage einen ungewöhnlichen Schritt enthält.
Die Qualität der Genehmigung nimmt zudem ab, wenn Agenten eine große Anzahl von Entscheidungen treffen. Ein menschlicher Prüfer, der Hunderte von Anfragen mit wenig Kontext erhält, kann möglicherweise kaum mehr als eine rein formale Kontrolle ausüben.
Identitäts- und Zugriffskontrollen entlasten die menschlichen Prüfer, indem sie verhindern, dass der Agent Maßnahmen vorschlägt oder ausführt, die außerhalb seiner autorisierten Rolle liegen. Die menschliche Genehmigung kann sich dann auf wirklich folgenreiche Entscheidungen konzentrieren, anstatt ein übermäßig weit gefasstes Berechtigungsmodell ausgleichen zu müssen.
Das beste Konzept vereint beides. Der Akteur verfügt über eine klar definierte Identität, begrenzte Befugnisse und ein lückenloses Tätigkeitsprotokoll. Menschliches Eingreifen kommt dort zum Tragen, wo die potenziellen Auswirkungen dies rechtfertigen.
Die Identität ist der Ausgangspunkt für Enterprise Agents
Unternehmen bewerten KI-Agenten häufig danach, was diese leisten können. Sie vergleichen die Modellleistung, die Integrationsmöglichkeiten und den Umfang der Aufgaben, die das System automatisieren kann.
Der Einsatz in der Produktion wirft eine weitere Frage auf: In wessen Auftrag handelt der Agent?
Eine zuverlässige Antwort erfordert mehr als nur einen Namen, der in einem Dashboard angezeigt wird. Der Agent benötigt eine eindeutige technische Identität, einen verantwortlichen Sponsor, aufgabenspezifische Berechtigungen, eine sichtbare Delegierung und einen verwalteten Lebenszyklus. Seine Aktionen müssen auch dann nachvollziehbar bleiben, wenn er mit anderen Agenten zusammenarbeitet oder über mehrere Unternehmenssysteme hinweg tätig ist.
Diese Kontrollmaßnahmen beseitigen die durch autonome Software entstehenden Risiken nicht. Sie machen diese Risiken jedoch beherrschbar.
Ein Agent ohne Identität kann Zugriffsrechte ansammeln, Aktionen ausführen und Abhängigkeiten schaffen, während er gleichzeitig schwer nachverfolgbar oder zu entfernen ist. Ein Agent mit einer klar verwalteten Identität wird zu einem anerkannten Akteur im Unternehmen, dessen Befugnisse die Organisation überprüfen, einschränken und widerrufen kann.
Da Unternehmen immer mehr Agenten einsetzen, wird die Identitätsverwaltung nicht mehr nur am Rande der Implementierung stehen. Sie wird darüber entscheiden, ob das Unternehmen seine Autonomie ausweiten kann, ohne die Kontrolle zu verlieren.


