Ihr KI-Agent benötigt einen eigenen Sicherheitsbereich

Unternehmenssoftware arbeitet traditionell mit klar definierten Zugriffsberechtigungen. Ein Mitarbeiter öffnet eine Anwendung, fordert eine Aktion an, und die Software folgt einer vorgegebenen Logik. Administratoren legen fest, auf welche Systeme der Mitarbeiter zugreifen darf, welche Daten er einsehen darf und welche Vorgänge er ausführen darf. KI-Agenten verkomplizieren dieses Modell.

Ein Agent kann ein Ziel interpretieren, zwischen verschiedenen Werkzeugen wählen, Informationen abrufen, eine Anwendungsprogrammierschnittstelle aufrufen und verschiedene Aktionen ausführen, bevor er die Kontrolle wieder an den Benutzer zurückgibt. Diese Flexibilität macht einen Großteil des Wertes von Agenten aus.

Außerdem entsteht dadurch ein neues Sicherheitsproblem. Unternehmen müssen kontrollieren können, was ein Agent tun darf, wenn er sich anders verhält als von seinen Entwicklern erwartet.

Ein Agent ist eher eine Identität als ein Merkmal.

Unternehmen setzen generative KI oft so ein, als würden sie lediglich eine weitere Softwarefunktion hinzufügen. Dieser Ansatz funktioniert, solange das Modell nur Text erzeugt. Ein Agent, der innerhalb von Unternehmenssystemen agieren kann, verdient jedoch eine andere Herangehensweise. Nehmen wir beispielsweise einen Beschaffungsagenten.

Es könnte Lieferantendaten auslesen, Verträge vergleichen, eine Bestellung erstellen und Informationen an ein ERP-System übermitteln. Ein Kundendienstmitarbeiter kann auf Kontodaten zugreifen, Fälle aktualisieren und Rückerstattungen veranlassen. Ein Entwickler kann Quellcode lesen, Befehle ausführen und Änderungen bereitstellen. Jeder Agent verfügt daher über Berechtigungen. Sicherheitsteams wissen bereits, wie sie privilegierte Identitäten von Menschen und Maschinen verwalten müssen. Sie schränken den Zugriff ein, überwachen Aktivitäten und trennen sensible Systeme voneinander. KI-Agenten benötigen ähnliche Kontrollmechanismen.

Das Prinzip der geringsten Berechtigungen wird unverzichtbar

Ein Agent sollte nur Zugriff auf die Systeme und Funktionen haben, die für seine Aufgabe erforderlich sind. Dieser Grundsatz klingt selbstverständlich. Doch aus Bequemlichkeit kann er schnell untergraben werden. Entwicklungsteams verbinden einen Agenten oft mit umfangreichen internen Ressourcen, da ein umfassenderer Zugriff die Leistung während der Testphase verbessert. Sobald der Agent in die Produktion geht, bleiben diese Berechtigungen möglicherweise bestehen.

Das daraus resultierende Risiko ist schwer zu erkennen, da der Agent selbst keine böswillige Absicht haben muss. Eine ungenau formulierte Anweisung, manipulierte externe Inhalte oder ein unerwarteter Denkweg können dazu führen, dass das System legitime Berechtigungen auf unsichere Weise nutzt. Unternehmen sollten daher die Identitäten der Agenten auf eng gefasste Rollen ausrichten. Ein Agent für die Rechnungsbearbeitung benötigt keinen Zugriff auf Gehaltsdaten. Ein Kommunikationsassistent benötigt keine Berechtigung, die Cloud-Infrastruktur zu ändern. Ein Forschungsagent muss möglicherweise Dokumente lesen können, darf diese jedoch weder löschen noch veröffentlichen. Der Sicherheitsperimeter sollte sich nach der jeweiligen Aufgabe richten.

Zugangsdaten sollten nur vorübergehend gültig sein

Herkömmliche Anwendungen stützen sich oft auf langfristig gültige Anmeldedaten. Agenten machen diese Vorgehensweise jedoch riskanter. Ein autonomes System kann über mehrere Tools hinweg arbeiten, wodurch sich mehr Möglichkeiten ergeben, dass Anmeldedaten in Protokolle, Eingabeaufforderungen oder Zwischenausgaben gelangen. Temporäre Anmeldedaten verringern dieses Risiko. Anstatt einem Agenten dauerhaften Zugriff auf ein System zu gewähren, kann das Unternehmen kurzlebige Token für eine bestimmte Aktion oder Sitzung ausstellen. Die Berechtigung läuft automatisch ab, sobald die Aufgabe beendet ist. Bei risikoreichen Vorgängen kann eine zweite Genehmigung erforderlich sein, bevor die Anmeldedaten freigegeben werden. Dieses Konzept verbessert zudem die Reaktion auf Sicherheitsvorfälle. Sicherheitsteams können den Zugriff eines Agenten widerrufen, ohne das gesamte Konto eines Mitarbeiters zu beeinträchtigen oder nicht betroffene Dienste neu konfigurieren zu müssen.

