Die versteckte Bedrohung von KI-Agenten erfordert ein neues Sicherheitsmodell

Agentic-KI-Systeme haben sich im vergangenen Jahr weit verbreitet. Sie werden nun für verschiedene Funktionen eingesetzt, darunter die Authentifizierung von Benutzern, die Übertragung von Kapital, die Auslösung von Compliance-Workflows und die Koordination über Unternehmensumgebungen hinweg mit minimaler menschlicher Überwachung.

Ein stiller Problem entsteht jedoch mit der zunehmenden Autonomie, nicht auf der Ebene von Prompts oder Richtlinien, sondern auf der Ebene der Infrastrukturvertrauens. Agentic-Systeme werden mit Insider-Befugnissen ausgestattet, während sie immer noch auf Rechenumgebungen laufen, die nie dafür ausgelegt waren, autonome Entscheidungsträger vor der Infrastruktur unter ihnen zu schützen.

Traditionelle Sicherheit geht davon aus, dass Software passiv ist, aber agentic-Systeme sind es nicht. Sie argumentieren, erinnern und handeln kontinuierlich, autonom und mit delegierter Autorität.

Nicht zu vergessen, dass KI-Agenten wahrscheinlich Zugang zu personenbezogenen Daten haben, basierend auf ihrem Anwendungsfall, wie z. B. E-Mails und Anrufprotokollen, unter anderem.

Zusätzlich existieren, während Hardware-basierte Schutzmechanismen wie vertrauliche virtuelle Maschinen und sichere Enklaven vorhanden sind, sie noch nicht die Standardgrundlage für die meisten agentic-KI-Einsätze. Als Ergebnis führen viele Agenten immer noch in Umgebungen aus, in denen sensible Daten während der Laufzeit der Infrastruktur ausgesetzt sind.

Agenten sind Insider, keine Werkzeuge

Sicherheitsteams wissen bereits, wie herausfordernd es ist, Insider-Bedrohungen zu bekämpfen, ein Problem, das im Verizon-Data-Breach-Bericht 2025 hervorgehoben wird, der zeigt, dass Systemeinbrüche für mehr als 53 % der bestätigten Datenlecks im vergangenen Jahr verantwortlich waren. In 22 % dieser Fälle nutzten Angreifer gestohlene Anmeldeinformationen, um Zugang zu erlangen, was zeigt, wie oft sie durch die Nutzung legitimer Identitäten anstelle der Ausnutzung technischer Schwachstellen erfolgreich sind.

Betrachten Sie nun einen Agenten, der aus Prompt-Logik, Tools und Plugins, Anmeldeinformationen sowie Richtlinien besteht. Er kann nicht nur Code ausführen und im Internet surfen, sondern auch CRM-Systeme abfragen, E-Mails lesen und Tickets pushen, unter anderem. Die Kombination von Funktionen hat traditionelle Angriffsflächen in eine moderne Schnittstelle gebracht.

Die Gefahr, die durch solche Insider-Bedrohungen entsteht, ist nicht spekulativ. Das Open Web Application Security Project (OWASP) listet nun “Prompt-Injection” als kritische Schwachstelle für LLM-Anwendungen auf und betont ihre besondere Gefahr für agentic-Systeme, die Aktionen ketten. Microsofts Threat Intelligence-Team hat auch Berichte veröffentlicht, die vor warnen, dass KI-Systeme mit Tool-Zugriff subvertiert werden können, um Datendiebstahl auszuführen, wenn Sicherheitsvorkehrungen nicht architektonisch durchgesetzt werden.

Diese Berichte sind eine zeitgemäße Erinnerung daran, dass Agenten, die legitimen Zugang zu Systemen und Daten haben, gegen ihre Besitzer gewendet werden können. Die Risikolandschaft für agentic-Systeme ist jedoch nicht einheitlich. Anwendungs-schicht-Schwachstellen wie Prompt-Injection und Tool-Missbrauch stammen aus der Unfähigkeit des Modells, vertrauenswürdige Anweisungen von unvertrauenswürdigen Benutzereingaben zu unterscheiden, eine Design-Einschränkung, die durch keine Menge an Speicher-Härte behoben werden kann.

Ein anderes und ebenso wichtiges Problem besteht auf der Infrastrukturebene: Einige Agenten laufen in Klartext-Speicher, was bedeutet, dass sensible Informationen wie Chat-Verläufe, API-Antworten und Dokumente während der Verarbeitung sichtbar sind und möglicherweise später weiterhin zugänglich bleiben. OWASP identifiziert dieses Risiko als Sensitive Information Disclosure (LLM02) und System Prompt Leakage (LLM07) und schlägt vor, Kontext-Isolation, Namensraum-Segmentierung und Speicher-Sandboxing als wichtige Sicherheitsmaßnahmen zu verwenden.

