Suche

Agenten-Sicherheit

Zero-Trust für autonome KI-Agenten – Blast-Radius begrenzen, Memory-Poisoning verhindern, Prompt-Injection abfangen. Sicherheit als Bauprinzip, nicht als Nachbesserung.

Das Thema in drei Schritten.

  1. 01 Einordnen 7 Kapitel im vollständigen Fachtext.
  2. 02 Prüfen Ein verknüpftes Szenario aus der Praxis.
  3. 03 Vertiefen 2 fachliche Anschlüsse zum Weiterlesen.
Inhalt 7 Kapitel
  1. 01 Warum Agenten-Sicherheit 2026 zum eigenen Thema wird
  2. 02 Die drei dominanten Angriffsklassen
  3. 03 Sechs Bauprinzipien
  4. 04 Zero-Trust für agentische Systeme
  5. 05 Was das im KMU heißt
  6. 06 Was der Agent überhaupt zu sehen bekommt
  7. 07 Verwandt

Warum Agenten-Sicherheit 2026 zum eigenen Thema wird

Mit jedem Tool, das ein KI-Agent ansteuern darf – CRM, ERP, Mail, Buchhaltung, MCP-Server – wächst der Blast-Radius: der Schaden, den eine einzige falsch ausgelöste Aktion anrichten kann. 2026 ist die Frage nicht mehr „Können wir Agenten?“, sondern „Wie begrenzen wir den Schaden, wenn ein Agent danebengreift oder durch Prompt-Injection manipuliert wird?“.

Die drei dominanten Angriffsklassen

AngriffWie es passiertGegenmaßnahme
Prompt-InjectionSchadhafte Anweisungen in Daten, die der Agent verarbeitet (Mails, Webseiten, PDFs, MCP-Toolausgaben)Trusted-Source-Trennung, Output-Sanitization, Mensch im Loop bei Schreib-Aktionen
Memory-PoisoningFalsche Fakten im persistenten Agent-Memory verbleiben über mehrere SessionsMemory-Quarantäne, Verfallsdaten, Audit-Trail für jedes Memory-Update
Tool-Privilege-EskalationAgent erhält über einen geschwächten MCP-Server Rechte, die er nicht haben sollteLeast-Agency, granulare Scopes, MCP-Server-Whitelisting

Diese drei Klassen sind keine Modellierungsübung. Im April 2026 zeigten Sicherheitsforscher um Aonan Guan, dass sich drei Agenten in GitHub Actions über Texte aus GitHub selbst kapern lassen: Claude Code Security Review über einen präparierten Titel eines Pull Requests, die Gemini CLI über Issue-Kommentare, der Copilot-Agent über einen versteckten Kommentar im Issue. Jeder Agent las den Text als Anweisung und gab Zugangsdaten seiner Umgebung heraus. Drei Hersteller, dasselbe Muster. Der Angriffsweg ist dabei bemerkenswert unspektakulär: kein Exploit, kein Zugriff auf das System, nur ein Textfeld, das jemand von außen befüllen darf. Die Hersteller haben einzelne Werkzeuge gesperrt oder Schutzanweisungen ergänzt; ob das den Angriff verhindert, ist offen.

Ein zweiter, belegter Fall traf einen Browser-Agenten: Eine präparierte Seite brachte ihn dazu, Einmalpasswörter aus dem Postfach des Nutzers auszulesen. OpenAI beschreibt Prompt Injection selbst als nicht vollständig lösbar. Auch ein vorgeschaltetes Prüfmodell, das geplante Tool-Aufrufe einstufen soll, lässt sich durch eingeschleuste Anweisungen verschieben. Es ist eine zusätzliche Schicht, kein Ersatz für eng gefasste Rechte und menschliche Freigabe bei riskanten Aktionen.

Die Konsequenz ist keine Warnung vor Agenten, sondern eine Regel für ihren Zuschnitt: Alles, was ein Agent liest und nicht selbst kontrolliert, ist potenziell eine Anweisung. Dazu gehören Pull-Request-Titel, Kommentare, Commit-Nachrichten, Ticket-Texte, E-Mail-Betreffe, Dateinamen und Werkzeugausgaben.

Sechs Bauprinzipien

  1. Least Agency – Jedes Tool ist eine bewusste Entscheidung, kein Default. Schreibrechte werden einzeln freigeschaltet, nicht pauschal. Bei zeitgesteuerten Läufen fragt niemand nach: Was ein solcher Lauf nicht können soll, regelst Du über die Zugänge, nicht über einen Satz im Prompt.
  2. Blast-Radius-Limit – Pro Aktion klären, wie groß der maximale Schaden wäre. „Mail an alle Kunden senden“ ist nie vollautonom.
  3. Trusted vs. Untrusted Input – Daten aus externen Quellen (Mails, Web, MCP-Tools) niemals direkt in Prompts. Sanitization und explizite Quellenmarkierung.
  4. Human in the Loop an Geld-, Compliance- und Identitäts-Aktionen – keine Ausnahmen. Wer freigibt, muss die Aktion tatsächlich ändern oder stoppen können und ihre Grundlage kennen; ein Klick auf „Bestätigen“ reicht nicht.
  5. AI BOM (AI Bill of Materials) – Welche Modelle, MCP-Server, Tools sind wo eingebunden? Audit-fähig, mit Versionsständen.
  6. Impossible vs. Tedious Tests – Test-Suiten, die nicht nur prüfen, ob der Agent die Aufgabe schafft, sondern ob er bei manipulierten Eingaben sauber abbricht.

Zero-Trust für agentische Systeme

Klassisches Zero-Trust war für Menschen-und-Geräte-Netzwerke gedacht. Übertragen auf Agenten: Jede Tool-Anbindung ist eine eigene Vertrauensgrenze. Der Agent darf nicht „mehr“ sehen, weil er gerade angemeldet ist – er sieht nur, was die Mission braucht. MCP-Server gehören geprüft, nicht blind eingebunden. Prompt- Injection über fremde MCP-Tools ist die Angriffsklasse Nr. 1 in 2026.

Was das im KMU heißt

Du brauchst kein Security-Operations-Center, um Agenten sicher zu betreiben. Du brauchst klare Antworten auf vier Fragen, bevor ein Agent in Produktion geht:

  • Was darf er lesen, was darf er schreiben? (Least-Agency-Liste)
  • Wo ist der Mensch verpflichtend dazwischen? (Geld, Compliance, Identität)
  • Wie merkst Du, wenn etwas schiefläuft? (Logging, Anomalie-Erkennung)
  • Wer drückt im Notfall den Aus-Knopf? (Klare Verantwortung, kein „IT fragt mal nach“)

Was der Agent überhaupt zu sehen bekommt

Die Least-Agency-Liste beantwortet, auf welche Systeme ein Agent zugreifen darf. Sie beantwortet nicht, was in dem Text steht, den er an das Modell weiterreicht. Genau dort entsteht die zweite Frage: Ein Agent, der Support-Mails triagiert oder Rechnungen ausliest, schickt Namen, IBANs und Vertragsnummern an einen kommerziellen Anbieter, ohne dass jemand die Entscheidung dafür bewusst getroffen hätte. Die Berechtigungsgrenze läuft um die Systeme, die Datengrenze läuft durch den Prompt – und die zweite wird beim Bauen regelmäßig übersehen.

Praktisch heißt das, den Weg zum Modell als eigene Stufe zu behandeln statt als Nebeneffekt der Tool-Anbindung. Wie diese Stufe aufgebaut ist und wo ihre Erkennung tatsächlich versagt, steht unter Pseudonymisierung & Anonymisierung.

Verwandt