KI-Agenten sicher einsetzen: Rechte, Freigaben, MCP-Server und Protokollierung

Ein Chat-Assistent antwortet, ein Agent handelt: Er erhält Werkzeuge, etwa Dateizugriff, E-Mail, Shell oder Schnittstellen, und entscheidet selbst, wann er sie aufruft. OWASP nennt die Folge „Excessive Agency“ (LLM06:2025): schädliche Aktionen als Reaktion auf unerwartete, mehrdeutige oder manipulierte Ausgaben des Modells, gleich warum es sich fehlverhält. Die Ursachen sind zu viel Funktionalität, zu viele Berechtigungen und zu viel Autonomie. Die OWASP Top 10 für agentische Anwendungen 2026 (veröffentlicht am 9.12.2025) erweitern das um den Grundsatz der geringsten Handlungsmacht (Least Agency): Agentisches Verhalten dort einsetzen, wo es nötig ist, weil es sonst die Angriffsfläche ohne Nutzen vergrößert.

1. 1

   Werkzeuge auf das Nötige beschränken

   Nur die Erweiterungen anbieten, die der Agent für seine Aufgabe braucht, und darin nur die nötigen Funktionen: Wer E-Mails zusammenfasst, braucht Lesen, nicht Senden oder Löschen. Offene Werkzeuge wie beliebige Shell-Befehle oder URL-Abrufe vermeiden (OWASP LLM06, Maßnahmen 1 bis 3).

2. 2

   Berechtigungen minimieren

   Jedem Werkzeug nur die Rechte geben, die es braucht, etwa Lesezugriff auf eine Tabelle statt auf die ganze Datenbank, und es im Kontext des jeweiligen Benutzers ausführen (LLM06, Maßnahmen 4 und 5).

3. 3

   Folgenreiche Aktionen freigeben lassen

   Ein Mensch bestätigt Aktionen mit großer Wirkung, bevor sie ausgeführt werden: senden, löschen, bezahlen, Berechtigungen ändern, veröffentlichen (LLM06, Maßnahme 6; LLM01, Maßnahme 5).

4. 4

   Autorisierung nicht dem Modell überlassen

   Ob eine Aktion erlaubt ist, entscheidet das Zielsystem nach seinen Regeln, nicht das Sprachmodell. Jede Anfrage über ein Werkzeug wird dort gegen die Sicherheitsrichtlinie geprüft (LLM06, Maßnahme 7: complete mediation).

5. 5

   Fremde Inhalte als nicht vertrauenswürdig behandeln

   Websites, Dokumente, E-Mails und Werkzeugbeschreibungen von MCP-Servern können Anweisungen enthalten. Sie werden getrennt und gekennzeichnet verarbeitet und dürfen keine Aktionen ohne Prüfung auslösen (LLM01, Maßnahme 6; MCP-Spezifikation).

6. 6

   Protokollieren und begrenzen

   Aufrufe von Werkzeugen und Aktionen in Zielsystemen protokollieren und überwachen, Raten und Budgets begrenzen, damit Fehlverhalten auffällt, bevor großer Schaden entsteht (LLM06; OWASP ASI02, Maßnahme 5).

Ein Beispiel aus OWASP LLM06: Ein Assistent, der E-Mails zusammenfasst, wird mit einer Erweiterung gebaut, die nur lesen kann, meldet sich mit einem OAuth-Zugang mit reinem Lese-Umfang an, und jede von ihm entworfene E-Mail sendet erst der Mensch nach Durchsicht ab.

• Eigene Identität je Agent und Aufgabe statt des persönlichen Kontos einer Administratorin oder eines Entwicklers; so bleibt nachvollziehbar, wer gehandelt hat (OWASP ASI03).
• Kurzlebige, eng begrenzte Token je Aufgabe statt dauerhafter Schlüssel; Rechte über Grenzen deckeln (ASI03, Maßnahme 1; ASI02: just-in-time und kurzlebige Zugänge).
• Zugangsdaten je MCP-Server getrennt und eng begrenzt, nichts aus der eigenen Shell geerbt, nichts wiederverwendet (MCP Local Server Security, Checkliste).
• MCP-Server dürfen keine Token annehmen, die nicht ausdrücklich für sie ausgestellt wurden, und Token nicht ungeprüft an nachgelagerte Schnittstellen weiterreichen (MCP Security Best Practices: Token Passthrough, „MUST NOT“).
• Geheimnisse gehören in einen Tresor oder die Anmeldedatenverwaltung des Systems, nicht in Prompts, Chatverläufe oder Konfigurationsdateien im Repository.
• Zugänge eines Agenten müssen sich zentral sperren und erneuern lassen, wenn er sich auffällig verhält (ASI04 und ASI10: Notabschaltung und Widerruf von Zugangsdaten).