Daher sollten Benutzer diese Agenten nicht als einfache Anwendungen behandeln, da sie dynamisch, argumentierend und ausführend sind und ein Sicherheitsmodell erfordern, das ihre einzigartige Natur als nicht-menschliche Entitäten mit Agency berücksichtigt. Dieser Ansatz muss sowohl Software-Steuerungen umfassen, um zu begrenzen, wie das Modell handelt, als auch Hardware-Schutzmaßnahmen, um Daten sicher zu halten, während sie verwendet werden.

Die Architektur des Vertrauens hat einen kritischen Fehler

Aktuelle Sicherheitspraktiken konzentrieren sich auf den Schutz von Daten in Ruhe und während der Übertragung. Die letzte Grenze, Daten in Verwendung, bleibt fast vollständig ungeschützt. Wenn ein KI-Agent über eine vertrauliche Datenmenge nachdenkt, um einen Kredit zu genehmigen, Patientenakten zu analysieren oder einen Handel auszuführen, werden diese Daten normalerweise entschlüsselt und in Klartext innerhalb des Serverspeichers verarbeitet.

In Standard-Cloud-Modellen kann jeder, der ausreichende Kontrolle über die Infrastruktur hat, einschließlich Hypervisor-Administratoren oder Co-Tenant-Angreifern, potenziell in das hineinschauen, was während der Ausführung einer Arbeitslast passiert. Für KI-Agenten ist diese Exposition besonders gefährlich, da sie Zugang zu sensiblen Informationen benötigen, um ihre Aufgaben zu erfüllen, was potenziell zu einer Angriffsfläche werden kann.

Wie Lumia Security demonstriert hat, können Angreifer mit Zugang zu einem lokalen Computer JWTs und Sitzungsschlüssel direkt aus dem Prozessspeicher von ChatGPT-, Claude- und Copilot-Desktop-Anwendungen erhalten. Diese gestohlenen Anmeldeinformationen können es ihnen ermöglichen, sich als ein anderer Benutzer auszugeben, die Konversationsgeschichte zu stehlen und Prompts in laufende Sitzungen einzufügen, die das Verhalten des Agenten ändern oder falsche Erinnerungen pflanzen können.

Ein Beispiel dafür ist der Vorfall von AWS CodeBuild, bei dem Angreifer heimlich schädlichen Code zu einem Projekt hinzufügten und, als das System ihn ausführte, in den Computerspeicher schauten und versteckte Anmeldeinformationen stahlen, die dort gespeichert waren. Mit diesen Token konnten die Angreifer den Code des Projekts ändern und möglicherweise auf andere Systeme zugreifen.

Für Finanzinstitute ist die stille Manipulation existenziell. Banken, Versicherungen und Investmentfirmen absorbieren bereits durchschnittliche Kosten für Datenlecks von über 10 Millionen US-Dollar, und sie verstehen, dass Integrität ebenso wichtig ist wie Vertraulichkeit. Laut einem aktuellen Informatica-Bericht wird das “Vertrauensparadox” wie folgt erklärt: Organisationen setzen autonome Agenten schneller ein, als sie ihre Ausgaben überprüfen können. Das Ergebnis ist eine Automatisierung, die Fehler oder Vorurteile direkt in die Kernprozesse einbauen kann, die mit Maschinengeschwindigkeit arbeiten.

Vertrauliches Rechnen und der Fall für Isolation

Inkrementelle Reparaturen werden das vorliegende Problem nicht lösen, obwohl strengere Zugriffskontrollen und bessere Überwachung helfen können. Dennoch kann keine davon das zugrunde liegende Problem ändern. Das Problem ist architektonisch, und solange die Berechnung in einem offenen Speicher erfolgt, sind Agenten anfällig, wenn es am wichtigsten ist, nämlich bei der Argumentation.

Vertrauliches Rechnen, definiert durch den Confidential Computing Consortium (CCC) als der Schutz von Daten in Verwendung durch hardware-basierte Trusted Execution Environments (TEEs), geht direkt auf den Kernfehler ein.

Für KI-Agenten ist diese hardware-basierte Isolation transformierend, da sie es ermöglicht, die Identitätsnachweise des Agenten, seine Modellgewichte, proprietäre Prompts und die sensiblen Benutzerdaten, die er verarbeitet, während der Ausführung verschlüsselt zu halten, nicht nur auf einer Festplatte oder über ein Netzwerk, sondern aktiv im Speicher. Die Trennung bricht die traditionelle Modellierung, bei der die Kontrolle über die Infrastruktur die Kontrolle über die Arbeitslast garantiert, endgültig.

