MCP- und Agenten-Sicherheit
KI-Agent-Sicherheit: der Überblick
KI-Agent-Sicherheit dreht sich um eine einzige Verschiebung: Ein Agent liest nicht nur, er handelt. Und zwar mit echten Rechten in echten Systemen. Sobald ein Sprachmodell Werkzeuge bekommt, um Dateien zu schreiben, Datenbanken abzufragen, APIs aufzurufen oder Code auszuführen, wird jede seiner Entscheidungen zu einer sicherheitsrelevanten Aktion. Dieser Überblick zeigt, welche Angriffsflächen dabei entstehen, welche Vertrauensgrenzen zählen und wo die MCP-Schicht besondere Vorsicht verlangt.
- Ein Agent handelt mit den Rechten seines Betreibers. Least Privilege pro Werkzeug ist die wichtigste Einzelmaßnahme.
- Das Modell trennt Anweisung und Daten nicht zuverlässig. Nicht vertrauenswürdige Inhalte sind Daten, nie ein Kontrollkanal.
- Destruktive und ausgehende Aktionen brauchen eine Bestätigung, damit eine eingeschleuste Anweisung nicht durchläuft.
- Werkzeuge und Datenzugänge gehören authentifiziert und minimal gescopt, mit sicheren Standardwerten.
- Wo Agenten über MCP mit der Welt verdrahtet sind, kommen eigene Vertrauensgrenzen hinzu, siehe die MCP-Tiefe unten.
Warum ein handelnder Agent eine neue Angriffsfläche ist
Ein klassisches Sprachmodell gibt Text zurück. Das Schlimmste, was passieren kann, ist eine falsche oder unerwünschte Antwort. Ein Agent dagegen setzt seine Antworten in Aktionen um. Er entscheidet, welches Werkzeug er mit welchen Argumenten aufruft, und dieses Werkzeug greift auf reale Ressourcen zu. Damit gelten für Agenten dieselben Fragen wie für jede privilegierte Software: Wer darf den Agenten steuern? Was darf jedes Werkzeug tun? Und welchen Eingaben vertraut der Agent, wenn er seine nächste Aktion wählt?
Die Besonderheit gegenüber gewöhnlicher Software: Das Modell zieht die Grenze zwischen einer echten Aufgabe und einem eingeschleusten Inhalt nicht zuverlässig. Klassischer Code trennt klar zwischen Programm und Daten. Ein Agent verarbeitet beides im selben Textstrom. Genau daraus entsteht die typische Verwundbarkeit von Agenten.
Die zentralen Vertrauensgrenzen
Zugang: wer den Agenten steuern darf
Jeder Einstiegspunkt, über den ein Agent oder seine Werkzeuge angesprochen werden, gehört authentifiziert. Viele nehmen an, ein lokal laufender Dienst sei allein dadurch schon sicher. Das ist falsch. Lokale Prozesse können solche Endpunkte erreichen, und über Umwege im Browser auch externe Webseiten. Wer den Zugang nicht kontrolliert, überlässt die Steuerung des Agenten und damit seine Rechte einem Unbefugten.
Eingaben: was der Agent für eine Anweisung hält
Ein Agent liest Inhalte aus vielen Quellen, und nicht alle sind vertrauenswürdig. Eine Webseite, ein Dokument oder eine Datenbankzeile kann eine versteckte Anweisung enthalten. Die tragende Regel lautet: Nicht vertrauenswürdige Inhalte sind Daten, nie ein Kontrollkanal. Wird diese Grenze verletzt, kann eingeschleuster Text die Werkzeuge des Agenten auslösen. Diese Klasse ist so zentral, dass wir ihr einen eigenen Leitfaden gewidmet haben, siehe Prompt-Injection und Tool-Poisoning.
Wirkung: was jedes Werkzeug tun darf
Least Privilege ist bei Agenten wichtiger als anderswo, denn das Modell ist fehlbar und lässt sich manipulieren. Jedes Werkzeug sollte genau so viel können, wie sein Anwendungsfall verlangt, und nicht mehr. Ein Universal-Werkzeug mit vollem Datei- oder Datenbankzugriff macht aus jedem kleinen Fehler eine große Eskalation. Destruktive und ausgehende Aktionen gehören zusätzlich hinter eine Bestätigung. Und Secrets sollten host-seitig gebrokert werden, damit sie nie beim ungeprüften Code liegen.
Wo MCP die Angriffsfläche verschiebt
Viele Agenten sind heute über das Model Context Protocol mit ihren Werkzeugen verbunden. MCP standardisiert diese Verbindung, und genau dadurch entsteht eine eigene Sicherheitsschicht mit eigenen Vertrauensgrenzen. Anders als bei einem einzelnen Agenten kommen hier drei verwundbare Parteien zusammen. Erstens der Server, der mit vollen Rechten handelt. Zweitens der Client, den ein bösartiger Server über Reverse-Channel-Verben treiben kann. Drittens die geteilten Bibliotheken darunter, deren einzelner Defekt auf alle abhängigen Server durchschlägt.
Wer Agenten produktiv betreibt, kommt an dieser Schicht nicht vorbei. Die Tiefe dazu haben wir in eigenen Leitfäden aufbereitet:
- Die OWASP MCP Top 10, praktisch erklärt, ein Überblick über die zehn Risikoklassen.
- Die OWASP Top 10 für Agentic Applications, die zehn Klassen für autonome Agenten (ASI01 bis ASI10).
- MCP-Server absichern, der praktische Leitfaden zu den konkreten Gegenmaßnahmen.
- MCP und OAuth, wie Sie den Vertrauensanker absichern.
Vom Prinzip zum Nachweis
Die Prinzipien der Agent-Sicherheit lassen sich in wenigen Sätzen fassen. Sie einzuhalten ist aber etwas anderes als zu belegen, dass die Kontrollen in einem konkreten System wirklich halten. Ein Teil der Risiken ist statisch erkennbar, als Code-Muster oder Konfiguration. Ein anderer Teil liegt im Design von Fähigkeiten und Vertrauensgrenzen und zeigt sich erst im Verhalten der Agent-Schleife. Belastbare Sicherheit braucht deshalb beide Ebenen und einen ausgeführten Nachweis pro Befund statt einer Vermutung. Was CyberSec42 dabei leistet, steht auf der Seite zu unseren Leistungen.
Wie belastbar ist Ihr Agent abgesichert?
In einem kostenlosen Erstgespräch ordnen wir die Angriffsfläche Ihres Agenten ein und benennen die eine Eigenschaft, von der Ihr Produkt abhängt, und ob sie belegbar ist. Jeder Befund kommt mit einem Proof of Concept, nicht mit einer Vermutung.
Erstgespräch anfragenCyberSec42 ist eine unabhängige technische Sicherheitsprüfung, keine akkreditierte Zertifizierungsstelle.
Häufige Fragen
Was ist KI-Agent-Sicherheit?
KI-Agent-Sicherheit befasst sich mit den Risiken, die entstehen, wenn ein Sprachmodell nicht nur Text erzeugt, sondern mit echten Rechten in echten Systemen handelt. Sie beantwortet drei Fragen: wer den Agenten steuern darf, welchen Eingaben er vertraut, und was jedes seiner Werkzeuge tun darf.
Warum ist ein Agent riskanter als ein normales Sprachmodell?
Ein reines Sprachmodell gibt Text zurück, ein Agent setzt seine Antworten in Aktionen um. Er ruft Werkzeuge auf, die auf reale Ressourcen zugreifen. Dazu trennt das Modell Anweisung und Daten nicht zuverlässig, weshalb eingeschleuste Inhalte seine Aktionen beeinflussen können.
Was ist die wichtigste Einzelmaßnahme?
Least Privilege pro Werkzeug. Jedes Werkzeug sollte genau so viel können, wie sein Anwendungsfall verlangt, und nicht mehr. Das begrenzt den Schaden, wenn das Modell fehlerhaft handelt oder manipuliert wird. Destruktive und ausgehende Aktionen gehören zusätzlich hinter eine Bestätigung.
Was hat MCP mit Agent-Sicherheit zu tun?
Das Model Context Protocol verbindet viele Agenten mit ihren Werkzeugen und bildet damit eine eigene Sicherheitsschicht. Dabei kommen drei verwundbare Parteien zusammen: der Server, der Client und die geteilten Bibliotheken. Die Tiefe dazu steht in unseren MCP-Leitfäden.
Kann ich Agent-Sicherheit mit einem Scanner abdecken?
Nur teilweise. Ein Teil der Risiken ist statisch als Code-Muster oder Konfiguration erkennbar, ein anderer liegt im Design von Fähigkeiten und Vertrauensgrenzen und zeigt sich erst im Verhalten der Agent-Schleife. Belastbar wird die Prüfung erst mit beiden Ebenen und einem ausgeführten Nachweis pro Befund.