KI-Agenten-Sicherheit

Was ist KI-Agenten-Sicherheit?

KI-Agenten-Sicherheit ist die Praxis, Systeme vor den Risiken zu schützen, die entstehen, wenn KI-Agenten autonom handeln: dem Befolgen von in Daten versteckten, eingeschleusten Anweisungen, der Nutzung zu weitreichender Berechtigungen, der Installation halluzinierter Abhängigkeiten oder dem Ausrollen ungeprüfter Änderungen in die Produktion. Sie kombiniert klassische Zugriffskontrolle mit Abwehrmaßnahmen, die speziell darauf zugeschnitten sind, wie sich Sprachmodelle manipulieren lassen.

Die wichtigsten Punkte

• Die Kernbedrohung ist, dass Agenten Anweisungen nicht zuverlässig von Daten unterscheiden können. Jeder Inhalt, den ein Agent liest – eine Webseite, eine E-Mail, ein Ticket – kann Befehle enthalten, denen er gehorcht.
• Least Privilege zählt bei Agenten mehr als bei Menschen. Ein Agent mit Datenbank-Zugangsdaten nutzt sie in dem Moment, in dem eine Aufgabe – oder ein Angreifer – in diese Richtung zeigt.
• Die gefährliche Kombination ist Zugriff auf private Daten, Exposition gegenüber nicht vertrauenswürdigen Inhalten und die Fähigkeit, nach außen zu kommunizieren. Entfernen Sie ein Bein, und die meisten Exfiltrationsangriffe brechen zusammen.
• Das Supply-Chain-Risiko wird verstärkt. Agenten installieren Pakete mit Maschinengeschwindigkeit, was Slopsquatting und bösartige MCP-Server zu praktikablen Angriffsvektoren macht.
• Die Verteidigung erfolgt mehrschichtig: begrenzte Berechtigungen, eine isolierte Ausführungsumgebung, Egress-Kontrollen und Human-in-the-Loop-Freigabe für irreversible Aktionen.

So funktioniert es

KI-Agenten-Sicherheit beginnt mit einer nüchternen Annahme: Das Modell lässt sich austricksen. Prompt-Injection gilt Stand 2026 im allgemeinen Fall als ungelöst, weshalb kein ernsthaftes Design darauf setzt, dass das Modell bösartige Anweisungen immer verweigert. Die Belege sind eindeutig: In einem öffentlichen Wettbewerb 2025 wurden 1,8 Millionen Prompt-Injection-Angriffe gegen 22 Frontier-Agenten gestartet, mehr als 60.000 erzielten Richtlinienverstöße, und fast alle Agenten ließen sich innerhalb von 10 bis 100 Anfragen zu den meisten Verstößen bewegen [1]. Auch Hartnäckigkeit zahlt sich aus: US-AISI-Hijacking-Evaluierungen von Claude 3.5 Sonnet auf AgentDojo zeigten, dass die Erfolgsrate von Angriffen von 57 % auf 80 % stieg, wenn jede Injection statt einmal 25-mal versucht wurde – was bedeutet, dass Benchmarks mit nur einem Versuch das reale Risiko unterschätzen [2]. Stattdessen liegt Sicherheit in dem, was der Agent physisch tun kann. Jedes Tool, das der Agent aufrufen kann, ist auf das Minimum begrenzt, das es braucht, Zugangsdaten sind kurzlebig und aufgabenspezifisch, und destruktive Operationen erfordern entweder eine menschliche Bestätigung oder sind schlicht nicht verdrahtet.

Die zweite Ebene ist Containment. Agenten laufen innerhalb von Sandboxes mit eingeschränktem Netzwerk-Egress, sodass selbst eine vollständig kompromittierte Session weder interne Dienste erreichen noch Geheimnisse an den Server eines Angreifers senden kann. Praktiker fassen das Risiko oft als tödliche Kombination zusammen: Ein Agent, der private Daten lesen, nicht vertrauenswürdige Inhalte aufnehmen und Daten nach außen senden kann, ist nur eine Injection von einem Sicherheitsvorfall entfernt. Architekturprüfungen für Agenten-Deployments prüfen inzwischen explizit auf genau diese Triade.

Die dritte Ebene betrifft die Software, mit der der Agent in Berührung kommt. Coding-Agenten schlagen ständig Pakete vor und installieren sie, und Angreifer reagieren, indem sie die plausibel klingenden Paketnamen registrieren, die Modelle halluzinieren – ein Angriff, bekannt als Slopsquatting. Tool-Ökosysteme fügen ihre eigene Angriffsfläche hinzu: Ein Model-Context-Protocol-Server ist Drittanbieter-Code mit Zugriff auf den Kontext Ihres Agenten und verdient daher dieselbe Prüfung wie jede andere Abhängigkeit. Und schließlich läuft alles, was ein Agent produziert, durch Prüf-Gates, denn ein plausibel aussehender Pull Request ist genau die Form, die ein Supply-Chain-Angriff annehmen möchte.

