AI-Agent-Sicherheitscheckliste: Tools, Prompts und Daten vor der Delegation pruefen
Eine umsetzbare Checkliste fuer Teams, die AI Agents mit Tools, Datenquellen, Berechtigungen und menschlichen Freigaben einsetzen.
Zuletzt aktualisiert am
Ein AI Agent ist nicht nur ein Chatfenster. Sobald er Dateien liest, Webseiten verarbeitet, Tickets aktualisiert, Shell-Befehle vorschlaegt oder ein externes Tool aufruft, verbindet er Sprachmodell, untrusted Inhalte und echte Berechtigungen. Die Sicherheitsfrage lautet deshalb nicht nur: “Kann das Modell etwas Falsches sagen?” Sie lautet auch: “Was kann dieses System tun, wenn es eine Anweisung falsch einordnet oder eine manipulierte Quelle vertraut?”
Eine Sicherheitscheckliste hilft, Arbeit schrittweise zu delegieren. Sie entscheidet nicht abstrakt, ob Agents erlaubt sind. Sie legt fuer einen konkreten Job fest, welche Daten sichtbar sind, welche Tools wirklich gebraucht werden, welche Schritte einen Menschen brauchen und welche Spuren nach dem Lauf erhalten bleiben. Die Hinweise wurden am 12. Juli 2026 geprueft. Tool-Integrationen und Bedrohungen entwickeln sich schnell; pruefen Sie daher die aktuelle Dokumentation des jeweiligen Anbieters.
Drei Ebenen, die getrennt geprueft werden muessen
| Ebene | Typisches Problem | Prueffrage |
|---|---|---|
| Anweisungen | Ein Ticket, eine Webseite oder ein Dokument versucht Regeln zu ueberschreiben | Kann der Agent Nutzerauftrag und untrusted Inhalt unterscheiden? |
| Tools | Ein Tool hat zu breite Rechte, irrefuehrende Metadaten oder einen unklaren Owner | Sieht der Agent nur Tools, die fuer diesen Job erforderlich sind? |
| Daten | Externe Daten werden wie vertrauenswuerdige Steuerinformation behandelt | Sind Herkunft, Sensitivitaet und Ausfuehrungskontext getrennt? |
Prompt Injection bleibt wichtig, aber sie ist nicht die einzige Gefahr. Ein Agent kann zudem eine manipulierte Tool-Beschreibung uebernehmen, vertrauliche Daten in einen falschen Kontext kopieren, Tokens zu breit verwenden oder eine Kette harmloser Befehle zu einer schaedlichen Aktion verbinden. Der sicherere Entwurf setzt nicht auf die Hoffnung, dass das Modell jede Manipulation erkennt. Er begrenzt die Folgen, wenn es das nicht tut.
Checkliste vor einer echten Delegation
| Kontrolle | Guter Startwert | Warnsignal |
|---|---|---|
| Aufgabenumfang | Ein konkretes Ergebnis und klares Ende | ”Klaere alles, was auftaucht” |
| Datenklassifizierung | Vertrauenswuerdige Eingaben und externe Inhalte sichtbar getrennt | Ticket, E-Mail, Webseite und Geheimnis landen im selben Kontext |
| Tool-Inventar | Jedes Tool hat Owner, Zweck und Berechtigungsstufe | Viele aehnliche Tools ohne nachvollziehbaren Bedarf |
| Rechte | Read-only als Standard; Schreiben braucht Freigabe | Agent darf direkt deployen, loeschen, zahlen oder E-Mails senden |
| Zugangsdaten | Kurzlebig, scoped und je Dienst getrennt | Ein allgemeiner Token wird durch mehrere Systeme gereicht |
| Genehmigung | Externe, teure oder irreversible Schritte halten an | Ein Lauf kann ohne Sichtung Schaden verursachen |
| Protokoll | Prompt, Tool-Aufruf, Ergebnis, Freigabe und Aktion werden erfasst | Nur die freundliche Schlussantwort bleibt sichtbar |
| Testfaelle | Normale, chaotische und adversariale Eingaben | Bewertung nur mit einer Demo auf Happy Path |
Die praktischste Regel fuer kleine Teams lautet: Was schwer rueckgaengig zu machen ist, braucht vor der Ausfuehrung eine menschliche Freigabe. Dazu gehoeren Produktionsaenderungen, Datenloeschungen, Vertrags- oder Zahlungsprozesse, externe Nachrichten und Berechtigungswechsel.
Prompt Injection, Tool Poisoning und Dateninjektion
| Risiko | Bedeutung in Alltagssprache | Beispiel |
|---|---|---|
| Prompt Injection | Externer Text versucht den Auftrag oder Schutzregeln zu ueberschreiben | Eine gelesene Seite fordert den Agent auf, interne Instruktionen offenzulegen |
| Tool Poisoning | Tool-Name oder Beschreibung lenkt die Tool-Auswahl in eine falsche Richtung | Ein angebliches Analyse-Tool fordert den Agent zum Export vertraulicher Daten auf |
| Dateninjektion | Untrusted Daten sehen aus wie Metadaten, Pfade oder Steuerinformation | Eine Antwort manipuliert Origin, Dateipfad oder naechste Aktion |
Der Unterschied ist fuer die Abwehr wichtig. Ein Filter fuer offensichtliche Instruktionen reicht nicht, wenn ein Wert in einer strukturierten Antwort spaeter als Pfad, URL oder Berechtigung interpretiert wird. Tool-Ergebnisse brauchen ebenso Herkunft und Begrenzung wie Webseiten und E-Mails.
MCP gezielt statt maximal verbinden
MCP standardisiert Verbindungen zwischen AI-Anwendungen, Tools und Datenquellen. Das kann die Integration klarer machen, aber jede neue Verbindung erweitert die Angriffsoberflaeche. Vor dem Einsatz eines MCP-Servers sollte ein Team diese Fragen beantworten:
- Wer betreibt den Server, und kann das Team Implementierung oder Lieferkette pruefen?
- Welche Daten liest er, welche Aktionen kann er ausloesen und welche Scopes sind dafuer notwendig?
- Sind Tool-Namen und Beschreibungen eindeutig genug, damit ein Modell sie nicht verwechselt?
- Gibt es pro Nutzer und pro Aufgabe minimalen Consent statt eines globalen Zugriffs?
- Werden Tokens fuer den richtigen Empfaenger ausgestellt und nicht ungeprueft weitergereicht?
- Werden interne Netzadressen und unerwartete Redirects bei Tool-Aufrufen begrenzt?
- Laesst sich nachtraeglich nachvollziehen, welcher Agent welches Tool mit welchen Eingaben nutzte?
Mehr Tools bedeuten nicht mehr Autonomie. Der bessere Aufbau zeigt einem Agent fuer einen Support-Triage-Job vielleicht nur Suche, Klassifikation und Entwurf. Ein Deployment-Tool, ein CRM-Schreibzugriff und ein Finanzsystem bleiben unsichtbar, bis ein eigener Workflow mit eigenen Kontrollen existiert.
Beispiel aus einem DACH-B2B-Team
Ein deutsches SaaS-Team moechte eingehende Sicherheitsfrageboegen zusammenfassen und Antworten aus freigegebenen Produktunterlagen vorbereiten. Die erste Version sollte nicht direkt im Kundenportal antworten. Sie kann Dokumente aus einer freigegebenen Wissensbasis lesen, fehlende Informationen markieren und einen Antwortentwurf erzeugen. Ein Security- oder Account-Owner bestaetigt jede Aussage vor dem Versand.
| Phase | Agent darf | Mensch prueft |
|---|---|---|
| Eingang | Fragebogen einordnen und oeffentliche Informationen suchen | Ob vertrauliche Anlagen oder Sonderklauseln vorliegen |
| Entwurf | Quellen zuordnen und Unsicherheiten markieren | Fakten, Datenschutzbehauptungen und Vertragsbezug |
| Versand | Keine externe Nachricht ohne Freigabe | Empfaenger, finale Formulierung und Anhang |
| Nachlauf | Lauf und Quellen protokollieren | Auffaellige Eingaben fuer den Testkatalog |
Dieses Muster passt zu Umgebungen mit Beschaffung, Datenschutz-Review und deutscher sowie englischer Produktdokumentation. Es macht den Agent nuetzlich, ohne ihn zum nicht pruefbaren Entscheider zu machen.
Checkliste fuer Coding Agents
| Vor der Freigabe | Mindestpruefung |
|---|---|
| Dateiaenderungen | Arbeitsverzeichnis begrenzen und generierte Patches reviewen |
| Befehle | Lesen von Installieren, Loeschen, Deployen und anderen Zustandsaenderungen trennen |
| Dependencies | Paketname, Registry, Lockfile und Postinstall-Skripte pruefen |
| Secrets | Keine Tokens in Prompts, Logs, generierten Dateien oder Shell-Historie |
| Pull Requests | Tests, Diff-Review und nachvollziehbare Herkunft verlangen |
| Externe Texte | Issues, READMEs, Kommentare und Web-Snippets als untrusted behandeln |
Ein Coding Agent wird besonders riskant, wenn Shell, Netzwerk, Tokens und Schreibrechte ohne dauerhafte Aufzeichnung kombiniert sind. Produktivitaet entsteht nicht durch maximale Rechte, sondern durch eine sichtbare Review-Kette.
Ein sinnvoller Start in dieser Woche
- Waehlen Sie einen wiederholbaren Job, etwa Support-Triage oder einen Pull-Request-Entwurf.
- Starten Sie mit Read-only-Zugang und einem kleinen Tool-Inventar.
- Dokumentieren Sie fuer jedes Tool Zweck, Owner, Inputs, Outputs und Berechtigung.
- Legen Sie Freigabe fuer Schreiben, externe Kommunikation, Kauf, Deployment und Loeschen fest.
- Speichern Sie Prompts, Tool-Aufrufe, Tool-Ergebnisse, Freigaben und finale Aktionen.
- Testen Sie mindestens eine adversariale Eingabe, beispielsweise ein Ticket mit einer Aufforderung, Regeln zu ignorieren.
- Erweitern Sie Rechte erst nach mehreren nachvollziehbar sicheren Durchlaeufen.
Nicht geeignet fuer unbeaufsichtigte Agents sind Zahlungs- und Personalprozesse, irreversible Produktionsaenderungen, gemischte Datenquellen mit Kundentext, unbekannte Drittserver und Workflows ohne brauchbare Logs. Progressive Delegation ist belastbarer: lesen, zusammenfassen, entwerfen, vorschlagen, dann nach Freigabe handeln.