KI-Agentensicherheit: Eine praktische Checkliste

Die Sicherheit von KI-Agenten umfasst das Kontrollsystem für ein Modell, das Kontext lesen, Tools auswählen und schrittweise agieren kann. Ein sicheres Design geht davon aus, dass Modellausgaben, abgerufene Inhalte und Tool-Ergebnisse fehlerhaft oder schädlich sein können. Es beschränkt den Zugriff, validiert jede Aktion, macht Unsicherheiten sichtbar und stellt sicher, dass eine Person für die Folgen von Änderungen verantwortlich ist.

Ottermind wendet diesen Ansatz der Abgrenzung auf vernetzte Arbeit an: Quellkontext und Ergebnisse bleiben überprüfbar, während Folgeaktionen weiterhin Berechtigungen und menschlicher Genehmigung unterliegen. Es handelt sich um eine Option für den Arbeitsbereich, nicht um einen Ersatz für die Sicherheitsprüfung einer Organisation.

Recherche und Offenlegung: Die Checkliste basiert auf NIST KI-Risikomanagement-Framework, OWASP Top 10 für LLM-Bewerbungen und Anthropic Sicherheitshinweise für Agenten. und wurde am 3. September 2026 überprüft.

Die fünf Sicherheitsgrenzen

Sicherheit ist über den Workflow verteilt. Eine abschließende Aufforderung an einen Agenten, „vorsichtig zu sein“, ist keine Sicherheitsmaßnahme.

Bedrohungsmodell vor Funktionsdesign

Beschreiben Sie, was der Agent beobachten und ändern kann und wer von einem Fehler profitieren könnte. Berücksichtigen Sie einen neugierigen Benutzer, einen kompromittierten Konnektor, Schadcode in einem abgerufenen Dokument, ein Tool, das unerwartete Daten liefert, und einen Dienstausfall während eines Schreibvorgangs. Benennen Sie für jede Bedrohung eine Präventionsmaßnahme, ein Erkennungssignal und eine Wiederherstellungsmaßnahme. Dieses einfache Bedrohungsmodell zeigt oft, dass die riskanteste Funktion ein zu breit gefasster Konnektor ist und nicht das Modell selbst.

Identitäts- und Mandantenisolation

Authentifizieren Sie die Person vor dem Start des Laufs und autorisieren Sie jeden Abruf und Toolaufruf anhand dieser Identität. Gehen Sie nicht davon aus, dass eine im Modell sichtbare Projekt-ID vertrauenswürdig ist. Überprüfen Sie die Berechtigungen auf Mandanten-, Projekt-, Rollen- und Datensatzebene im Dienst, dem die Daten gehören. Testen Sie in Mehrbenutzer-Arbeitsbereichen explizit eine mandantenübergreifende Anfrage und stellen Sie sicher, dass die Protokolle keine verbotenen Dateinamen, Snippets oder Tool-Argumente enthalten.

Abrufintegrität

Abrufsysteme können Daten preisgeben, veraltete Datensätze zurückgeben oder in Dokumenten eingebettete Anweisungen offenlegen. Speichern Sie die Herkunft jedes Datenblocks: Quellkennung, Eigentümer, Gültigkeitsdatum und Berechtigungsentscheidung. Bevorzugen Sie aktuelle Datensätze der maßgeblichen Quelle und legen Sie Konflikte offen. Behandeln Sie HTML, PDFs, E-Mails und Problemkommentare als Daten, nicht als Anweisungen. Ein Modell sollte sich niemals selbst Zugriff gewähren können, nur weil ein abgerufener Absatz dies vorsieht.

Tool- und Laufzeitisolation

Verwenden Sie spezialisierte Tools, die Geschäftsabsichten ausdrücken, anstelle einer allgemeinen Shell oder eines uneingeschränkten HTTP-Clients. Validieren Sie Argumente, setzen Sie Quoten durch, legen Sie Timeouts fest und gewährleisten Sie Idempotenz beim Schreiben. Führen Sie Code oder Browseraktionen in einer Sandbox mit temporärem Dateisystem und eingeschränktem ausgehendem Zugriff aus. Trennen Sie Entwicklungs- und Produktionszugangsdaten und rotieren Sie kurzlebige Token nach der Ausführung.