Der Zugriff auf das Tool sollte explizit erfolgen

Mitarbeiter werden dann leistungsfähig, wenn sie Tools dynamisch auswählen können. Diese Fähigkeit erfordert klare Grenzen. Ein Unternehmen sollte einen genehmigten Katalog mit Tools führen, die jeder Mitarbeiter nutzen darf. Jedes Tool sollte nur die Funktionen bereitstellen, die für den vorgesehenen Arbeitsablauf erforderlich sind.

Ein Kundendienstmitarbeiter benötigt möglicherweise eine Funktion, um eine Rückerstattung innerhalb eines festgelegten Limits vorzunehmen. Er benötigt keinen uneingeschränkten Zugriff auf die zugrunde liegende Finanzdatenbank dieser Funktion. Daraus ergibt sich ein wichtiger architektonischer Unterschied. Der Mitarbeiter sollte nach Möglichkeit mit kontrollierten Geschäftsabläufen interagieren und nicht mit der rohen Infrastruktur.

Entwickler können dann auf der Grundlage dieser Aktionen Validierungsregeln festlegen: Wertgrenzen, Pflichtfelder, Kundenstatus, geografische Einschränkungen oder die Genehmigung durch einen Mitarbeiter. Der Agent bleibt dabei innerhalb einer kontrollierten Betriebsumgebung flexibel.

Externe Inhalte können zu einer Anweisung werden

Eines der ungewöhnlichsten Risiken in agentenbasierten Systemen ergibt sich aus der Art und Weise, wie Modelle Informationen verarbeiten. Ein Mensch kann in der Regel zwischen Daten und Anweisungen unterscheiden. Bei Software wird diese Unterscheidung traditionell noch strenger getroffen. Große Sprachmodelle funktionieren anders. Ein Agent, der eine Website durchsucht, eine E-Mail liest oder ein Dokument öffnet, kann auf Text stoßen, der darauf ausgelegt ist, sein Verhalten zu beeinflussen. Wenn das System vertrauenswürdige Anweisungen nicht effektiv von nicht vertrauenswürdigen Inhalten trennt, können externe Informationen die Aufgabe des Agenten beeinträchtigen. Dadurch ist die Prompt-Injektion mehr als nur ein Problem für Chatbots. Ein Agent mit Zugriff auf Werkzeuge kann potenziell auf manipulierte Anweisungen reagieren. Die Sicherheit muss daher sowohl das Modell als auch die Umgebung, in der es arbeitet, umfassen. Inhalten aus externen Quellen sollte ein geringeres Vertrauen entgegengebracht werden. Sensible Aktionen sollten einer zusätzlichen Validierung bedürfen. Agenten sollte es nicht gestattet sein, jeden Text, den sie lesen, als gleichermaßen maßgeblich zu behandeln.

Die Netzwerksegmentierung funktioniert weiterhin

Die KI führt neue Begriffe ein, doch viele bewährte Sicherheitsprinzipien behalten ihre Gültigkeit. Die Netzwerksegmentierung ist eines davon. Ein Agent, der keinen direkten Zugriff auf eine Produktionsdatenbank benötigt, sollte diesen auch nicht erhalten. Ein Agent, der in einem Geschäftsbereich tätig ist, sollte nicht automatisch auf Systeme zugreifen können, die von einem anderen Geschäftsbereich genutzt werden. Sandboxing kann hier eine zusätzliche Schutzebene bieten.

Unternehmen können ihren Mitarbeitern ermöglichen, Code auszuführen, Dateien zu bearbeiten oder Arbeitsabläufe in isolierten Umgebungen zu testen, bevor etwas in die Produktionssysteme gelangt. Dadurch lassen sich die Folgen unerwarteter Verhaltensweisen begrenzen. Ein ausgeklügeltes Modell erfordert keine ausgeklügelte Sicherheitsphilosophie. Schränken Sie die Umgebung ein, begrenzen Sie die Berechtigungen und gehen Sie davon aus, dass es irgendwann zu Ausfällen kommen wird.

Protokolle müssen sowohl Entscheidungen als auch Maßnahmen erfassen

Herkömmliche Sicherheitsprotokolle zeichnen Ereignisse auf: Ein Benutzer hat sich angemeldet, eine Datei wurde geändert, eine Transaktion wurde durchgeführt.

