KI-Assistenten beschränken sich längst nicht mehr darauf, Fragen im Browser zu beantworten. Unternehmen setzen zunehmend öffentliche und unternehmensinterne KI-Tools ein, um Dokumente zusammenzufassen, Verträge zu prüfen, Code zu generieren und interne Daten zu durchsuchen. Gleichzeitig können autonome Agenten Dateien öffnen, APIs aufrufen, sich mit Model-Context-Protocol-(MCP)-Servern verbinden und mit Benutzerberechtigungen handeln.
Diese Fähigkeiten ermöglichen nützliche Automatisierung, öffnen aber auch eine grosse Sicherheitslücke. Wenn Agenten im Kontext eines Benutzer-, Dienst- oder technischen Kontos arbeiten, können sie die dort verfügbaren Berechtigungen nutzen. Nachgelagerte Systeme protokollieren dabei unter Umständen dieselbe Identität wie bei einer direkt durch eine Person ausgelösten Aktion. Ohne agentenspezifischen Kontext ist deshalb häufig schwer erkennbar, ob eine Aktion von einer Person oder einem KI-Agenten ausging.
Daher ist es unerlässlich, dass KI Sicherheitsmechanismen eingesetzt werden, die:
- zwischen direkt ausgelösten Benutzeraktionen und Agentenaktivitäten unterscheiden können
- Visibilität über den Einsatz von KI-Agenten im gesamten Unternehmen schaffen
- Agentenaktivitäten detailliert überwachen und Agenten bei Sicherheits- oder Datenschutzverstössen blockieren können
Gleichzeitig dürfen diese Tools Sicherheitstelemetrie nicht zu einem Mass für die Leistung, Produktivität oder Arbeitszeit der Mitarbeitenden machen.
Was ist Sicherheit von KI-Agenten?
Die Sicherheit agentenbasierter KI umfasst die Überwachung und den Schutz von KI-Tools, -Assistenten und autonomen Agenten, die mit Unternehmensdaten, Applikationen und Infrastruktur interagieren.
Dazu gehören zwei verwandte Bereiche:
- Die Nutzung von KI-Diensten in Geschäftsprozessen, von freigegebenen Enterprise-Copilots bis zu öffentlichen browserbasierten Chatbots und anderen nicht verwalteten Diensten.
- Die Aktivitäten autonomer Agenten, beispielsweise wenn ein Coding- oder Operations-Agent Dateien liest, APIs aufruft, MCP-Server nutzt oder auf externe Ressourcen zugreift.
Diese Unterscheidung ist wichtig. Ein Unternehmen hat vielleicht keine intern entwickelten Agenten und ist dennoch durch die Nutzung externer KI-Dienste einem KI-bedingten Datenabfluss ausgesetzt. Ein weithin bekanntes Beispiel ist der Samsung-Vorfall aus dem Jahr 2023, bei dem Ingenieure proprietären Quellcode, Programmcode für Anlagenmessungen und Sitzungsnotizen offenlegten, indem sie diese zur Fehlerbehebung und Zusammenfassung in ChatGPT eingaben. Umgekehrt kann ein genehmigter interner Agent ein Risiko darstellen, wenn er übermässige Berechtigungen erbt oder beginnt, Tools und Ressourcen ausserhalb seines eigentlichen Zwecks zu nutzen. Eine aussagekräftige Sicherheitssicht muss beides abdecken.
Warum herkömmliche Kontrollen nur einen Teil des Bildes zeigen
Bestehende Sicherheitskontrollen spielen nach wie vor eine zentrale Rolle. Identitätssysteme legen fest, wer Zugriff hat, Endpoint-Sicherheitslösungen erfassen sicherheitsrelevante Aktivitäten auf Geräten, Netzwerkkontrollen prüfen die Kommunikation, und Applikations-Logs zeichnen einzelne Ereignisse auf.
Die Herausforderung beginnt, wenn eine KI-Interaktion diese Grenzen überschreitet.
Angenommen, ein Benutzer bittet einen genehmigten KI-Assistenten, einen vertraulichen Liefervertrag mit Informationen aus dem Web abzugleichen. Der Assistent liest das Dokument, ruft ein externes Suchtool auf und sendet einen Teil des Kontexts an einen Online-Dienst. Jede einzelne Aktion kann legitim erscheinen:
- Das initiierende Benutzerkonto ist berechtigt, den Vertrag zu öffnen.
- Der KI-Assistent ist genehmigt.
- Die externe Website ist nicht als bösartig bekannt.
- Die Verbindung nutzt regulären verschlüsselten Webverkehr.
Die Sicherheitsfrage betrifft die gesamte Abfolge. Waren vertrauliche Informationen in der Anfrage enthalten? Welcher Dienst hat sie erhalten? Hat der Assistent das erwartete Suchtool verwendet? War das ausgehende Volumen für dieses Benutzerkonto oder dieses Modell ungewöhnlich?
Diese Fragen sind schwer zu beantworten, wenn Prompts, Identitäten, Dateien, Tool-Aufrufe und Netzwerkziele in getrennten Systemen verbleiben.
Prompt-Injection macht vertrauenswürdige Agenten zu Malware
Ein wesentliches Risiko ist Prompt-Injection. Das OWASP GenAI Security Project definiert Prompt-Injection als Eingabe, die das Verhalten eines Modells auf unbeabsichtigte Weise verändert. Die Eingabe kann direkt von einem Benutzer stammen oder indirekt von einer Website, einem Dokument, einer E-Mail oder einer anderen externen Quelle.
Eine indirekte Prompt-Injection kann überraschend einfach sein. Ein KI-Assistent soll eine Webseite zusammenfassen. Versteckte Inhalte auf dieser Seite weisen das Modell an, nach sensiblen Informationen zu suchen und diese in eine Anfrage an eine andere Ressource einzufügen. Die sichtbare Aufgabe wirkt wie eine routinemässige Zusammenfassung, während das Modell zusätzliche Anweisungen verarbeitet, die der Benutzer nie erteilen wollte.
Die schädlichen Folgen eines solchen Angriffs können stark variieren: Ein reiner Text-Assistent liefert womöglich lediglich eine falsche Antwort. Ein Desktop-KI-Agent, der mit E-Mail, Cloud-Speicher, Quellcode und Geschäftsapplikationen verbunden ist, könnte hingegen missbraucht werden, um Daten zu exfiltrieren, auf die der Benutzer Zugriff hat, oder sämtliche Daten zu löschen.
EchoLeak, erfasst als CVE-2025-32711, hat gezeigt, wie ein indirekter Prompt-Injection-Pfad in Microsoft 365 Copilot ein Risiko der Offenlegung von Informationen schaffen konnte. Der Vorfall zeigt, dass auch freigegebene KI-Tools durch manipulierte oder schädliche Anweisungen aus vertrauenswürdig wirkenden Geschäftsinhalten zu riskanten Handlungen verleitet werden können.
Kein Sicherheitsprodukt kann garantieren, jede Prompt-Injection-Technik zu erkennen. Erkennungsregeln und Verhaltensanalysen können jedoch ungewöhnliche Ressourcenzugriffe und relevante Abweichungen sichtbar machen, die eine Untersuchung rechtfertigen. Eine kontinuierliche Anomalieerkennung könnte zudem versuchte Datenexfiltration oder destruktive Anweisungen (zum Beispiel Anweisungen mit den Wörtern «delete» oder «drop») automatisch erkennen und blockieren.
Das Risiko entsteht auch bei gewöhnlicher KI-Nutzung
Nicht jeder Datenleck im Zusammenhang mit KI geht auf einen Angreifer zurück. Ein Mitarbeiter fügt möglicherweise Kundendaten in einen privaten Chatbot ein, weil dieser so schneller eine Antwort liefert. Ein Entwickler lädt möglicherweise eine Konfigurationsdatei mit Anmeldedaten hoch, während er um Hilfe bei der Fehlerbehebung bittet. Ein Beschaffungsspezialist sendet möglicherweise einen Vertrag an ein externes Modell, ohne zu bemerken, dass das Dokument vertrauliche Klauseln enthält.
Diese Handlungen beruhen oft auf nachvollziehbaren geschäftlichen Absichten. Dennoch sind sie schwer zu steuern, wenn das Unternehmen grundlegende Fragen nicht beantworten kann:
- Welche genehmigten und externen KI-Modelle und -Anbieter werden im Unternehmen eingesetzt?
- Betrifft die Aktivität genehmigte Unternehmensdienste oder nicht verwaltete externe Dienste?
- Welche Arten von Daten und Dateien verlassen das Unternehmen?
- Welche externen Websites, APIs und MCP-Server erhalten Informationen?
- Ist das Volumen oder das Ziel für die jeweilige Applikation, den Workflow oder die Geschäftsumgebung ungewöhnlich?
Das ist das Shadow-AI-Problem in der Praxis. Eine Bestandsaufnahme der freigegebenen Tools ist nützlich, zeigt aber nicht, welche Dienste tatsächlich genutzt werden oder welche Informationen durch diese Tools fliessen.
Autonome Agenten bringen Tools und Befugnisse ins Spiel
Agenten fügen eine weitere Dimension hinzu, weil sie Modellausgaben in Aktionen umsetzen können.
Ein Coding-Agent liest vielleicht ein Repository, installiert ein Paket, ruft eine Deployment-API auf und ändert eine Datenbank – alles im Rahmen einer einzigen Aufgabe. Auch wenn die zugewiesene Aufgabe eine routinemässige Schemaaktualisierung ist, könnten die verfügbaren Tools und Berechtigungen dem Agenten den Zugang zu Systemen ermöglichen, die nie Teil des Workflows sein sollten.
Eine veröffentlichte Schwachstelle in GitHub Copilot CLI veranschaulicht das Problem. Präparierte Shell-Ausdrücke konnten ausführbare Befehle in Operationen verstecken, welche die Sicherheitsprüfung des Produkts als reine Lesevorgänge einstufte. Manipulierte Repository-Inhalte, Antworten von MCP-Servern oder entsprechende Benutzeranweisungen konnten den Agenten dadurch veranlassen, Befehle ohne die vorgesehene Freigabe auszuführen. Die Schwachstelle wurde gepatcht, doch der Fall zeigt, warum Sicherheitsteams nicht nur verstehen müssen, womit ein Agent beauftragt wurde, sondern auch, welche Tools er aufgerufen und welche Aktionen er letztlich ausgeführt hat.
Das relevante Sicherheitssignal ist möglicherweise kein bekannter bösartiger Befehl. Es kann eine Abweichung von der etablierten Rolle des Agenten oder vom genehmigten Workflow sein:
- Der Agent ruft ein Tool auf, das normalerweise nicht Teil dieses Workflows ist.
- Er greift auf eine Produktionsumgebung statt auf die erwarteten Entwicklungsressourcen zu.
- Er überträgt ein ungewöhnlich grosses Datenvolumen an einen externen Dienst.
- Er verbindet sich mit einem MCP-Server, der neu oder im Unternehmen unüblich ist.
- Seine Aktionen weichen wesentlich von der zugewiesenen Aufgabe oder dem genehmigten Prozess ab.
Regeln können bekannte Risikomuster identifizieren, während die Verhaltensanalyse weniger vorhersehbare Abweichungen in Agenten-, Applikations- und KI-Workflow-Aktivitäten aufdecken kann. Zusammen helfen diese Signale Sicherheitsteams bei der Untersuchung, wenn die tatsächliche Reichweite eines Agenten über seine vorgesehene Aufgabe hinausgeht.
MCP-Server und APIs erweitern den Aktionsradius von Agenten
MCP-Server und REST-APIs ermöglichen es KI-Applikationen auf Tools, Datenquellen und externe Dienste zuzugreifen.
Ein MCP-Server oder eine REST-API kann Zugriff auf Quellcode, Support-Tickets, interne Dokumentation, Cloud-Dienste oder Datenbanken gewähren.
Sicherheitsteams müssen daher verstehen, welche Dienste angebunden sind, welche Applikationen und Workflows sie aufrufen, wie häufig sie aufgerufen werden und welche Daten zwischen ihnen fliessen. Wer jede Verbindung isoliert betrachtet, erkennt das gesamte Risiko unter Umständen nicht.
Von GitHub veröffentlichte Sicherheitsforschung zeigt, wie ein Angriff mehrere verbundene Tools überspannen kann. In einem Szenario beeinflussten manipulierte Anweisungen in einem GitHub-Issue einen IDE-Agenten, nachdem dieser den Inhalt über ein verbundenes Tool abgerufen hatte. Der Agent konnte daraufhin andere verfügbare Tools nutzen, um auf ein lokales GitHub-Token zuzugreifen und zu versuchen, es an einen externen Server zu senden. GitHub hat die Schwachstellen behoben und zusätzliche Schutzmassnahmen eingeführt, doch das Beispiel zeigt, wie nicht vertrauenswürdige Inhalte, die über einen Service in den Workflow gelangen, Aktionen über einen anderen Service beeinflussen können.
Die übergeordnete Lehre lautet nicht, dass jeder MCP-Server oder jede API grundsätzlich unsicher ist. Vielmehr umfasst die tatsächliche Betriebsumgebung eines Agenten die Tools, Zugangsdaten, Datenquellen und externen Ziele, die ihm zur Verfügung stehen. Wer nur die Modellinteraktion überwacht, sieht einen Grossteil dieser Kette nicht. Die Sicherheitsanalyse muss die ursprüngliche Anweisung mit den aufgerufenen Diensten, den abgerufenen Daten und den nachfolgenden Aktionen verknüpfen.
Exeon.AgentGuard für KI-Visibilität und Anomalieerkennung
Die Sicherheitsherausforderungen beim Einsatz von KI in Unternehmen lassen sich in sieben zentrale Bereiche gliedern. Mit Exeon.AgentGuard haben wir ein neues Security-Analytics-Produkt entwickelt, das Sicherheitsteams bei der Untersuchung folgender Fragen unterstützt:
| Bereich | Herausforderungen und Fragen |
| Modelle und Anbieter (Shadow AI) | Welche genehmigten und nicht genehmigten (Shadow-)KI-Dienste werden genutzt? |
| Konten und technischer Kontext | Welches Konto, welche Applikation oder welcher Agent hat die Interaktion ausgelöst, und über welche technische Umgebung? |
| Prompts und Antworten | Welcher Kontext und welche Anweisungen haben die Interaktion geprägt? |
| Which capabilities did the agent invoke? | Welche Funktionen hat der Agent aufgerufen? |
| Dateien und Daten | Auf welche internen Informationen hat der Agent oder KI-Workflow zugegriffen? |
| Externe Ressourcen | Welche externen Websites, APIs und Dienste wurden kontaktiert? Sind Daten an diese externen Ressourcen abgeflossen? |
| Verhalten | Weicht die Aktivität von den erwarteten Mustern für den Agenten, die Applikation oder den Workflow ab? Verdächtiges Verhalten blockieren. |
Exeon.AgentGuard verbindet Visibilität über KI-Interaktionen hinweg mit anpassbaren Erkennungsregeln und Verhaltensanalyse.
Die Lösung kann sich mit Web-Proxys oder KI-Gateways verbinden, um KI-Interaktionen in Echtzeit zu analysieren. Alternativ kann sie Log-Daten eines Proxy-Servers oder KI-Dienstes nutzen. Auf Basis der verfügbaren Datenquellen rekonstruiert Exeon.AgentGuard Interaktionen mit gängigen KI-Modellen und verknüpft sie mit den relevanten Tools, Ressourcen und Datenflüssen.
Lokale Verarbeitung, Anonymisierung und Deduplizierung tragen dazu bei, die für Erkennung und Untersuchung erforderlichen Informationen zu erhalten, ohne redundante Daten zu sammeln oder den Datensatz für die Sicherheitsanalyse an einen externen Analysedienst zu übertragen.
Im zweiten Teil dieser Blogserie untersuchen wir vier praktische Anwendungsfälle: potenziellen Datenabfluss durch KI-Nutzung, nicht verwaltete KI-Dienste, verbundene Tools sowie Agenten, die ihren vorgesehenen Handlungsbereich verlassen.