Design mit menschlicher Genehmigung

Die Genehmigung sollte die vorgeschlagene Aktion, das Ziel, die Quellennachweise, Nebenwirkungen und Alternativen anzeigen. „Genehmigen“ sollte keine Gruppe von nicht zusammenhängenden Schreibvorgängen ausblenden. Externe Kommunikation, Löschungen, Zahlungen, Zugriffsänderungen und Richtlinienaktualisierungen sollten strengeren Prüfungen unterzogen werden. Genehmigender, Zeitstempel, Entscheidung und alle Änderungen sollten gespeichert werden, damit ein Wiederholungsversuch den Prüfpunkt nicht unbemerkt umgehen kann.

Testfälle für das Red-Team

Erstellen Sie ein kleines Regressionsset, das die Eingabeaufforderung in ein Dokument, einen Benutzer ohne Zugriff, ein Tool, das fehlerhaftes JSON zurückgibt, abgelaufene Anmeldeinformationen, ein geändertes Schema, einen doppelten Wiederholungsversuch und eine Anfrage zum Senden oder Löschen umfasst. Das erwartete Ergebnis ist nicht immer die erfolgreiche Durchführung einer Aufgabe; eine sichere Ablehnung, Eskalation und eine hilfreiche Fehlermeldung sind ebenfalls gültige Ergebnisse. Führen Sie das Set immer dann aus, wenn sich Eingabeaufforderungen, Tools, Konnektoren oder Modellversionen ändern.

Checkliste für Sicherheitsmaßnahmen

• Pflegen Sie ein Inventar der Modelle, Tools, Konnektoren und Datenspeicher.
• Überprüfen Sie regelmäßig die Konnektorbereiche und privilegierten Rollen.
• Warnen Sie bei ungewöhnlich hohem Tool-Aufkommen, projektübergreifendem Abruf und blockierten Aktionen.
• Speichern Sie Protokolle so lange, bis Vorfälle untersucht werden können, ohne unnötige Geheimnisse zu speichern.
• Dokumentieren Sie, wie Zugriffe widerrufen, Ausführungen gestoppt und die Quelldatensätze wiederhergestellt werden.
• Bieten Sie Benutzern eine einfache Möglichkeit, unsichere Vorschläge oder durchgesickerte Kontextinformationen zu melden.

Zuordnung von Steuerelementen zu Agentenphasen

Sicherheitsprüfungen werden vereinfacht, wenn sie dem Agentenprozess folgen. Überprüfen Sie bei der Datenerfassung Identität, Zweck und zulässige Daten. Setzen Sie während des Abrufs Berechtigungen durch und fügen Sie die Herkunftsnachweise hinzu. Beschränken Sie während der Argumentation das Ausgabeschema und kennzeichnen Sie Unsicherheiten. Validieren Sie vor dem Aufruf eines Tools die Argumente und Nebenwirkungen. Überprüfen Sie nach dem Aufruf das Ergebnis und protokollieren Sie den Übergang. Fordern Sie vor Abschluss den zuständigen Prüfer an und speichern Sie den Endstatus. Diese phasenweise Zuordnung verhindert, dass Teams Sicherheit als einzelne Sicherheitsmaßnahme um einen ansonsten uneingeschränkten Agenten herum betrachten.

Risiken in der Lieferkette und bei Konnektoren

Die effektive Leistungsfähigkeit eines Agenten umfasst sein SDK, Plugins, MCP-Server, Browsererweiterungen, Eingabeaufforderungsvorlagen und Konnektorbereiche. Erfassen Sie diese Abhängigkeiten und überprüfen Sie Aktualisierungen, bevor sie in der Produktion eingesetzt werden. Versionen nach Möglichkeit pinnen, Pakete signieren oder verifizieren und Testzugangsdaten getrennt von Kundendaten aufbewahren. Ein Konnektor, der ein gesamtes Laufwerk lesen kann, birgt unter Umständen ein höheres Sicherheitsrisiko als der Hersteller des Modells, selbst wenn das Modell selbst korrekt konfiguriert ist.