Die Überwachung von Agenten erfordert zusätzliche Hintergrundinformationen.

Sicherheits- und Compliance-Teams müssen unter Umständen wissen, welche Anweisung die Aufgabe ausgelöst hat, welche Tools der Agent ausgewählt hat und welche Informationen er erhalten hat, bevor er eine Maßnahme ergriffen hat.

Das bedeutet jedoch nicht, dass jeder interne Modellierungsprozess dokumentiert werden muss.

Das bedeutet, eine nachverfolgbare Kette rund um die nachfolgenden Arbeitsschritte zu schaffen.

Wenn ein Mitarbeiter einen Kundendatensatz ändert, sollte das Unternehmen in der Lage sein, die Anfrage, die Berechtigung, den Tool-Aufruf und das Ergebnis nachzuvollziehen.

Ohne diesen Nachweis werden Unternehmen Schwierigkeiten haben, Vorfälle zu untersuchen oder gegenüber Aufsichtsbehörden und Wirtschaftsprüfern nachzuweisen, dass sie die Kontrolle haben.

Die Genehmigung durch den Menschen sollte sich nach dem Risiko richten

Würde für jede Aktion eines Agenten eine menschliche Genehmigung erforderlich sein, würde dies einen Großteil des Produktivitätsvorteils zunichte machen.

Vollständige Autonomie zu gewähren, führt zum gegenteiligen Problem.

Unternehmen benötigen daher Schwellenwerte.

Maßnahmen mit geringem Risiko können automatisch durchgeführt werden. Ein interner Recherchemitarbeiter kann Dokumente ohne Genehmigung zusammenfassen. Ein Supportmitarbeiter kann routinemäßige Ticketinformationen im Rahmen vordefinierter Regeln aktualisieren.

Maßnahmen mit höherem Risiko sollten eskaliert werden.

Zahlungen, Kontoschließungen, Änderungen in der Produktion, rechtliche Eingaben oder die Kommunikation mit externen Stellen können erfordern, dass eine Person den letzten Schritt genehmigt.

Der Schwellenwert sollte eher die potenziellen Auswirkungen als die technische Komplexität widerspiegeln.

Ein scheinbar einfacher API-Aufruf kann schwerwiegende Folgen haben, wenn dabei Geld überwiesen oder personenbezogene Daten offengelegt werden.

Jeder Agent braucht einen Notausschalter

Unternehmen sollten davon ausgehen, dass sich ein Akteur irgendwann auf eine Weise verhalten wird, die sie nicht vorhergesehen haben.

Es muss sofort reagiert werden.

Administratoren sollten in der Lage sein, die Zugangsdaten eines Agenten zu sperren, aktive Sitzungen zu beenden und weitere Tool-Aufrufe zu verhindern, ohne dabei nicht betroffene Systeme herunterzufahren.

Auch die Wiederherstellungsverfahren spielen eine wichtige Rolle.

Falls der Mitarbeiter vor dem Herunterfahren Datensätze geändert hat, müssen die Teams die betroffenen Transaktionen identifizieren und diese, soweit möglich, rückgängig machen.

Im Bereich der traditionellen Cybersicherheit wurden jahrzehntelang Maßnahmen zur Eindämmung und Wiederherstellung entwickelt. Eine Agent-Architektur sollte diese von Anfang an integrieren.

Die Sicherheit bestimmt, wie autonom Agenten werden können

Unternehmen werden KI-Systemen weiterhin mehr Verantwortung übertragen, da der wirtschaftliche Anreiz auf der Hand liegt. Ein Assistent, der lediglich Textentwürfe erstellt, spart Zeit. Ein Agent, der einen gesamten Arbeitsablauf abwickeln kann, kann die Kosten und die Geschwindigkeit eines Geschäftsprozesses verändern. Das Sicherheitsmodell muss sich im gleichen Tempo weiterentwickeln. Unternehmen sollten den Zugriff von Agenten nicht länger als nebensächliches Konfigurationsproblem betrachten. Berechtigungen, Anmeldedaten, Tools, Netzwerke, Protokollierung und Genehmigungsregeln bilden die Betriebsumgebung, in der der Agent Entscheidungen trifft.

Je mehr Autonomie ein Unternehmen gewähren möchte, desto präziser muss dieses Umfeld gestaltet werden. Ein KI-Agent benötigt keinen uneingeschränkten Zugriff, um nützlich zu sein. Er benötigt genügend Freiheit, um die Aufgabe zu erfüllen, und genügend Einschränkungen, um zu verhindern, dass ein einzelner Fehler zu einem Zwischenfall wird.