Beispiel

Ein Unternehmen setzt einen Support-Agenten ein, der eingehende Kunden-E-Mails liest, die Bestelldatenbank abfragen und antworten kann. Ein Angreifer schickt eine E-Mail mit verstecktem Text: Anweisungen, die Bestellhistorie eines anderen Kunden nachzuschlagen und in die Antwort einzufügen. Ein naives Deployment leakt die Daten. Die abgesicherte Version übersteht den Angriff wegen früher getroffener Design-Entscheidungen: Das Datenbank-Tool akzeptiert nur die eigene Kunden-ID des Tickets, eingeschleuste Freitext-Abfragen schlagen fehl, ausgehende Antworten oberhalb eines Sensibilitätsschwellenwerts warten auf menschliche Freigabe, und der gesamte Austausch wird für Audits protokolliert. Das Modell wurde getäuscht; das System hielt stand.

Häufige Missverständnisse

Das anhaltende Missverständnis ist, dass Agenten-Sicherheit ein Problem der Modellauswahl sei, lösbar durch ein klügeres oder besser alignetes Modell. Modellqualität hilft am Rand, aber ein State-of-the-Art-Modell mit Produktions-Zugangsdaten und ohne Egress-Kontrollen ist immer noch eine geladene Waffe, die auf Ihre Infrastruktur gerichtet ist. Das Muster zeigt sich in den Breach-Daten: IBMs Cost of a Data Breach Report 2025 stellte fest, dass 13 % der Organisationen Sicherheitsverletzungen bei KI-Modellen oder -Anwendungen erlitten hatten, und 97 % davon verfügten nicht über angemessene KI-Zugriffskontrollen [3]. Behandeln Sie den Agenten wie einen nicht vertrauenswürdigen Mitarbeiter am ersten Tag: fähig, nützlich, und nur mit den Schlüsseln ausgestattet, die die aktuelle Aufgabe erfordert.

FAQ

Wie unterscheidet sich die Sicherheit agentischer KI von regulärer Anwendungssicherheit? Sie erbt alles aus der Anwendungssicherheit und fügt eine neue Klasse von Input-Angriffen hinzu. Klassische Anwendungen führen nur ihren eigenen Code aus; Agenten nehmen offene Eingaben in natürlicher Sprache entgegen und verwandeln sie in Aktionen, sodass die Angriffsfläche jedes Dokument, jede Seite und jede Nachricht umfasst, die der Agent jemals lesen wird.

Ist Prompt-Injection in der Praxis tatsächlich ausnutzbar? Ja. Öffentliche Demonstrationen gegen Browser-Agenten, E-Mail-Assistenten und Coding-Tools tauchen regelmäßig auf, und das Muster ist immer dasselbe: nicht vertrauenswürdiger Inhalt plus ein leistungsfähiges Tool. Deshalb konzentrieren sich Gegenmaßnahmen auf die Einschränkung von Fähigkeiten statt allein auf Erkennung.

Wer ist in einer Engineering-Organisation für KI-Agenten-Sicherheit zuständig? In den meisten Teams liegt sie 2026 gemeinsam bei Platform Engineering und Security. Platform verantwortet Sandboxing, Credential Scoping und Audit-Logging; Security verantwortet Threat Modeling und die Prüfung neuer Tool-Integrationen, einschließlich MCP-Server.

Quellen

1. arXiv (agent red-teaming competition paper). "1.8 million prompt-injection attacks against 22 frontier agents; over 60,000 policy violations, most elicited within 10-100 queries." https://arxiv.org/abs/2507.20526. Abgerufen im August 2026.
2. NIST / Center for AI Standards and Innovation. "Agent hijacking success on Claude 3.5 Sonnet rose from 57% to 80% at 25 attempts per injection task." https://www.nist.gov/news-events/news/2025/01/technical-blog-strengthening-ai-agent-hijacking-evaluations. Abgerufen im August 2026.
3. IBM. "13% of organizations reported breaches of AI models or applications; 97% of those lacked proper AI access controls, 2025 Cost of a Data Breach Report." https://newsroom.ibm.com/2025-07-30-ibm-report-13-of-organizations-reported-breaches-of-ai-models-or-applications,-97-of-which-reported-lacking-proper-ai-access-controls. Abgerufen im August 2026.