Fern-Attestierung bietet verifizierbare kryptografische Beweise, dass eine bestimmte Inferenzanfrage innerhalb einer hardware-basierten Trusted Execution Environment, sei es ein CPU oder GPU, ausgeführt wurde. Der Beweis wird aus Hardware-Messungen generiert und zusammen mit der Antwort geliefert, wodurch eine unabhängige Überprüfung möglich ist, wo und wie die Arbeitslast ausgeführt wurde.

Attestationsaufzeichnungen enthüllen nicht den ausgeführten Code. Stattdessen wird jeder Arbeitslast eine eindeutige Arbeitslast-ID oder Transaktions-ID zugeordnet, und die TEE-Attestationsaufzeichnung ist mit dieser ID verknüpft. Die Attestierung bestätigt, dass die Berechnung innerhalb einer vertrauenswürdigen Umgebung ausgeführt wurde, ohne deren Inhalt preiszugeben.

Die Einrichtung schafft eine neue Grundlage für Compliance und Prüfbarkeit, die es ermöglicht, die Aktionen eines Agenten mit einer bestimmten Codeversion zu verknüpfen, die attestiert und einer bekannten Menge an Eingabedaten zugeordnet wurde.

Auf dem Weg zu verantwortlicher Autonomie

Die Auswirkungen des oben beschriebenen Systems gehen über die grundlegende Sicherheit hinaus. Betrachten Sie die Gesetze, die Finanzen, Gesundheitswesen und personenbezogene Informationen regeln. Viele Rechtsordnungen wenden Daten-Souveränitätsregeln an, die einschränken, wo Informationen verarbeitet werden dürfen. In China erfordern das Personal Information Protection Law und das Data Security Law, dass bestimmte Kategorien von Daten, wie wichtige personenbezogene Daten, innerhalb des Landes gespeichert und vor der Übertragung ins Ausland überprüft werden.

Ähnlich haben mehrere Golfstaaten, wie die Vereinigten Arabischen Emirate und Saudi-Arabien, ähnliche Ansätze verfolgt, insbesondere für Finanz-, Regierungs- und kritische Infrastruktur-Daten.

Vertrauliches Rechnen kann Sicherheit und Prüfbarkeit stärken, indem es Daten schützt, während sie verarbeitet werden, und die Laufzeitumgebung attestiert. Es ändert jedoch nicht, wo die Verarbeitung stattfindet. Wo Daten-Souveränitätsregeln lokale Verarbeitung erfordern oder Bedingungen für grenzüberschreitende Übertragungen auferlegen, können vertrauenswürdige Ausführungsumgebungen Compliance-Steuerungen unterstützen, nicht ersetzen.

Darüber hinaus ermöglicht vertrauliches Rechnen sichere Zusammenarbeit in Multi-Agenten-Systemen, in denen Agenten aus verschiedenen Organisationen oder innerhalb verschiedener Abteilungen oft Informationen teilen oder Ausgaben überprüfen müssen, ohne vertrauliche Daten preiszugeben.

Und wenn die Technologie mit einer Zero-Trust-Architektur kombiniert wird, ist das Ergebnis eine viel stärkere Grundlage. Zero Trust validiert kontinuierlich Identität und Zugriff, während vertrauliches Rechnen den Speicher des Hardware-Geräts vor nicht autorisierter Extraktion schützt und verhindert, dass sensible Informationen in Klartext wiederhergestellt werden.

Zusammen verteidigen sie, was tatsächlich wichtig ist, beispielsweise Entscheidungslogik, sensible Eingaben und die kryptografischen Schlüssel, die die Autorisierung von Aktionen ermöglichen.

Neuer Basisschutz für autonome Systeme

Wenn jede Interaktion Menschen dem Risiko der Exposition aussetzt, werden sie KI nicht mit Dingen wie Gesundheitsakten oder Finanzentscheidungen betrauen. Ähnlich werden Unternehmen ihre wichtigsten Aufgaben nicht automatisieren, wenn dies zu regulatorischen Problemen oder dem Verlust wichtiger Daten führen kann.

Serious Builder erkennen an, dass Anwendungs-schicht-Fixes allein in High-Assurance-Umgebungen unzureichend sind.

Wenn Agenten mit finanzieller Autorität, regulierten Daten oder cross-organisationaler Koordination betraut werden, wird die Infrastruktur-Exposition zu mehr als einer theoretischen Sorge. Und ohne vertrauliche Ausführung in solchen Kontexten bleiben viele Agenten ein weiches Ziel, mit gestohlenen Schlüsseln und veränderbarer Logik. Die Größe moderner Datenlecks zeigt genau, wohin dieser Weg führt.

Privatsphäre und Integrität sind keine optionalen Funktionen, die nach der Bereitstellung hinzugefügt werden können. Sie müssen von der Silizium-Ebene aus architektonisch gestaltet werden. Daher muss für die sichere Skalierung von KI-Agenten hardware-gestützte Vertraulichkeit nicht nur als Wettbewerbsvorteil, sondern als Basis angesehen werden.