MCP-Server stellen einem Agenten Werkzeuge, Daten und Vorlagen bereit. Die Spezifikation (Fassung 2026-07-28) sagt dazu: Werkzeuge bedeuten beliebige Codeausführung und sind entsprechend vorsichtig zu behandeln; Beschreibungen des Werkzeugverhaltens gelten als nicht vertrauenswürdig, außer sie stammen von einem vertrauenswürdigen Server; Hosts müssen vor dem Aufruf eines Werkzeugs die ausdrückliche Zustimmung des Benutzers einholen. Durchsetzen kann das Protokoll diese Grundsätze nicht selbst, das müssen die Anwendungen tun.

• Braucht der Server lokale Dateien, Werkzeuge oder das lokale Netz? Wenn nicht, die entfernte Fassung über Streamable HTTP mit Autorisierung statt eines lokalen Prozesses nutzen
• Herausgeber identifiziert, Quellcode einsehbar, exakter Paketname geprüft (Tippfehler-Pakete), Version fest angeheftet
• Bei Starthilfen wie npx oder uvx bedenken, dass die Versionsangabe nur das oberste Paket festlegt; ein Container-Image mit Digest friert alle Abhängigkeiten ein
• Werkzeugbeschreibungen vor dem Einsatz gelesen; Server mit fremden Anweisungen in Beschreibungen entfernt; Client fragt erneut, wenn sich Werkzeuge ändern
• Fremde Server isoliert in Container, Sandbox oder virtueller Maschine, ohne unnötige Laufwerkseinbindungen
• Dateizugriff auf bestimmte Verzeichnisse beschränkt, wo möglich nur lesend
• Ausgehender Netzverkehr gesperrt oder auf eine bekannte Liste von Zielen beschränkt
• Nur so viele Server wie nötig, weil alle konfigurierten Server denselben Kontext des Modells teilen
• Im Unternehmen: Liste freigegebener Server mit Kriterien, laufende Inventur der Client-Konfigurationen, Protokolle der MCP-Aktivität, Server zentral sperrbar

Die Prüfpunkte folgen dem Leitfaden „Local Server Security“ der MCP-Dokumentation (Fassung 2026-07-28). Er nennt die Isolation des Prozesses die wirksamste einzelne Maßnahme, weil sie auch dann schützt, wenn die Prüfung der Herkunft versagt.

Das Beispiel beschreibt Funktionen laut Herstellerdokumentation, keine Bewertung oder Empfehlung eines Produkts. Anthropic weist selbst darauf hin, dass kein System gegen alle Angriffe immun ist und Vorschläge vor der Freigabe zu prüfen sind.

Unabhängig von der Stufe verlangt Art. 4 der KI-Verordnung in der Fassung der VO (EU) 2026/1744, dass Anbieter und Betreiber Maßnahmen ergreifen, um die KI-Kompetenz der Personen zu unterstützen, die in ihrem Auftrag mit KI-Systemen arbeiten. Wer Agenten freigibt oder überwacht, muss ihre Grenzen kennen.

• Aufgabe, Grenzen und verantwortliche Person des Agenten schriftlich festgelegt
• Agentisches Verhalten ist für die Aufgabe nötig; einfachere, feste Abläufe wurden geprüft
• Nur nötige Werkzeuge und Funktionen freigeschaltet, keine offenen Shell- oder Abrufwerkzeuge ohne Grund
• Eigene Identität mit geringsten Rechten, kurzlebige Zugänge, keine geteilten Administratorkonten
• Folgenreiche Aktionen brauchen eine menschliche Freigabe; die Liste dieser Aktionen ist festgelegt
• Zielsysteme prüfen jede Anfrage selbst gegen ihre Berechtigungen
• Inhalte Dritter werden als nicht vertrauenswürdig behandelt; Tests mit eingeschleusten Anweisungen durchgeführt
• MCP-Server nach Herkunft geprüft, Version angeheftet, isoliert, mit eigenem eng begrenztem Zugang
• Netzzugang des Agenten und seiner Werkzeuge auf bekannte Ziele beschränkt
• Alle Werkzeugaufrufe und Aktionen protokolliert, Auswertung und Aufbewahrung geregelt
• Budgets und Ratenbegrenzung gesetzt, Notabschaltung und Widerruf der Zugänge getestet
• Datenschutz geprüft: Rechtsgrundlage, Vertrag mit dem Anbieter, gegebenenfalls Datenschutz-Folgenabschätzung
• Nutzende geschult; Meldeweg für auffälliges Verhalten bekannt

Die Prüfliste ist eine Empfehlung von TOMORIS auf Grundlage der genannten OWASP- und MCP-Veröffentlichungen; sie ersetzt keinen Sicherheitstest des konkreten Agenten.