Dieser Beitrag basiert auf Mackenzies Gespräch mit Abdel Sghiouar im Podcast „The Secure Disclosure“. Hören Sie sich die gesamte Folge an oder sehen Sie sich das Video unten an.
Wenn Sie einem Agenten uneingeschränkten Zugriff auf Ihren Cluster gewähren, kann er ein Problem schneller durch alle Schichten des Stacks zurückverfolgen als jeder Techniker im Bereitschaftsdienst. Doch genau diese Reichweite macht den Agenten zu einem lohnenden Ziel für Angreifer. Durch das Entziehen des Schreibzugriffs wird zwar verhindert, dass er den Cluster beschädigt, doch ein schreibgeschützter Agent kann weiterhin alle Geheimnisse auslesen, die der Cluster ihm preisgibt, und ein gekaperter Agent kann dazu gebracht werden, diese preiszugeben.
Abdel Sghiouar ist seit 13 Jahren bei Google tätig und arbeitet mittlerweile als Senior Cloud Developer Advocate mit den Schwerpunkten Kubernetes und Cloud-Native. Seiner Meinung nach erfasst der Begriff „Prompt Injection“ nicht das gesamte Ausmaß der Sicherheitslücke bei Agenten. Er bevorzugt den Begriff „Prompt Poisoning“. Mackenzie hat sich mit ihm zusammengesetzt, um über die Sicherheit von KI-Agenten in Kubernetes zu sprechen und darüber, was sich ändert, sobald ein Agent das Ruder übernimmt.
Abdels Antwort lautet: „Vertrauen ist gut, Kontrolle ist besser“, auch wenn er zugibt, dass der Aspekt des Vertrauens nach wie vor ein ungelöstes Problem darstellt.
Was kann ein KI-Agent in Ihrem Cluster erreichen?
Sobald ein Agent zum Einsatz kommt, stellt sich zunächst die Frage, ob er über die erforderlichen Berechtigungen verfügt. In Kubernetes läuft dies auf die rollenbasierte Zugriffskontrolle (RBAC) hinaus. Ein Operations-Agent verfügt in der Regel über weitreichende Lesezugriffsrechte, da er für seine Aufgaben Signale aus dem gesamten Cluster benötigt – und genau diese Zugriffsrechte sind es, auf die es einem Angreifer ankommt.
Abdel sieht zwei Möglichkeiten, wie ein Angreifer diesen Zugriff gegen Sie nutzen kann. Die erste besteht darin, die vom Agenten gelesenen Daten zu manipulieren. Anwendungsprotokolle gehören zu den Signalen, die ein Operations-Agent abruft. Ein Angreifer, der Text in diese Protokolle einschleusen kann, kann somit auch Text in die Eingabeaufforderung des Agenten einschleusen. „Die Anwendung würde die Daten empfangen, alles auf die Festplatte schreiben, und dann würde der Agent es lesen.“
Aus diesem Grund bevorzugt Abdel den Begriff „Prompt-Poisoning“. Der Begriff „Prompt-Injection“ weckt Assoziationen mit SQL-Injection, die sich durch parametrisierte Abfragen beheben lässt; ein großes Sprachmodell verfügt jedoch über keine vergleichbare Möglichkeit, Anweisungen und Eingaben voneinander zu trennen. Es verarbeitet die Systemprompt, die Anweisungen des Benutzers, den Gesprächsverlauf und alles, was es im selben Moment als Kontext herangezogen hat, sodass eine von einem Angreifer verfasste Log-Zeile das gleiche Gewicht haben kann wie eine Anweisung des Bedieners.
Das zweite Risiko besteht darin, was der Agent lesen kann, sobald er manipuliert wurde. Wenn seine Berechtigungen alles umfassen, was der Pod sehen kann, „kann er secrets lesen, er kann Umgebungsvariablen lesen“, und all das wird in dem Moment offengelegt, in dem der Agent einer falschen Anweisung folgt. Durch das „Poisoning“ verschafft sich der Angreifer Zugang zum Agenten, und ein zu weitreichender Lesezugriff entscheidet darüber, wie viel Beute er am Ende mitnimmt.
Warum ein Lesezugriff nicht ausreicht
Die meisten Teams, bei denen Abdel beobachtet hat, dass sie Kubernetes mit Agenten betreiben, starten diese im schreibgeschützten Modus. Das schützt den Cluster, da ein Agent, der nur lesen kann, kein Deployment löschen oder einen Knoten leeren kann. Und wie Mackenzie betonte, ist der Agent ohne Lesezugriff kaum von Nutzen. Noch wichtiger ist, dass ein schreibgeschützter Agent weiterhin die „ secrets “ ausliest und somit weiterhin alle schädlichen Einträge erfasst, die in die Protokolle gelangt sind.
Mackenzie wies auf dasselbe Muster außerhalb des Clusters hin. Aikido Security entdeckte eine Prompt-Injektion (oder ein „Prompt Poisoning“) im GitHub-Workflow, den Google zur triage von Issues in seinem Gemini-CLI-Repository nutzt. Dort konnte ein speziell gestaltetes Issue den Agenten dazu bringen, die Umgebungsvariablen preiszugeben, auf die er Zugriff hatte. Googles Korrektur verhinderte, dass der Agent diese Variablen weitergab, wodurch diese konkrete Sicherheitslücke geschlossen wurde – allerdings blieb die Anfälligkeit für ein „Prompt Poisoning“ an sich bestehen.
Abdel vertritt die Ansicht, dass die Sicherheitsmechanismen, auf die sich die Teams bereits verlassen, „nach wie vor für Agenten gelten“. Was sich ändert, ist, dass es nun eine Komponente gibt, deren Entscheidungen man nicht einfach für bare Münze nehmen kann. Ein Sprachmodell kann Halluzinationen erzeugen, daher „kann man nicht vollständig darauf vertrauen, dass die Schlussfolgerungen des Agenten korrekt sind“. Seine Lösung lautet: Vertrauen ist gut, Kontrolle ist besser – ein Mensch sollte im Regelkreis stehen und die Handlungen des Agenten überprüfen. Er räumt jedoch offen ein, dass dies „eines der größten Probleme für die Zukunft“ ist und etwas, das die Branche noch nicht gelöst hat.
Wo „ Aikido Security“ zum Einsatz kommt
Aikido KI-Penetrationstests kann KI-Fähigkeiten testen. Dabei werden manipulierte Eingaben über abgerufene Dokumente und Tool-Ausgaben eingespeist, um zu prüfen, ob diese die Anweisungen des Agenten außer Kraft setzen und ob ein manipulierter Agent dazu gebracht werden kann, Tools aufzurufen oder Systeme anzusteuern, die er nicht ansprechen sollte. Außerdem lässt sich so feststellen, ob Ihr Agent dazu überredet werden kann, für jemand anderen zu arbeiten.
Der Rest hängt davon ab, wie weit der Agent reichen kann, wenn er kompromittiert wurde. „Infrastructure as Code“-Prüfungen erkennen im Pull-Request zu weit gefasste ClusterRole- oder Cloud-Identitäts- und Zugriffsmanagement-Rollen, einschließlich solcher, die der Agent selbst vorschlägt, und das „secrets “-Scanning findet fest codierte Anmeldedaten, bevor diese in einer Umgebungsvariablen landen, die der Agent auslesen kann. Das „Container “-Image-Scanning deckt sowohl die Workloads ab, denen Ihr Agent vertraut, als auch das eigene Image des Agenten und kennzeichnet in beiden Fällen anfällige Pakete und Malware.
Sobald der Agent läuft, Aikido Cloud überprüft er die ihm zugewiesenen Berechtigungen, die nicht immer mit den im Pull-Request gewährten übereinstimmen. Er kennzeichnet Kubernetes-RBAC-Bindungen, die dem Agenten mehr Zugriffsmöglichkeiten einräumen, als für seine Aufgabe erforderlich sind, und bei der Sicherheitsüberprüfung wird erkannt, wenn die Workload-Identität des Agenten einer Cloud-Rolle mit Administratorrechten zugeordnet ist. Die Erreichbarkeits - und Angriffspfadanalyse verknüpft diese Erkenntnisse dann miteinander und zeigt auf, welche Schritte ein Agent nacheinander ausführen könnte, um von seinem Pod zu einem kritischen Ziel zu gelangen, wie beispielsweise einer Produktionsdatenbank oder den Anmeldedaten eines Cloud-Administrators.
{{cta}}