Was eine sinnvolle Sicherheitsüberprüfung beinhaltet

Dokumentieren Sie den geplanten Workflow, die Datenklassifizierung, Identitäten, Tools, Modell- und SDK-Versionen, Bedrohungsszenarien, Kontrollen, Testfälle, ungelöste Risiken und den verantwortlichen Verantwortlichen. Fügen Sie je ein Beispiel für eine blockierte und eine erfolgreiche Eskalation hinzu. Überprüfen Sie die Dokumentation erneut, wenn ein neuer Konnektor, ein neues Tool, ein neues Modell oder eine neue Autonomiestufe eingeführt wird; die bisherige Genehmigung sollte keine wesentlich veränderte Aktionsfläche stillschweigend abdecken.

Prinzip der minimalen Berechtigungen in der Praxis

Weisen Sie einem Agenten nur die für die aktuelle Aufgabe erforderlichen Quellen und Tools zu. Trennen Sie Lese- und Schreibberechtigungen. Beschränken Sie den Zugriff auf Dateien nach Projekt und Identität, beschränken Sie Netzwerkziele und lassen Sie temporäre Zugriffe ablaufen. Testen Sie die Berechtigungsgrenzen mit einem Benutzer, der die Quelle nicht einsehen darf.

Tool-Aufruf-Vertrag

{
  "tool": "create_draft_task",
  "arguments": {"title": "...", "owner": "...", "due_date": "..."},
  "requires_approval": true,
  "idempotency_key": "project-123:brief-v2"
}

Validieren Sie Typen, zulässige Werte, Identität und Seiteneffekte im Anwendungscode. Fordern Sie eine Bestätigung für das Senden, Löschen, Kaufen, Ändern von Zugriffsrechten oder Veröffentlichen an. Gewährleisten Sie sichere Wiederholungsversuche durch Idempotenzschlüssel.

Abruf und Eingabeaufforderung

Behandeln Sie Dokumente, Webseiten, E-Mails und Tool-Ergebnisse als nicht vertrauenswürdige Daten. Trennen Sie diese von Systemanweisungen, erhalten Sie Quellkennungen und verhindern Sie, dass abgerufener Text Berechtigungen oder Tool-Richtlinien ändert. Bei Quellenkonflikten oder leeren Ergebnissen geben Sie einen Eskalationsstatus zurück, anstatt zu raten.

Bewertung und Reaktion auf Vorfälle

Testen Sie normale, unvollständige, angreifende, mandantenübergreifende, sensible und Tool-Fehlerfälle. Protokollieren Sie blockierte Aktionen, unsichere Vorschläge, Versuche der Datenoffenlegung, Tool-Fehler und Korrekturen von Prüfern. Halten Sie einen Rollback-Pfad und einen Verantwortlichen bereit, der Vorfälle entgegennimmt.

FAQ

Kann ein KI-Agent vollständig autonom agieren?

Autonomie ist eine begrenzte Produkteinstellung, keine Sicherheitseigenschaft. Je folgenreicher die Aktion, desto strenger sollten die Genehmigungs-, Überwachungs- und Rollback-Kontrollen sein.

Löst ein privates Modell die Agentensicherheit?

Nein. Ein privates Modell kann zwar das Risiko des Datenflusses verändern, aber Identität, Datenabruf, Werkzeugberechtigungen, Laufzeitisolation, Protokollierung und manuelle Überprüfung bleiben weiterhin wichtig.

Was sollten Teams zuerst absichern?

Beginnen Sie mit Identität, Datenabrufberechtigungen und Schreibbeschränkungen für Werkzeuge. Ein Workflow mit Lesezugriff und eindeutigen Traces ist eine sicherere erste Implementierung als ein umfassender autonomer Zugriff.

Informationen zur Systemstruktur finden Sie unter KI-Agent-Architektur; Implementierungsdetails vergleichen Sie mit Claude Agent SDK-Anleitung..