Die versteckte Bedrohung durch KI-Agenten erfordert ein neues Sicherheitsmodell

Agente KI-Systeme haben sich im Laufe des letzten Jahres 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 in Unternehmensumgebungen mit minimaler menschlicher Überwachung.

Allerdings entsteht ein ruhigeres Problem mit der zunehmenden Autonomie, nicht auf der Ebene von Prompts oder Richtlinien, sondern auf der Ebene des Infrastrukturvertrauens. Agente Systeme werden mit Insider-Befugnissen ausgestattet, während sie immer noch in Rechenumgebungen ausgeführt werden, 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 agente Systeme sind es nicht. Sie argumentieren, erinnern und handeln kontinuierlich, autonom und mit delegierter Autorität.

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

Darüber hinaus existieren zwar hardwarebasierte Schutzmechanismen wie vertrauliche virtuelle Maschinen und sichere Enklaven, aber sie sind noch nicht die Standardbasis für die meisten agenbasierten KI-Implementierungen. Als Ergebnis werden viele Agenten immer noch in Umgebungen ausgeführt, 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-Bericht von 2025 hervorgehoben wird, der zeigt, dass Systemeinbrüche für mehr als 53 % der bestätigten Sicherheitsverletzungen im letzten Jahr verantwortlich waren. In 22 % dieser Fälle nutzten Angreifer gestohlene Anmeldeinformationen, um Zugang zu erhalten, was zeigt, wie oft sie durch die Nutzung legitimer Identitäten anstelle der Ausnutzung technischer Schwachstellen erfolgreich sind.

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

Die Gefahr, die von solchen Insider-Bedrohungen ausgeht, ist nicht spekulativ. Das Open Web Application Security Project (OWASP) listet Prompt-Injection als kritische Schwachstelle für LLM-Anwendungen auf und betont ihre besondere Gefahr für agente Systeme, die Aktionen ketten. Das Microsoft Threat Intelligence-Team hat auch Hinweise veröffentlicht, die warnen, dass KI-Systeme mit Tool-Zugriff abgefangen werden können, um Datendiebstahl zu begehen, wenn Sicherheitsvorkehrungen nicht architektonisch durchgesetzt werden.

Diese Berichte erinnern uns daran, dass Agenten, die legitimen Zugang zu Systemen und Daten haben, gegen ihre Besitzer eingesetzt werden können. Die Risikolandschaft für agente Systeme ist jedoch nicht einheitlich. Anwendungs-schichtbedrohungen wie Prompt-Injection und Tool-Missbrauch ergeben sich aus der Unfähigkeit des Modells, vertrauenswürdige Anweisungen von unvertrauenswürdigen Benutzereingaben zu unterscheiden, einer Design-Einschränkung, die durch keine Menge an Memory-Hardening 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 sein können 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, Namespace-Segmentierung und Memory-Sandboxing als wichtige Sicherheitsmaßnahmen zu verwenden.

Daher sollten Benutzer diese Agenten nicht als einfache Anwendungen behandeln, da sie dynamische, argumentierende Ausführende erfordern, die ein Sicherheitsmodell benötigen, das ihre einzigartige Natur als nicht-menschliche Entitäten mit Agency berücksichtigt. Dieser Ansatz muss sowohl Software-Steuerungen zur Begrenzung der Modellhandlungen als auch Hardware-Schutzmaßnahmen zur Sicherstellung der Datensicherheit während der Verwendung umfassen.

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 in der Regel entschlüsselt und im 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 möglicherweise zu einer Angriffsoberfläche werden kann.

Wie Lumia Security gezeigt 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 Konversationshistorie zu stehlen und Prompts in laufende Sitzungen einzugeben, die das Verhalten des Agenten ändern oder falsche Erinnerungen pflanzen können.

