Drei KI-Sicherheitsfehler gefährden Unternehmen
Google News machte auf eine InfoWorld-Warnung zu drei Konflikten aufmerksam, die Unternehmen nicht länger als theoretische KI-Risiken behandeln können. Vertrauenswürdige Modelle können feindliche Anweisungen verarbeiten, Agenten können übermäßige Berechtigungen übernehmen, und Freigabemasken für Menschen können die tatsächlich autorisierte Aktion verschleiern.
Die Überschrift ist relevant, weil Unternehmen von dialogbasierten Assistenten zu Systemen übergehen, die Dateien lesen, Anwendungen aufrufen, Code ändern und Geschäftsprozesse auslösen. Dieser Wandel macht aus einer fehlerhaften Antwort einen potenziellen Sicherheitsvorfall. Der zentrale Konflikt ist nun klar: schnelle KI-Einführung gegen durchsetzbare Grenzen dafür, was jedes System sehen und tun darf.
Das Problem besteht nicht darin, dass jedes Modell plötzlich böswillig geworden ist. Vielmehr verlieren vertraute Kontrollen häufig ihre Bedeutung, wenn probabilistische Software zwischen Daten, Nutzern, Zugangsdaten und Tools sitzt. Jüngste Vorfälle bei Microsoft, Google, Amazon, Anthropic, Cursor und anderen Anbietern zeigen, wie schnell diese Lücke operativ werden kann.
Die Google-News-Warnung betrifft Kontrolle, nicht Intelligenz
Der gefährlichste Fehler in Unternehmen besteht darin, das Modellverhalten als primäre Sicherheitsgrenze zu behandeln.
Der Google News listing verweist auf eine InfoWorld-Überschrift über drei Sicherheitsfehler, die Unternehmen heimsuchen. Das übergeordnete Signal ist wichtiger als die saisonale Einordnung. Unternehmen verbinden Sprachmodelle mit wertvollen Systemen, bevor sie die Grenzen rund um diese Verbindungen neu definieren.
Ein Chatbot erzeugte früher Text, den eine Person prüfte. Ein KI-Agent kann heute entscheiden, welches Tool aufgerufen wird, Argumente zusammenstellen, gespeicherte Zugangsdaten verwenden und mehrere Schritte hinweg fortfahren. Diese größere Reichweite macht Modellfehler zu Problemen der Anwendungssicherheit.
Organisationen reagieren häufig, indem sie mehr Anweisungen in den System-Prompt aufnehmen. Sie weisen das Modell an, keine vertraulichen Informationen offenzulegen, keinen nicht vertrauenswürdigen Befehlen zu folgen oder gefährliche Aktionen auszuführen. Solche Anweisungen können das Verhalten verbessern, schaffen jedoch keine durchsetzbare Autorisierungsgrenze.
Prompt Injection erklärt, warum. Eine Prompt Injection sind bösartige oder irreführende Inhalte, die ein Modell dazu bringen, unbeabsichtigten Anweisungen zu folgen. Eine indirekte Injection gelangt über Material hinein, das das Modell abruft, etwa eine E-Mail, Webseite, ein Dokument, Issue oder Repository.
Das Modell muss sowohl vertrauenswürdige Anweisungen als auch nicht vertrauenswürdige Inhalte über dieselbe natürlichsprachliche Schnittstelle interpretieren. Es kann einen Satz in einem Kontext als Daten erkennen und ähnlichen Text an anderer Stelle als Befehl behandeln. Kein Prompt kann die Berechtigungen verändern, die von der umgebenden Anwendung gewährt werden.
Die OWASP risk list setzt Prompt Injection an die erste Stelle ihrer Risiken für Anwendungen mit Large Language Models im Jahr 2025. Sie nennt zudem die Offenlegung sensibler Informationen, Schwächen in der Lieferkette, unsachgemäße Verarbeitung von Ausgaben und übermäßige Handlungsbefugnisse.
Diese Trennung vermittelt eine hilfreiche Erkenntnis. Prompt Injection ist häufig der Auslöser, doch die umgebende Architektur bestimmt die Folgen. Ein kompromittierter Assistent ohne Geheimnisse und ohne Schreibzugriff hat einen begrenzten Schadensradius. Dieselbe Eingabe wird ernst, wenn ein Agent E-Mails lesen, private Daten abfragen, Code ausführen oder Cloud-Ressourcen verändern kann.
Deshalb führt besseres Modellschlussfolgern nicht automatisch zu besserer Sicherheit. Ein leistungsfähigeres Modell kann legitime Pläne zuverlässiger umsetzen. Es kann aber auch verbundene Systeme effektiver navigieren, nachdem ein Angreifer seinen Plan umgeleitet hat.
Unternehmen sollten KI daher als nicht vertrauenswürdige Entscheidungskomponente innerhalb eines größeren Sicherheitssystems bewerten. Das Modell kann eine Aktion vorschlagen, doch deterministische Kontrollen müssen entscheiden, ob diese Aktion zulässig ist. Zu diesen Kontrollen zählen Identitätsprüfungen, Richtliniendurchsetzung, Eingabeisolation und Ausgabevalidierung.
Dieses Prinzip verändert auch, wie Teams Fehler untersuchen. Eine ungewöhnliche Antwort ist nicht bloß ein Qualitätsproblem, wenn das Modell Tools besitzt. Prüfer müssen fragen, welche Identität die Anfrage ausgeführt hat, welche Daten in den Kontext gelangten und welcher externe Zustand verändert wurde.
Die drei Fehler der Überschrift verbindet diese fehlende Kontrollebene. Unternehmen vertrauen dem Modell, den Berechtigungen darum herum und dem den Nutzern gezeigten Freigabeprozess. Jede Schicht kann versagen und dabei normal erscheinen.
Fehler Eins: Modellleitplanken als Sicherheitskontrollen behandeln
Eine Modellverweigerung ist eine Verhaltenspräferenz, während eine Zugriffskontrollregel eine durchsetzbare Entscheidung ist.
Unternehmen beginnen KI-Sicherheitsprüfungen häufig damit, zu testen, ob ein Modell verbotene Anfragen ablehnt. Diese Arbeit ist wertvoll, insbesondere zur Missbrauchsverhinderung und Einhaltung von Richtlinien. Sie beantwortet jedoch nicht, ob die gesamte Anwendung Geheimnisse schützen oder manipuliertem Kontext widerstehen kann.
Eine Modellleitplanke arbeitet typischerweise durch Training, Filterung, Klassifizierung oder schriftliche Anweisungen. Diese Maßnahmen beeinflussen Antworten. Sie können keine Datenbankberechtigung entziehen, die Laufzeit eines Tokens verkürzen oder verhindern, dass eine Anwendung vertrauliche Datensätze in den Kontext übergibt.
Der Unterschied wird wichtig, wenn Retrieval-Augmented Generation eingesetzt wird. Retrieval-Augmented Generation, kurz RAG, stellt einem Modell ausgewählte Unternehmensdokumente bereit, bevor es antwortet. Das Modell kann nur über Material nachdenken, das ihm die Retrieval-Schicht liefert, wodurch Retrieval-Berechtigungen Teil der Sicherheitsgrenze werden.
Wenn diese Schicht Dokumente ausschließlich nach semantischer Relevanz zurückliefert, kann sie organisatorische Grenzen überschreiten. Ein nützlich wirkender Abschnitt könnte zu einer anderen Abteilung, einem anderen Kunden oder einer anderen Rechtsangelegenheit gehören. Die flüssige Zusammenfassung des Modells kann dann den zugrunde liegenden Autorisierungsfehler verbergen.
Dasselbe Risiko entsteht, wenn Anwendungen Inhalte von außerhalb des Unternehmens abrufen. Ein Recherche-Agent könnte Webseiten, Anhänge, Support-Tickets und gemeinsam genutzte Dokumente lesen. Jede dieser Quellen kann Anweisungen enthalten, die für den Agenten bestimmt sind, statt nützliche Informationen für den Mitarbeiter zu liefern.
Microsofts Beschreibung der behobenen EchoLeak-Schwachstelle zeigt die Schwere dieses Angriffswegs. Das Unternehmen erklärt, dass der Angriff unter bestimmten Bedingungen eine mehrstufige, promptübergreifende Injection nutzte, um begrenzte Daten zu exfiltrieren, auf die ein Opfer zugreifen konnte. Microsoft behandelte das Problem als CVE-2025-32711.
Die Bedeutung der EchoLeak guidance reicht über ein einzelnes Produkt hinaus. Sie zeigte, dass ein produktiver Assistent externe Inhalte, internen Zugriff und Modellverhalten zu einem Pfad für Datenexfiltration verbinden kann.
Eine reine Prompt-Abwehr fordert das Modell auf, die Manipulation zu erkennen. Eine Systemabwehr geht davon aus, dass die Erkennung scheitern kann. Sie begrenzt dann abgerufene Daten, blockiert gefährliche Ausgabekanäle und überprüft jede sensible Operation außerhalb des Modells.
Das National Institute of Standards and Technology vertritt einen ähnlich umfassenden Ansatz. Sein generative AI profile behandelt Risiken über Design, Entwicklung, Bereitstellung, Bewertung und Nutzung hinweg. Es reduziert KI-Sicherheit nicht auf Modellfilterung.
Dieser Lebenszyklusansatz ist wichtig, weil Unternehmensanwendungen viele Komponenten enthalten. Dazu gehören Modellanbieter, Vektordatenbanken, Identitätssysteme, Plugins, APIs, Monitoring-Tools und Benutzeroberflächen. Eine Sicherheitsprüfung, die nur das Modell testet, lässt den Großteil dieser Kette unberührt.
Ein praktischer Test sollte mit Annahmen über kompromittierten Kontext beginnen. Prüfer können feindliche Anweisungen in Dokumente einfügen, die die Anwendung normalerweise abruft. Anschließend können sie beobachten, ob der Agent Daten preisgibt, sein Ziel verändert oder einen nicht autorisierten Tool-Aufruf versucht.
Teams sollten diese Tests nach Änderungen an Modellen, Prompts, Konnektoren, Retrieval-Einstellungen oder Tool-Beschreibungen wiederholen. KI-Verhalten kann sich verschieben, selbst wenn der Anwendungscode unverändert aussieht. Eine erfolgreiche Bewertung aus dem vorherigen Quartal garantiert nicht, dass der aktuelle Workflow identisch funktioniert.
Modell-Upgrades schaffen eine weitere Quelle falscher Sicherheit. Ein Anbieter kann das Verweigerungsverhalten verbessern und zugleich andere Planungsmuster einführen. Eine Anwendung, die von einer nicht dokumentierten Verweigerung abhängig war, kann ohne formelle Berechtigungsänderung weniger vorhersehbar werden.
Die sicherere Architektur behandelt Prompts als eine Verteidigungsschicht. Sie kombiniert sie mit Zugriffskontrollen, die das Modell nicht umschreiben kann. Sensible Daten sollten unzugänglich bleiben, sofern Nutzer, Aufgabe und Ressource nicht alle eine explizite Richtlinie erfüllen.
Auch Ausgaben müssen geprüft werden, bevor sie zu Aktionen werden. Eine generierte Datenbankabfrage sollte Autorisierung und Validierung durchlaufen. Eine vorgeschlagene E-Mail sollte Zielprüfungen unterzogen werden. Code sollte in einer isolierten Umgebung mit eng begrenztem Dateisystem- und Netzwerkzugriff ausgeführt werden.
Diese Struktur beseitigt Prompt Injection nicht. Sie verhindert, dass eine erfolgreiche Injection automatisch zu einem Sicherheitsverstoß wird. Das ist das realistischere Ziel für Unternehmenssicherheit.
Fehler Zwei: KI-Agenten Berechtigungen im Umfang eines Menschen geben
Ein Agent sollte die kleinste temporäre Berechtigung erhalten, die für eine Aufgabe nötig ist, nicht den dauerhaften Zugriff seines Nutzers.
Der zweite Fehler entsteht, wenn ein Unternehmen einen KI-Agenten mit vorhandenen Mitarbeiter-Zugangsdaten verbindet. Dieser Ansatz ist bequem, weil Anwendungen diese Identitäten bereits verstehen. Er gibt probabilistischer Automatisierung jedoch auch die Reichweite, die sich um ein menschliches Konto angesammelt hat.
Mitarbeiter benötigen oft weitreichenden Zugriff, weil ihre Aufgaben im Lauf der Woche variieren. Ein Agent, der eine eng umrissene Anfrage bearbeitet, braucht nicht denselben Umfang. Wenn er jedes zugängliche Postfach, Repository, jeden Kundendatensatz und jedes Cloud-Tool übernimmt, wird sein Schadensradius unnötig groß.
OWASP beschreibt dieses Problem als übermäßige Handlungsbefugnis. Die Schwachstelle entsteht, wenn ein KI-System zu viel Funktionalität, zu viele Berechtigungen oder zu viel Autonomie erhält. Manipulierte Ausgaben können dann schädliche Aktionen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit auslösen.
Das Wort „Handlungsbefugnis“ kann das Risiko abstrakt wirken lassen. In der Praxis bedeutet es gewöhnliche Berechtigungen, die an einen unvorhersehbaren Planer gekoppelt sind. Ein Modell wählt einen Tool-Aufruf, die Anwendung stellt Zugangsdaten bereit, und ein anderes System akzeptiert die Anfrage als autorisiert.
Das traditionelle Prinzip der minimalen Rechte bleibt der richtige Ausgangspunkt. Jeder Agent benötigt eine eigene Identität, eine klar definierte Aufgabe und eine kurze Liste erlaubter Ressourcen. Diese Identität sollte nicht unbemerkt den Shell-Zugriff eines Entwicklers oder den gesamten Dokumentenbestand einer Führungskraft übernehmen.
Zugangsdaten sollten außerdem schnell ablaufen. Langlebige Schlüssel ermöglichen es, dass ein Fehler oder eine Kompromittierung über das Ende der ursprünglichen Sitzung hinaus fortbesteht. Kurzlebige Tokens verkürzen dieses Zeitfenster und schaffen klarere Audit-Aufzeichnungen für jede Aufgabe.
Schreibzugriff verdient eine separate Behandlung gegenüber Lesezugriff. Viele Assistenten können nützliche Zusammenfassungen liefern, ohne Quellsysteme zu verändern. Unternehmen sollten dort beginnen und erst nach Tests des vollständigen Pfads eng begrenzte Aktionen hinzufügen.
Vorgänge mit hoher Auswirkung benötigen transaktionale Grenzen. Ein Agent, der eine Kundenerstattung vorbereitet, kann Belege zusammenstellen und einen Betrag empfehlen. Ein separater deterministischer Dienst sollte Richtlinien, Autorisierung, Ziel und Grenzen prüfen, bevor etwas ausgezahlt wird.
Dasselbe Muster gilt für die Softwareentwicklung. Ein Agent kann einen Patch in einem temporären Workspace vorschlagen. Er sollte nicht automatisch Zugriff auf Produktionszugangsdaten, Deployment-Systeme, persönliche Konfigurationsdateien oder nicht zusammenhängende Repositories erben.
Auch der Netzwerkzugriff verdient Beschränkungen auf Aufgabenebene. Ein Coding-Agent, der lediglich Paketdokumentation benötigt, sollte keine beliebigen externen Server erreichen können. Ein Rechercheassistent kann über einen zugelassenen Abrufdienst arbeiten, der private Adressen, gefährliche Protokolle und nicht vertrauenswürdige Downloads blockiert.
Tool-Beschreibungen sind keine Berechtigungskontrollen. Einem Agenten mitzuteilen, dass eine Funktion nur für einen bestimmten Zweck verwendet werden darf, verhindert keine unbefugte Ausführung. Der empfangende Dienst muss durchsetzen, wer sie aufrufen darf, welche Argumente gültig sind und welche Ressourcen im zulässigen Umfang bleiben.
Hier kollidieren viele Enterprise-AI-Programme mit der Geschwindigkeit der Bereitstellung. Produktteams wollen einen Connector, der für viele Anwendungsfälle funktioniert. Sicherheitsteams benötigen getrennte Bereiche, Identitäten, Protokolle und Freigaberegeln für jede relevante Aktion.
Die Spannung ist real, doch weitreichender Zugriff ist nicht das einzige praktikable Design. Unternehmen können Capabilities für einzelne Aufgaben vergeben. Eine Capability ist eine eng definierte Berechtigung, die eine Aktion auf einer Ressource für einen begrenzten Zeitraum autorisiert.
Dieser Ansatz verbessert auch Untersuchungen. Protokolle können zeigen, dass eine bestimmte Agenteninstanz für eine Supportanfrage drei genehmigte Datensätze gelesen hat. Gemeinsame Benutzerzugangsdaten erzeugen dagegen einen Strom von Aktionen, der sich oft nur schwer zuordnen lässt.
Datenminimierung gehört in dasselbe Design. Ein Agent benötigt kein vollständiges Dokument, wenn ein gefiltertes Feld die Frage beantwortet. Er benötigt nicht jedes Kundenkonto, wenn die Aufgabe ein einzelnes Konto benennt.
Teams, die durchsuchbare interne Systeme aufbauen, stoßen früh auf dieses Problem. Eine sichere technische Wissensdatenbank muss Quellberechtigungen erhalten, statt jede Datei in einen einzigen uneingeschränkten Index zu überführen.
Der entscheidende Vergleich lautet nicht Agenten gegen Menschen. Es geht um dauerhaften menschlichen Zugriff gegenüber aufgabenspezifischem Maschinenzugriff. Maschinen arbeiten schneller, wiederholen Aktionen konsistent und können einen Fehler auf viele Datensätze skalieren.
Unternehmen sollten entsprechend gestalten. Ein System, das während einer Sitzung Hunderte Male handeln kann, benötigt engere Grenzen als eine Person, die eine einzelne bewusste Änderung vornimmt. Geschwindigkeit vergrößert sowohl Produktivität als auch Schaden.
Fehler Drei: Anzunehmen, dass menschliche Freigabe eine Aktion sicher macht
Menschliche Beteiligung bietet wenig Schutz, wenn die Oberfläche Ziel, Zeitpunkt oder Folge der vorgeschlagenen Aktion verbirgt.
Viele Enterprise-AI-Produkte beziehen vor folgenreichen Vorgängen eine Person ein. Der Agent zeigt einen Bestätigungsdialog an, und der Nutzer entscheidet, ob fortgefahren werden soll. Dieses Design wirkt beruhigend, weil die Verantwortung sichtbar beim Menschen bleibt.
Der Schutz hängt davon ab, was die Person tatsächlich sehen kann. Eine vage Aufforderung wie „diese Änderung zulassen“ ermöglicht keine informierte Entscheidung. Ebenso wenig eine Freigabeoberfläche, die auf Inhalten basiert, die ein Angreifer beeinflussen kann.
Die GhostApproval-Forschung von Wiz legte dieses Problem bei sechs bekannten AI-Coding-Assistenten offen. Zu den betroffenen Produkten zählten Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity und Windsurf.
Laut den GhostApproval-Ergebnissen konnte ein bösartiges Repository symbolische Links verwenden, um eine scheinbar lokale Dateiänderung aus dem Workspace heraus umzuleiten. Ein symbolischer Link ist ein Dateisystemverweis, der einen Pfad auf einen anderen Ort verweist.
Die sichtbare Freigabe konnte eine harmlose Projektdatei nennen, während der aufgelöste Pfad auf eine sensible Systemdatei zielte. Bei einigen getesteten Produkten berichtete Wiz, dass Schreibvorgänge vor einer aussagekräftigen Autorisierung stattfanden. Dadurch wurde die Oberfläche von einer Sicherheitsschranke zu einem Mechanismus zum Rückgängigmachen.
Die Ergebnisse bedeuten nicht, dass jede aktuelle Version weiterhin verwundbar ist. Wiz berichtete über Korrekturen oder Reaktionen mehrerer Anbieter, und das Produktverhalten kann sich schnell ändern. Das dauerhafte Problem ist das durch die Forschung offengelegte Vertrauensmodell.
Menschliche Freigabe funktioniert nur, wenn das System kanonische, unabhängig verifizierte Details präsentiert. Bei einem Dateivorgang gehören dazu der aufgelöste Pfad, der Vorgangstyp, die Inhaltsdifferenz, die Prozessidentität und die Frage, ob sich das Ziel außerhalb des autorisierten Workspace befindet.
Bei einer Nachricht benötigen Nutzer den tatsächlichen Empfänger, angehängte Daten und die Sendeidentität. Bei einer Zahlung benötigen sie Ziel, Betrag, Autorisierungsquelle und das Ergebnis der Richtlinienprüfung. Bei einer Cloud-Änderung benötigen sie Konto, Ressource, Region und die erwartete Auswirkung.
Die Anwendung muss diese Fakten aus vertrauenswürdigem Systemzustand erzeugen. Sie sollte sich nicht auf die natürlichsprachliche Zusammenfassung des Agenten verlassen. Dasselbe Modell, das um Berechtigung bittet, hat – absichtlich oder nicht – einen Anreiz, die Aktion als nützlich darzustellen.
Der Zeitpunkt ist ebenso wichtig. Die Freigabe muss erfolgen, bevor das System externen Zustand verändert. Ein Button, der nach einem Dateischreibvorgang, API-Aufruf oder einer Nachrichtenübermittlung erscheint, kann das Ereignis nicht verhindern.
Unternehmen müssen zudem Genehmigungsmüdigkeit vermeiden. Wenn Nutzer häufig Anfragen für harmlose Vorgänge erhalten, lernen sie, diese zu akzeptieren, ohne Details zu prüfen. Angreifer können dann eine gefährliche Anfrage zwischen vertrauten Aufforderungen verstecken.
Risikobasierte Freigaben bieten ein besseres Muster. Aktionen mit geringer Auswirkung können innerhalb strenger Grenzen erfolgen. Sensible Vorgänge erhalten umfassendere Offenlegung, stärkere Authentifizierung und unabhängige Richtlinienprüfungen.
Manche Aktionen sollten niemals von einem einzigen Klick abhängen. Das Löschen von Produktionsdaten, Änderungen an Zugriffsrichtlinien, der Export großer Datensätze oder die Änderung von Deployment-Zugangsdaten können eine zweite Identität oder eine außerhalb des Kanals erfolgende Prüfung erfordern.
Das entfernt Menschen nicht aus dem Prozess. Es gibt ihnen eine Entscheidung, die sie realistisch bewerten können. Menschen eignen sich am besten für Urteilsvermögen, nicht für die Überprüfung verborgener technischer Zustände unter Zeitdruck.
Sicherheitsteams sollten Freigabeoberflächen adversarial testen. Sie können prüfen, ob lange Dateinamen das Ziel verbergen, ob Formatierungen Warnungen verschleiern können und ob ein kompromittiertes Dokument den angezeigten Text beeinflussen kann.
Sie sollten auch Race Conditions untersuchen. Der geprüfte Zustand muss zwischen Freigabe und Ausführung unverändert bleiben. Wenn ein Angreifer nach der Freigabe eine Datei, ein Ziel oder ein Argument ersetzen kann, deckt die sichtbare Entscheidung die tatsächliche Aktion nicht mehr ab.
Die Aufmerksamkeit von Google News für Enterprise-AI-Sicherheit spiegelt eine breitere Korrektur wider. „Human in the loop“ ist keine vollständige Beschreibung einer Kontrolle. Prüfer müssen wissen: welcher Mensch, welche Informationen, welcher Zeitpunkt und welche unabhängig durchgesetzte Grenze.
Warum Unternehmen diese drei Fehler immer wieder machen
Bereitstellungsanreize belohnen sichtbare AI-Fähigkeiten, während verlässliche Grenzen für Käufer langsamer und weniger sichtbar bleiben.
Die drei Fehler bestehen fort, weil jeder eine bequeme Abkürzung bietet. Prompt-Anweisungen sind einfacher als die Neugestaltung von Zugriffskontrollen. Gemeinsame Zugangsdaten sind einfacher als aufgabenspezifische Identitäten. Bestätigungsbuttons sind einfacher als überprüfbare Autorisierungsabläufe.
Demos verstärken diese Abkürzungen. Eine erfolgreiche Demo belohnt weitreichenden Zugriff, weil der Agent mehr Informationen finden und mehr Schritte abschließen kann. Eingeschränkter Zugriff führt zu mehr Ablehnungen, Einrichtungsaufwand und scheinbarer Reibung.
In der Produktion kehrt sich diese Rechnung um. Jedes angebundene System führt eine weitere Vertrauensbeziehung ein. Jede zusätzliche Berechtigung erhöht die potenzielle Auswirkung. Jeder automatisierte Schritt verkürzt die Zeit, in der ein Verteidiger ungewöhnliches Verhalten erkennen kann.
Auch die organisatorische Zuständigkeit schafft ein weiteres Problem. Produktteams wählen Modelle und Connectoren. Identity-Teams verwalten Zugangsdaten. Sicherheitsteams überwachen Ereignisse. Rechtsteams definieren Datenbeschränkungen. Geschäftsbereiche entscheiden, welche Workflows relevant sind.
Ein Agent kann während einer Aufgabe all diese Bereiche durchqueren. Wenn kein Team die gesamte Ausführungskette verantwortet, kann jede Gruppe annehmen, dass eine andere Kontrolle den Fehler aufhält.
Zusicherungen von Anbietern können die Lücke vertiefen. Enterprise-Verträge behandeln möglicherweise Datenaufbewahrung, Modelltraining und Verschlüsselung. Diese Schutzmaßnahmen sind wichtig, beheben jedoch weder zu weitreichende Kundenberechtigungen noch unsicheres Workflow-Design.
Ein Anbieter kann gespeicherte Prompts schützen, während der Kunde interne Datensätze über Retrieval offenlegt. Er kann die Modellinfrastruktur isolieren, während ein Unternehmen einem Agenten übermäßigen Cloud-Zugriff gewährt. Die Verantwortung bleibt über den gesamten Stack verteilt.
Auch Sicherheitsprodukte haben Schwierigkeiten, wenn AI-Aktivität legitimer Arbeit ähnelt. Ein autorisierter Mitarbeiter könnte einen zugelassenen Assistenten bitten, einen Vertrag zusammenzufassen. Derselbe Workflow wird gefährlich, wenn der Vertrag eine verborgene Anweisung enthält, die den Agenten umleitet.
Herkömmliches Monitoring sieht einen authentifizierten Nutzer, eine zugelassene Anwendung und eine erlaubte Datenanfrage. Das fehlende Signal ist die Beziehung zwischen nicht vertrauenswürdigem Kontext und der darauf folgenden Aktion.
Unternehmen benötigen umfangreichere Spuren für diese Beziehung. Nützliche Protokolle erfassen abgerufene Quellen, Modellentscheidungen, Tool-Aufrufe, Richtlinienergebnisse, Freigaben und daraus resultierende Zustandsänderungen. Sensible Inhalte können geschützt werden, während genug Belege für Untersuchungen erhalten bleiben.
Das Ziel ist nicht unbegrenzte Überwachung von Mitarbeitern. Es ist nachvollziehbare Automatisierung. Menschen sollten verstehen, wann ein AI-System auf Unternehmensdaten zugreift und welche Aktionen es in ihrem Namen ausführt.
Shadow AI erschwert diese Arbeit. Shadow AI bezeichnet die Nutzung nicht genehmigter Modelle, Agenten oder Connectoren durch Mitarbeiter außerhalb der normalen Governance. Das Blockieren jedes öffentlichen Tools kann Aktivitäten in persönliche Konten und nicht verwaltete Geräte drängen.
Eine bessere Antwort kombiniert genehmigte Alternativen mit durchsetzbaren Kontrollen auf Identitäts-, Browser-, Endpoint- und Datenebene. Mitarbeiter benötigen einen praktikablen Weg für legitime Arbeit. Sicherheitsteams benötigen Transparenz darüber, wohin geschützte Informationen gelangen.
Unternehmen sollten außerdem Experimente von der Produktion trennen. Eine Sandbox kann synthetische Daten, wegwerfbare Zugangsdaten, isolierte Netzwerke und begrenzte Tools bereitstellen. Erfolgreiche Experimente können dann eine explizite Bedrohungsmodellierung durchlaufen, bevor sie echten Zugriff erhalten.
Dieser Prozess erfordert mehr als eine Compliance-Checkliste. Jeder Workflow benötigt einen Missbrauchsfall. Prüfer sollten fragen, was passiert, wenn abgerufene Inhalte täuschen, ein Modell das falsche Tool auswählt oder ein Nutzer eine irreführende Anfrage freigibt.
Anschließend sollten sie die Wiederherstellung testen. Kann das Unternehmen die Agentenidentität sofort widerrufen? Kann es geänderte Datensätze identifizieren? Kann es Aktionen rückgängig machen, ohne demselben Modell zu vertrauen, das sie verursacht hat?
Das stärkste Gegenargument lautet, dass diese Kontrollen die Einführung verlangsamen werden. Das trifft auf einige Bereitstellungen zu. Nicht gelöste Berechtigungs- und Freigabemängel verursachen jedoch später Verzögerungen durch Incident Response, Notfallbeschränkungen und verlorenes Vertrauen.
Eine weitere Unsicherheit betrifft die Modelle selbst. Anbieter verbessern fortlaufend die Verarbeitung von Anweisungen und die Angriffserkennung. Diese Verbesserungen können erfolgreiche Manipulationen reduzieren, rechtfertigen jedoch nicht die Entfernung deterministischer Grenzen.
Enterprise-Sicherheit sollte sich mit den Modellen verbessern, aber nicht von diesen Veränderungen abhängen. Eine gut konzipierte Anwendung wird mit einem besseren Modell sicherer und bleibt begrenzt, wenn dieses Modell versagt.
Worauf Sicherheitsverantwortliche als Nächstes achten sollten
Die nächste Phase wird anhand von Berechtigungsdesign, unabhängigen Tests und Transparenz bei Vorfällen gemessen werden – nicht anhand von Modellverweigerungswerten.
Das erste Signal ist, ob Anbieter aussagekräftige Postmortems zu Sicherheitsvorfällen mit Agenten veröffentlichen. Nützliche Offenlegungen beschreiben die ursprüngliche Eingabe, verfügbare Tools, Zugangsdaten, das Versagen der Eindämmung und die endgültige Auswirkung. Vage Verweise auf „unerwartetes Verhalten“ bieten kaum Orientierung.
Postmortems sollten auch klarstellen, was sich nach dem Vorfall geändert hat. Ein neuer Prompt ist ein schwächerer Beleg als eine entzogene Berechtigung oder ein neu gestaltetes Autorisierungs-Gate. Sicherheitsverantwortliche sollten zwischen verhaltensbezogener Anpassung und architektonischer Behebung unterscheiden.
Das zweite Signal ist die Einführung agentenspezifischer Identitätskontrollen. Unternehmen benötigen getrennte Maschinenidentitäten, kurzlebige Zugangsdaten, ressourcenspezifische Berechtigungsbereiche und einen Notfallentzug. Produkte, die lediglich den Nutzer imitieren, lassen wichtige Fragen unbeantwortet.
Käufer sollten fragen, ob ein Agent während einer Aufgabe auf nicht zusammenhängende Anwendungen zugreifen kann. Sie sollten Nachweise verlangen, dass Richtlinien jedem Tool-Aufruf folgen. Außerdem sollten sie überprüfen, ob Protokolle Aktionen mit dem ursprünglichen Nutzer und der jeweiligen Sitzung verknüpfen.
Das dritte Signal sind wiederholbare Sicherheits-Regressionstests. KI-Regressionstests prüfen, ob bekannte Angriffe nach Änderungen an Modellen, Prompts, Tools, Retrieval oder Berechtigungen erneut auftreten. Sie sollten vor der Bereitstellung und nach jeder wesentlichen Aktualisierung ausgeführt werden.
Diese Tests benötigen realistische feindliche Inhalte. Teams sollten Angriffe in E-Mails, Webseiten, Dokumenten, Repositories und Tool-Antworten platzieren. Direkte Nutzer-Prompts decken nur einen Teil der Eingabeoberfläche einer Anwendung ab.
Unabhängige Forschung bleibt unverzichtbar. Bewertungen von Anbietern betonen häufig den Normalbetrieb und bekannte Angriffe. Externe Forschende betrachten Vertrauensgrenzen anders, wie EchoLeak und GhostApproval zeigen.
Beschaffungsteams können diese Arbeit unterstützen, indem sie nach Offenlegungsprogrammen, Reaktionszeiten und veröffentlichten Maßnahmen zur Behebung fragen. Die Reaktion eines Produkts auf Forschungsergebnisse verrät ebenso viel wie sein Sicherheitsmarketing.
Google News wird weiterhin alarmierende KI-Vorfälle hervorheben, weil Agenten immer sensiblere Systeme erreichen. Die sinnvolle Reaktion ist weder Panik noch ein pauschales Verbot. Sie besteht darin, die Definition einer sicheren Bereitstellung in Unternehmen zu verändern.
Behandeln Sie das Modell als nicht vertrauenswürdig. Geben Sie dem Agenten weniger Zugriff als der Person, die ihn steuert. Sorgen Sie dafür, dass Freigabebildschirme unabhängig verifizierte Fakten anzeigen, bevor etwas geändert wird.
Sicherheitsverantwortliche sollten jetzt einen vernetzten KI-Workflow auswählen und ihn von der Eingabe bis zur endgültigen Aktion nachverfolgen. Welche Kontrolle funktioniert noch, wenn das Modell einer feindlichen Anweisung folgt? Die Antwort zeigt, ob das Unternehmen über eine KI-Sicherheitsarchitektur verfügt oder nur über ein KI-Sicherheitsversprechen.
