Insider-Bedrohungen durch KI-Agenten rücken vertrauenswürdigen Zugriff ins Zentrum der Sicherheit
KI-Agenten haben eine kritische Grenze überschritten: Sie können heute vertrauenswürdige Zugangsdaten nutzen, um Daten zu lesen, Tools aufzurufen und Unternehmenssysteme ohne ständige Aufsicht zu verändern.
Dadurch wird die Insider-Bedrohung durch KI-Agenten von einem Problem der Modellsicherheit zu einem Problem der Zugriffskontrolle. Ein Agent benötigt keine böswillige Absicht, um Datensätze offenzulegen, unbefugte Nachrichten zu versenden oder einen unsicheren Workflow auszuführen. Er braucht lediglich legitime Berechtigungen, eine schädliche Anweisung und ausreichend Autonomie zum Handeln.
Die jüngste Argumentation von Cybersecurity Insiders verdeutlicht diese Umkehrung. Unternehmen betrachteten KI bisher als Software, die vor externen Angreifern geschützt werden musste. Sicherheitsteams müssen nun berücksichtigen, ob die Software selbst zu einem vertrauenswürdigen, aber unsicheren Akteur werden kann.
Das bedeutet nicht, dass jeder Agent als feindselig eingestuft werden sollte. Es bedeutet, dass Unternehmen Authentifizierung nicht länger als Beweis dafür behandeln können, dass eine Aktion sicher ist. Eine gültige Identität beantwortet, wer oder was Zugriff angefordert hat. Sie belegt nicht, ob die angeforderte Aktion der tatsächlichen Absicht des Nutzers entspricht.
Der sich abzeichnende Konflikt lautet daher nicht Mensch gegen Maschine. Es geht um umfassenden, dauerhaften Zugriff gegenüber enger, aufgabenspezifischer Autorisierung. Sicherheitsteams müssen entscheiden, ob Agenten die weitreichenden Zugriffsmuster übernehmen sollen, die für Mitarbeitende und herkömmliche Anwendungen geschaffen wurden.
Die Antwort wird darüber entscheiden, ob die Einführung von Agenten zu kontrollierter Automatisierung oder zu einer neuen Klasse schwer erkennbarer Insider-Vorfälle führt.
Die Insider-Bedrohung durch KI-Agenten beginnt mit legitimem Zugriff
Das entscheidende Risiko besteht nicht darin, dass ein KI-Agent den Perimeter durchbricht, sondern darin, dass er über Zugriff handelt, den das Unternehmen ihm bewusst eingeräumt hat.
Traditionelle Programme zum Umgang mit Insider-Risiken konzentrieren sich auf Mitarbeitende, Auftragnehmer und kompromittierte Konten. Diese Akteure befinden sich bereits innerhalb einer Vertrauensgrenze. Sie können Daten oder Systeme missbrauchen, ohne eine extern erreichbare Schwachstelle auszunutzen.
Agenten passen überraschend gut in dieses Modell. Sie können OAuth-Berechtigungen, Dienstidentitäten, API-Zugriff, Datenbankberechtigungen und delegierte Autorität besitzen. Außerdem können sie diese Privilegien über einen mehrstufigen Workflow hinweg kombinieren.
Ein Agent, der mit der Vorbereitung eines Vertriebsbriefings beauftragt ist, könnte Kundendaten durchsuchen, interne Notizen abrufen und eine E-Mail entwerfen. Ein Coding-Agent könnte ein Repository lesen, ein Terminal öffnen, Dateien ändern und einen Pull Request einreichen. Ein Support-Agent könnte Kontoinformationen abfragen und eine Rückerstattung veranlassen.
Jede einzelne Berechtigung kann plausibel erscheinen. Die gefährliche Fähigkeit entsteht, wenn der Agent sie in einer unerwarteten Abfolge miteinander verknüpft.
Das ist ein grundlegender Unterschied zwischen einem Agenten und einer herkömmlichen Anwendung. Traditionelle Software folgt in der Regel vorgegebenen Pfaden. Ein Agent interpretiert ein Ziel, wählt Tools aus und bestimmt Zwischenschritte zur Laufzeit.
Diese Flexibilität schafft Mehrwert, schwächt aber auch Annahmen, die in älteren Kontrollen verankert sind. Eine für einen vorgesehenen Workflow erteilte Berechtigung kann mehrere unbeabsichtigte Workflows ermöglichen. Der Agent kann diese Pfade schneller entdecken als ein menschlicher Bediener.
Prompt Injection verschärft das Problem. Prompt Injection ist ein Angriff, bei dem täuschende Anweisungen in Daten platziert werden, die ein KI-System liest. Der Agent kann diese Anweisungen mit einem Teil seiner zugewiesenen Aufgabe verwechseln.
Stellen Sie sich einen Assistenten vor, der Dokumente aus einem externen Ordner prüft. Ein Dokument enthält versteckten Text, der den Assistenten anweist, vertrauliche Dateien abzurufen und deren Inhalte an anderer Stelle zu versenden. Der Agent könnte gehorchen, weil beide Aktionen genehmigte Tools verwenden.
Das System kann einen erfolgreichen Login, ein gültiges Token und erlaubte API-Aufrufe protokollieren. Herkömmliches Monitoring erkennt autorisierte Aktivitäten. Das Unternehmen erkennt einen Datenabfluss.
OWASPs Leitfaden zu agentischen Bedrohungen identifiziert Risiken, die durch autonome Planung, Tool-Nutzung, Speicher und Interaktionen zwischen Agenten entstehen. Dies sind keine isolierten Modellverhaltensweisen. Es handelt sich um Risiken auf Systemebene, die durch die Verbindung eines Modells mit Autorität entstehen.
Dasselbe Problem tritt auf, wenn ein Agent ein unzureichend spezifiziertes Ziel erhält. „Löse alle überfälligen Anfragen“ könnte dazu führen, dass er Nachrichten versendet, Datensätze verändert oder Fälle schließt, die eine menschliche Prüfung erfordert hätten. Niemand muss das Modell zuvor kompromittieren.
Deshalb ist die Absicht ebenso wichtig wie die Identität. Ein sicheres Design muss bestimmen, wer die Aufgabe autorisiert hat, welche Ressourcen sie umfasst, welche Aktionen zulässig sind und wie lange diese Autorität gültig bleibt.
Ohne solche Grenzen wird ein authentifizierter Agent zu einem Insider mit einem ungewöhnlich hohen Arbeitstempo.
Vertrauenswürdiger Zugriff wird zum neuen Sicherheitsperimeter
KI-Agenten machen vertrauenswürdigen Zugriff wichtiger als den Netzwerkstandort, weil ihre legitime Arbeit bereits Anwendungen, Clouds und Datenspeicher übergreift.
Die Zero-Trust-Architektur hat einen Teil dieses Wandels vorweggenommen. NISTs Zero-Trust-Standard lehnt implizites Vertrauen ab, das sich allein auf Netzwerkstandort oder Eigentümerschaft eines Assets stützt. Sicherheitsentscheidungen stehen dort im Mittelpunkt, die Nutzer, Assets, Ressourcen und explizite Autorisierung berücksichtigen.
Dieses Modell wird noch dringlicher, wenn das Zugriff anfordernde Subjekt ein autonomes System ist. Ein Agent kann Grenzen überschreiten, die menschliche Insider früher ausgebremst haben. Er muss weder Geräte wechseln, mehrere Oberflächen öffnen noch Daten manuell zwischen Anwendungen kopieren.
Eine Anweisung kann eine Kette von Tool-Aufrufen auslösen. Diese Kette könnte von einer Messaging-Plattform über Cloud-Speicher in eine Kundendatenbank und anschließend zu einem externen Dienst führen. Der Agent führt die Abfolge über vertrauenswürdige Integrationen aus.
Eine Netzwerk-Firewall sieht erlaubte Verbindungen. Identitätssysteme sehen bekannte Zugangsdaten. Anwendungsprotokolle zeigen Vorgänge, die das zugewiesene Konto ausführen durfte.
Das kombinierte Ergebnis kann dennoch gegen Richtlinien verstoßen.
Sicherheit muss deshalb näher an jede einzelne Aktion rücken. Bei der Autorisierung sollten die Identität des Agenten, sein Verantwortlicher, die aktuelle Aufgabe, die angeforderte Ressource, das verwendete Tool und die umgebenden Risikosignale berücksichtigt werden.
Dafür benötigt jeder eingesetzte Agent eine eigene Identität. Gemeinsame Dienstkonten erschweren Untersuchungen, weil mehrere Agenten Aktivitäten unter einem Namen erzeugen können. Sie ermöglichen zudem, dass sich Berechtigungen ansammeln, wenn neue Workflows dasselbe Konto wiederverwenden.
Eine dedizierte Identität schafft eine nachvollziehbare Verantwortlichkeitskette. Sicherheitsteams können einen Agenten mit seinem Sponsor, seinem Zweck, den zulässigen Tools, der Bereitstellungsumgebung und dem Prüfungsrhythmus verknüpfen. Sie können einen Workflow aussetzen, ohne unabhängige Automatisierungen zu deaktivieren.
Identität allein reicht jedoch nicht aus. Ein eindeutig identifizierter Agent kann weiterhin überprivilegiert sein. Er kann eine gültige Berechtigung auch zum falschen Zeitpunkt oder für das falsche Ziel einsetzen.
Wirksame Kontrollen müssen sowohl den Umfang als auch die Dauer von Berechtigungen reduzieren. Ein Agent, der einen Quartalsbericht erstellt, sollte keinen dauerhaften Zugriff auf jede Quelle behalten, die er berührt hat. Er sollte eng begrenzte Autorität für die aktuelle Aufgabe erhalten.
Kurzlebige Zugangsdaten verkürzen die für Missbrauch verfügbare Zeit. Just-in-time-Zugriff erteilt Autorität beim Start der Aufgabe und entzieht sie anschließend wieder. Richtlinien auf Tool-Ebene begrenzen, welche Vorgänge der Agent aufrufen kann.
Diese Kontrollen spiegeln die zentrale Lehre der Insider-Bedrohung durch KI-Agenten wider. Vertrauen sollte an eine bestimmte Aktion unter bestimmten Bedingungen geknüpft sein, nicht dauerhaft an einen Agenten.
Unternehmen müssen außerdem Lesen und Handeln voneinander trennen. Ein Agent, der einen Kalender zusammenfasst, benötigt andere Autorität als einer, der Besprechungen plant. Ein System, das Codeänderungen vorschlägt, sollte nicht automatisch die Berechtigung erhalten, sie bereitzustellen.
Diese Unterscheidung kann bei einer schnellen Einführung verschwimmen. Teams beginnen mit einem schreibgeschützten Assistenten und ergänzen dann schrittweise Schreibzugriff, Browsersteuerung und Workflow-Automatisierung. Die ursprüngliche Risikobewertung entspricht nicht mehr dem eingesetzten System.
Agenten-Inventare müssen daher Fähigkeiten und nicht bloß Installationen erfassen. Sicherheitsteams müssen wissen, welche Agenten auf sensible Daten zugreifen, externe Tools aufrufen, öffentlich kommunizieren, Datensätze verändern oder Transaktionen autorisieren können.
Das Inventar muss sich ebenso schnell verändern wie die Agenten selbst.
Warum bestehende Insider-Kontrollen das Verhalten von Agenten übersehen
Kontrollen, die auf menschliche Geschwindigkeit und menschliche Motive ausgelegt sind, geraten an ihre Grenzen, wenn Software Hunderte legitime Aktionen ohne Ermüdung oder Zögern ausführen kann.
Programme für menschliche Insider-Risiken suchen häufig nach erkennbaren Verhaltensänderungen. Ein Mitarbeitender lädt ungewöhnlich große Datenmengen herunter, meldet sich zu einer unerwarteten Uhrzeit an oder greift auf eine Abteilung außerhalb seiner üblichen Rolle zu.
Diese Signale bleiben nützlich, doch Agenten schaffen eine andere Ausgangsbasis. Sie können kontinuierlich arbeiten. Sie können mehr Datensätze verarbeiten als ein Mensch. Ihre Aktivität kann von stabiler Cloud-Infrastruktur statt von einem Mitarbeiterendpunkt ausgehen.
Eine hohe Aktionsrate kann normale Automatisierung statt böswilliges Verhalten anzeigen. Eine niedrige Aktionsrate kann dennoch eine gezielt vorbereitete Offenlegung verbergen. Das Volumen allein wird zu einem unzuverlässigen Signal.
Auch die Absicht ist schwerer abzuleiten. Ein menschlicher Nutzer führt Aktionen in der Regel über eine interaktive Sitzung aus. Ermittler können diese Aktionen mit Aufgabenbereichen, Kommunikation und bekannten Geschäftsprozessen vergleichen.
Ein Agent übersetzt eine umfassende Anweisung in Zwischenentscheidungen. Der Nutzer sieht diese Entscheidungen möglicherweise nie. Die endgültige Aktion kann mehrere Schritte von der ursprünglichen Anfrage entfernt sein.
Protokolle müssen diese Kette bewahren. Ermittler sollten in der Lage sein, die Nutzeranweisung, Modellentscheidungen, abgerufenen Kontext, Tool-Auswahlen, Autorisierungsergebnisse und endgültigen Auswirkungen zu rekonstruieren.
Das bedeutet nicht, jede interne Modellberechnung zu speichern. Es bedeutet, einen prüfbaren Nachweis der relevanten externen Aktionen und der Autorität zu führen, auf der jede einzelne beruht.
Standardmäßige Anwendungsprotokolle liefern häufig nur Fragmente. Ein System zeichnet das Token auf. Ein anderes protokolliert die Datenbankabfrage. Ein drittes erfasst eine ausgehende Nachricht. Ohne eine gemeinsame Aufgabenkennung kann die Organisation sie nicht zu einem Agenten-Workflow verbinden.
Das Beobachtbarkeitsproblem wächst in Multi-Agenten-Systemen. Ein Agent kann einem anderen die Recherche delegieren, der wiederum ein drittes System bittet, ein Tool auszuführen. Autorität kann durch diese Kette wandern, obwohl der ursprüngliche Nutzer niemals jeden Beteiligten genehmigt hat.
Rekursives Vertrauen beschreibt diese wachsende Beziehung. Eine Organisation vertraut einem Agenten, der einem anderen Dienst vertraut, der wiederum auf einer anderen Identität oder einem anderen Tool beruht. Die effektive Angriffsfläche erstreckt sich über jedes Glied.
Die Insider-Bedrohung durch KI-Agenten kann diese Kette ausnutzen, ohne ein offensichtliches Eindringereignis zu erzeugen. Eine kompromittierte Tool-Antwort kann den Planungsagenten beeinflussen. Ein vergifteter Speichereintrag kann künftige Entscheidungen prägen. Ein externes Dokument kann einen vertrauenswürdigen Workflow umleiten.
Bestehende Endpunkt- und Netzwerkabwehrmaßnahmen bleiben wichtig. Sie können Malware blockieren, verdächtige Ziele erkennen und kompromittierte Infrastruktur isolieren. Sie können jedoch nicht zuverlässig entscheiden, ob eine autorisierte Geschäftsaktion dem beabsichtigten Ergebnis des Nutzers entspricht.
Diese Beurteilung erfordert einen umfassenderen Kontext.
Organisationen sollten für jede Agentenrolle Verhaltensgrundlagen festlegen. Ein Reporting-Agent könnte normalerweise genehmigte Datenquellen lesen und in einen bestimmten Dokumentenspeicher schreiben. Ein Versuch, E-Mails zu versenden oder auf Zugangsdaten zuzugreifen, läge außerhalb dieses Profils.
Richtlinien können auch Ablaufbeschränkungen durchsetzen. Das Lesen einer nicht vertrauenswürdigen Webseite sollte nicht unmittelbar den Zugriff auf vertrauliche Datensätze autorisieren. Eine Änderung der Datensensibilität sollte eine neue Autorisierungsentscheidung auslösen.
Menschliche Genehmigungen bleiben für folgenschwere Maßnahmen sinnvoll. Genehmigungsbildschirme müssen jedoch aussagekräftige Informationen enthalten. Eine vage Aufforderung zum „Fortfahren“ hilft einem Prüfer nicht zu verstehen, welche Daten übertragen werden oder welche Datensätze sich ändern.
Die Genehmigung sollte die Maßnahme, das Ziel, die betroffenen Ressourcen und die erwartete Folge benennen. Andernfalls wird der Mensch zu einer zeremoniellen Kontrollinstanz statt zu einem Sicherheitsmechanismus.
Das Prinzip der minimalen Rechte muss der Aufgabe folgen, nicht dem Agenten
Das sicherste Zugriffsmodell gibt einem Agenten nur die für eine einzelne Aufgabe erforderlichen Mindestbefugnisse und erzwingt eine neue Entscheidung, wenn sich die Aufgabe ändert.
Das Prinzip der minimalen Rechte ist seit Langem ein Sicherheitsgrundsatz. Agentische Systeme machen seine Umsetzung anspruchsvoller, weil ihre Arbeitsabläufe dynamisch sind.
Eine herkömmliche Anwendung erhält Berechtigungen, die zu einem stabilen Funktionsumfang passen. Ein Agent kann je nach Anfrage, abgerufenen Informationen oder Ergebnissen eines früheren Schritts unterschiedliche Tools auswählen.
Ihm im Voraus jede denkbare Berechtigung zu geben, vereinfacht die Entwicklung. Zugleich entsteht dadurch eine Ansammlung ungenutzter Befugnisse. Ein manipulierter Agent kann Fähigkeiten einsetzen, die für die aktuelle Aufgabe nie erforderlich waren.
Aufgabengebundene Autorisierung bietet einen besseren Weg. Das System bewertet das erklärte Ziel und erteilt eine eingeschränkte Berechtigung für die notwendige Ressource. Diese Berechtigung läuft ab, wenn der Schritt oder die Sitzung endet.
Microsofts Least-Privilege-Muster empfiehlt, Identität, Umfang, Tool-Zugriff und Auditierbarkeit festzulegen, bevor die Autonomie erweitert wird. Zudem betont es dedizierte Agentenidentitäten mit klar verantwortlichen Eigentümern.
Betrachten wir einen Agenten, der Spesenabrechnungen verarbeitet. Er muss eingereichte Dokumente lesen, sie mit Richtlinien abgleichen und eine Empfehlung vorbereiten. Er benötigt keine dauerhafte Befugnis, Zahlungen auszuführen.
Wenn das Unternehmen später automatische Erstattungen unterhalb eines festgelegten Schwellenwerts zulässt, sollte diese Schreibberechtigung getrennt vergeben werden. Das System sollte die Richtlinie dokumentieren, die sie autorisiert hat, und außerhalb dieser Grenze eine Eskalation verlangen.
Diese Aufteilung begrenzt den Schaden, wenn etwas schiefgeht. Eine bösartige Anweisung in einem Beleg könnte die Empfehlung beeinflussen. Sie sollte nicht automatisch die Fähigkeit verleihen, Geld umzuleiten.
Dasselbe Modell gilt für Wissensarbeit. Ein Recherche-Agent kann die freigegebenen Dokumente eines Teams durchsuchen, sein Ausgabeziel sollte jedoch eingeschränkt bleiben. Sensibles Quellmaterial sollte nicht in öffentliche Prompts, externe Kanäle oder nicht verwandte Projekte gelangen.
Zugriffsentscheidungen benötigen Datenkontext. Eine Dateikennzeichnung, Projektmitgliedschaft, gesetzliche Aufbewahrungspflicht, Kundenbeschränkung oder Vertraulichkeitsstufe kann verändern, ob derselbe Tool-Aufruf angemessen ist.
Organisationen, die eine AI knowledge base aufbauen, sollten Berechtigungsgrenzen als Teil der Abrufqualität behandeln. Eine hilfreiche Antwort muss auf relevante Informationen zurückgreifen, ohne Eigentums- oder Vertraulichkeitsgrenzen zu überschreiten.
Auch das Tool-Design ist wichtig. Breite Tools schaffen breite Fehlermöglichkeiten. Ein generischer Datenbank-Connector, der beliebige Abfragen ausführen kann, birgt mehr Risiken als eine zweckgebundene Funktion, die freigegebene Felder zurückgibt.
Entwickler sollten die engste sinnvolle Operation bereitstellen. Statt einem Agenten vollständigen Postfachzugriff zu geben, könnte ein Dienst ihm erlauben, Nachrichten abzurufen, die einer Fallkennung entsprechen. Statt Shell-Zugriff könnte er einen kontrollierten Build-Befehl bereitstellen.
Tool-Bindung verknüpft spezifische Agentenidentitäten mit spezifischen Operationen. Der Agent kann nicht jede verfügbare Integration aufrufen, nur weil die Plattform weiß, dass diese Tools existieren.
Auch Eingaben und Ausgaben müssen außerhalb des Modells validiert werden. Ein Modell sollte nicht allein dafür verantwortlich sein zu entscheiden, ob seine eigene vorgeschlagene Aktion gegen Richtlinien verstößt.
Eine separate Richtlinienebene kann Ziele, Datenklassifizierungen, Transaktionslimits und Aufgabenkontext prüfen. Sie kann eine Operation vor der Ausführung blockieren, verändern oder eskalieren.
Diese Trennung korrigiert ein verbreitetes Missverständnis über Agentensicherheit. Bessere Prompts und leistungsfähigere Modelle können Fehler reduzieren, aber sie können durchsetzbare Grenzen nicht ersetzen.
Ein Prompt ist eine Anweisung. Eine Autorisierungsrichtlinie ist ein Kontrollmechanismus.
Der Unterschied ist wichtig, weil ein Agent einen Prompt missverstehen, vergifteten Kontext übernehmen oder widersprüchliche Anweisungen erhalten kann. Eine Policy Engine sollte Grenzen weiterhin durchsetzen, selbst wenn das Modell unvorhersehbar handelt.
Zero Trust hilft, löst aber nicht die Frage der Absicht
Zero Trust kann die Reichweite eines Agenten begrenzen, aber nicht automatisch bestimmen, ob eine erlaubte Aktion dem tatsächlichen Ziel des Nutzers dient.
Das ist der zentrale Zielkonflikt in der Debatte über vertrauenswürdigen Zugriff. Sicherheitsanbieter positionieren Identität, bedingten Zugriff und Zero Trust zunehmend als Antworten auf Agentenrisiken. Diese Kontrollen adressieren wichtige Schwachstellen.
Microsofts Zero Trust for AI erweitert explizite Verifizierung und minimale Rechte auf KI-Daten, Modelle, Workloads, Nutzer und Agentenverhalten. Microsoft beschreibt zudem manipulierte, überprivilegierte oder fehlgeleitete Agenten als mögliche „Doppelagenten“.
Diese Einordnung ist hilfreich, doch Organisationen sollten Zero Trust nicht als vollständige Produktkategorie behandeln. NIST beschreibt Zero Trust als eine Reihe architektonischer Prinzipien, nicht als einzelnen Technologieeinkauf.
Eine Organisation kann moderne Identitätskontrollen einführen und Agenten dennoch mit übermäßigen Berechtigungen ausstatten. Sie kann Authentifizierung verlangen, ohne eine Agentenaufgabe von einer anderen zu unterscheiden. Sie kann Protokolle erfassen, die niemand überprüft.
Die schwierigsten Fälle betreffen Aktionen, die sowohl autorisiert als auch plausibel sind.
Ein Kundenservice-Agent darf möglicherweise rechtmäßig auf Kundendaten zugreifen und Nachrichten versenden. Ein Coding-Agent darf möglicherweise rechtmäßig Quelldateien verändern. Ein Beschaffungs-Agent darf möglicherweise rechtmäßig Lieferanten kontaktieren.
Die bösartige oder fehlerhafte Variante jeder dieser Aktionen kann auf der Identitätsebene nahezu identisch aussehen.
Kontextbezogene Autorisierung verringert diese Lücke. Das System kann fragen, ob das Ziel freigegeben ist, ob die angeforderten Felder erforderlich sind, ob die Aktion dem bisherigen Verhalten entspricht und ob die Datenklassifizierung die Übertragung erlaubt.
Dennoch erzeugen Kontextmodelle falsch positive und falsch negative Ergebnisse. Strenge Kontrollen können nützliche Arbeitsabläufe unterbrechen. Lockere Kontrollen können Produktivität erhalten und zugleich schädliche Kombinationen zulassen.
Die Organisation muss entscheiden, wo Autonomie endet. Niedrigschwellige, reversible Aufgaben können mehr Freiheit tolerieren. Folgenschwere, irreversible Aufgaben erfordern stärkere Verifizierung und häufig menschliche Genehmigung.
Reversibilität verdient besondere Aufmerksamkeit. Ein Agent, der eine Nachricht entwirft, erstellt ein überprüfbares Artefakt. Ein Agent, der die Nachricht versendet, verändert die Außenwelt. Ein Agent, der das Löschen von Datensätzen empfiehlt, unterscheidet sich von einem, der sie löscht.
Die Sicherheitsarchitektur sollte diese Unterschiede widerspiegeln.
Teams sollten Agenten auch als Systeme testen, nicht nur als Modelle. Modellevaluierungen können messen, ob ein Agent unter kontrollierten Bedingungen Anweisungen befolgt. Das Produktionsrisiko hängt von Tools, Zugangsdaten, Speicher, Datenquellen und umgebenden Anwendungen ab.
Red-Team-Übungen sollten bösartige Dokumente, mehrdeutige Ziele, kompromittierte Tool-Antworten und unerwartete Berechtigungskombinationen einführen. Ziel ist zu beobachten, ob externe Kontrollen Fehler eindämmen.
Das OWASP-Framework hilft Teams, diese Bedrohungen zu erfassen, während NISTs Cloud-Zugriffsmodell erläutert, wie Richtlinien auf Identitätsebene und granulare Anwendungskontrollen Zero Trust über verteilte Dienste hinweg unterstützen.
Keines von beiden garantiert, dass ein Agent geschäftliche Absichten versteht. Diese Unsicherheit muss bei Bereitstellungsentscheidungen sichtbar bleiben.
Sicherheitsverantwortliche sollten daher Behauptungen hinterfragen, wonach eine Plattform „Agenten absichert“, ohne den Umfang zu erläutern. Erkennt sie Agentenidentitäten? Steuert sie Berechtigungen? Prüft sie Tool-Aufrufe? Schützt sie Prompts und Daten? Erhält sie systemübergreifende Audit-Trails?
Die meisten Produkte decken nur einen Teil des Lebenszyklus ab. Unternehmen werden weiterhin Richtlinienverantwortung, operative Prozesse, Incident Response und anwendungsspezifische Kontrollen benötigen.
Die Insider-Bedrohung durch AI agents ist keine einzelne Schwachstelle mit einem einzelnen Patch. Sie ist die Folge davon, probabilistische Entscheidungsträger in vertrauenswürdige Arbeitsabläufe einzubetten.
Drei Signale werden zeigen, ob sich vertrauenswürdiger Zugriff verbessert
Die nächste Phase der KI-Sicherheit wird an einsetzbaren Kontrollen und Erkenntnissen aus Vorfällen gemessen werden, nicht an umfassenderen Versprechen über verantwortungsvolle Agenten.
Das erste Signal ist die Einführung eigenständiger, kontrollierter Agentenidentitäten. Organisationen sollten Agenten auflisten, ihre Eigentümer identifizieren, ihre Berechtigungen überprüfen und sie einzeln deaktivieren können.
Microsoft Entras Agent Identity Framework zeigt, wohin sich große Identitätsplattformen entwickeln. Es unterstützt dedizierte Agentenkonstrukte, Aktivitätsprotokollierung, Governance und bedingten Zugriff für nichtmenschliche Akteure.
Andere Identitäts- und Cloud-Anbieter werden unter Druck geraten, vergleichbare Kontrollen über heterogene Umgebungen hinweg anzubieten. Unternehmen betreiben selten nur eine Agentenplattform oder ein Identitätssystem.
Fortschritt wird glaubwürdig, wenn Administratoren eine einzelne Agentenaktion über Anwendungen hinweg nachverfolgen können, ohne sich auf ein gemeinsam genutztes Dienstkonto zu stützen. Bleiben dedizierte Identitäten optional oder plattformspezifisch, bleibt die Sichtbarkeit fragmentiert.
Das zweite Signal ist die breitere Nutzung aufgabengebundener, kurzlebiger Autorisierung. Agentenplattformen sollten Zugriff für eine klar definierte Operation anfordern, statt dauerhafte Berechtigungen von einem Nutzer oder Entwickler zu übernehmen.
Diese Veränderung erfordert eine bessere Integration zwischen Orchestrierungssystemen und Identitätsinfrastruktur. Die Plattform muss beschreiben, was der Agent tun will, und zwar in einer Form, die eine Policy Engine bewerten kann.
Auch Genehmigungsoberflächen müssen sich verbessern. Nutzer sollten Ressource, Aktion, Ziel und erwartete Wirkung sehen, bevor sie sensible Befugnisse erteilen.
Wenn Anbieter diese Kontrollen standardmäßig ausliefern, wird die These des vertrauenswürdigen Zugriffs überzeugender. Wenn eine sichere Konfiguration umfangreiches Custom Engineering erfordert, werden Teams unter Lieferdruck weiterhin breite Berechtigungen wählen.
Das dritte Signal sind öffentliche Erkenntnisse aus realen Vorfällen und unabhängigen Tests. Sicherheitsteams müssen wissen, wie Agenten außerhalb von Demonstrationen versagen.
Nützliche Offenlegungen erläutern die ursprüngliche Anweisung, den Zugriffspfad, die beteiligten Tools, die versagte Kontrolle und den Punkt, an dem die Eindämmung gelang. Vage Verweise auf unsichere Ausgaben liefern nicht genügend architektonische Orientierung.
Unabhängige Evaluierungen sollten vollständige Agentensysteme gegen Prompt Injection, übermäßige Handlungsfähigkeit, vergifteten Speicher, Offenlegung von Zugangsdaten und agentenübergreifende Manipulation testen. Sie sollten außerdem messen, ob Kontrollen nützliche Arbeit erhalten.
Die Berichterstattung über Vorfälle wird verdeutlichen, welche Risiken dominieren. Prompt Injection erhält viel Aufmerksamkeit, doch Konfigurationsfehler, übermäßige Berechtigungen, gemeinsam genutzte Identitäten und ungeprüfte Integrationen könnten sich als ebenso wichtig erweisen.
Das Ergebnis wird Ausgaben und Designprioritäten prägen. Wenn die meisten Vorfälle gestohlene Zugangsdaten betreffen, erhält Identitätsschutz Vorrang. Wenn gültige Agenten erlaubte Tools wiederholt missbrauchen, werden Laufzeitautorisierung und Verhaltenskontrollen zum zentralen Schlachtfeld.
Unternehmen müssen nicht auf perfekte Standards warten. Sie können Agenten schon jetzt inventarisieren, Identitäten trennen, ungenutzte Berechtigungen entfernen, Tools beschränken, Aktionsketten protokollieren und für irreversible Operationen Genehmigungen verlangen.
Sie sollten außerdem festlegen, was passiert, wenn ein Agent unerwartet handelt. Schnelle Suspendierung, Widerruf von Zugangsdaten, Isolierung von Workflows und Beweissicherung gehören in den Incident-Response-Plan.
Die praktische Frage ist einfach: Kann Ihre Organisation jede folgenreiche Agentenaktion erklären und seine Berechtigung widerrufen, ohne einen gesamten Geschäftsprozess zu deaktivieren?
Wenn die Antwort nein lautet, genießt der Agent mehr Vertrauen, als die Sicherheitsarchitektur sicher verwalten kann.
Die Insider-Bedrohung durch KI-Agenten verändert die Reihenfolge der Maßnahmen. Unternehmen können nicht zuerst weitreichende Zugriffe gewähren und die Überwachung erst nach der Bereitstellung ergänzen. Identität, Aufgabengrenzen, Nachvollziehbarkeit und Eindämmung müssen vor der Autonomie vorhanden sein.
Für Entwickler und Unternehmenskäufer sollte die nächste Bewertung über die Frage hinausgehen, ob ein Agent eine Demo abschließt. Fragen Sie, worauf er zugreifen kann, wann diese Berechtigung erlischt und ob eine unabhängige Kontrolle die endgültige Aktion stoppen kann.
Vertrauenswürdiger Zugriff ist jetzt das Schlachtfeld, weil Zugriff Modellausgaben in reale Folgen verwandelt. Die Organisationen, die diesen Übergang steuern, werden den Wert der Automatisierung erschließen, ohne jede authentifizierte Aktion automatisch als vertrauenswürdig zu behandeln.