Ein Beispiel dafür ist der Vorfall von AWS CodeBuild im Juli 2025. Die Angreifer fügten heimlich schädlichen Code zu einem Projekt hinzu, und als das System ihn ausführte, sah der Code in den Computerspeicher und stahl versteckte Anmelde-Tokens, die dort gespeichert waren. Mit diesen Tokens 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 von über 10 Millionen Dollar pro Sicherheitsverletzung und verstehen, dass Integrität ebenso wichtig ist wie Vertraulichkeit. Laut einem aktuellen Bericht von Informatica wurde 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 Voreingenommenheit direkt in die Kernprozesse einbauen kann, die mit Maschinengeschwindigkeit arbeiten.

Vertrauliches Rechnen und der Fall für Isolation

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

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

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

Remote-Attestierung bietet verifizierbare kryptographische Beweise, dass eine bestimmte Inferenzanfrage innerhalb einer hardwarebasierten Trusted Execution Environment (TEE) ausgeführt wurde, sei es auf einem CPU oder GPU. Der Beweis wird aus Hardware-Messungen generiert und zusammen mit der Antwort geliefert, was eine unabhängige Überprüfung ermöglicht, wo und wie die Arbeitslast ausgeführt wurde.

Attestierungsprotokolle geben nicht preis, welcher Code ausgeführt wurde. Stattdessen wird jede Arbeitslast mit einer eindeutigen Arbeitslast-ID oder Transaktions-ID verknüpft, und das TEE-Attestierungsprotokoll 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 Handlungen eines Agenten mit einer bestimmten Codeversion zu verknüpfen, die attestiert und einer bekannten Menge an Eingabedaten zugeordnet wurde.

Auf dem Weg zur rechenschaftspflichtigen 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 Gerichtsbarkeiten wenden Regeln der Datensouveränität an, die einschränken, wo Informationen verarbeitet werden dürfen. In China erfordern das Gesetz zum Schutz personenbezogener Informationen und das Gesetz über die Datensicherheit , dass bestimmte Kategorien von Daten, wie wichtige personenbezogene Daten, beispielsweise, innerhalb des Landes gespeichert und überprüft werden müssen, bevor sie ins Ausland übertragen werden.

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

Vertrauliches Rechnen kann Sicherheit und Prüfbarkeit stärken, indem es Daten während der Verarbeitung schützt und die Attestierung der Laufzeitumgebung ermöglicht. Es ändert jedoch nicht, wo die Verarbeitung stattfindet. Wo Regeln der Datensouveränität lokale Verarbeitung oder Bedingungen für grenzüberschreitende Übertragungen erfordern, können vertrauenswürdige Ausführungsumgebungen Compliance-Steuerungen unterstützen, nicht jedoch rechtliche Anforderungen 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 proprietäre Daten preiszugeben.

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

Zusammen verteidigen sie das, was wirklich zählt, zum Beispiel Entscheidungslogik, sensible Eingaben und die kryptographischen Schlüssel, die die Aktionen autorisieren.

Neue Grundlage für autonome Systeme

Wenn jede Interaktion Menschen der Gefahr der Exposition aussetzt, werden sie nicht zulassen, dass KI damit umgeht, wie z. B. Gesundheitsakten oder Finanzentscheidungen trifft. Ähnlich werden Unternehmen ihre wichtigsten Aufgaben nicht automatisieren, wenn dies zu regulatorischen Problemen oder zum Verlust wichtiger Daten führen könnte.

Ernsthafte Erbauer erkennen, dass Anwendungs-Schicht-Korrekturen allein in hochsicheren Umgebungen unzureichend sind.

Wenn Agenten mit finanzieller Autorität, regulierten Daten oder zwischenorganisationeller Koordination betraut werden, wird die Infrastruktur-Exposition zu mehr als einem theoretischen Anliegen. Und ohne vertrauliche Ausführung in solchen Kontexten bleiben viele Agenten ein weiches Ziel, mit entwendbaren Schlüsseln und veränderbarer Logik. Die Größe moderner Sicherheitsverletzungen 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 agenter KI hardware-gestützte Vertraulichkeit nicht nur als Wettbewerbsvorteil, sondern als Grundlage angesehen werden.