[!NOTE] Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Die besten AI Agent-Sicherheitsmuster im Jahr 2026
Agent-Sicherheit bezieht sich auf die Steuerung von Aktionen. Ein Chatbot kann eine falsche Antwort liefern. Ein Agent hingegen kann echte Anmeldeinformationen verwenden, Tools aufrufen und Produktionsdaten verändern.
Die Standardregel ist einfach: Gewähren Sie einem Agent keine Funktionen, die es nicht benötigt. Beginnen Sie mit eingeschränkten Werkzeugen, Richtlinienüberprüfungen vor jedem Tool Call, isolierten Sandboxes, begrenzten Zugangsrechten, menschlichen Freigabestufen sowie Audits von Traces. Fügen Sie außerdem Guardrails und Ausgabefilter hinzu, betrachten Sie diese jedoch nicht als primäre Sicherheitsbarriere.
Muster-Ranking
| Muster | Priorität | schützt vor | Hinweis zur Implementierung |
|---|---|---|---|
| Tools mit minimalem Berechtigungsprofil | P0 | Übermäßige Agenz | Veröffentlichen Sie auf keinen Fall Werkzeuge, die der Agent unter keinen Umständen verwenden darf. |
| Prüfungen der Voreinstellungen vor der Tool-Nutzung | P0 | Gefährliche Aktionen | Überprüfen Sie die konkrete Aktion unmittelbar vor der Ausführung. |
| Sandboxes | P0 | Schäden an Dateien, der Shell, dem Browser sowie dem Netzwerk | Isoliere Code sowie unzuverlässige Inhalte. |
| Menschliche Freigaben | P0 | irreversible oder regulierte Aktionen | Gate-Writes, Deployments-, Zahlungen, externe Sendungen sowie privilegierte Änderungen. |
| Begrenzte Anmeldeinformationen | P0 | Übergriffe bei der Bereitstellung von Zugangsdaten sowie Fehler durch fehlerhaft konfigurierte Stellvertreterkomponenten | Verwenden Sie eng gefasste Scope-Einstellungen pro Server sowie pro Tool. |
| MCP Serverisolierung | P1 | Tool-Vergiftung, Tool-Schattierung, Angriffe zwischen Servern | Vermeiden Sie es, unzuverlässige Server mit leistungsstarken Tools in einem und demselben Kontext ohne vorherige Prüfung zu kombinieren. |
| Auditorie von Traces | P1 | Unbekannte Vorgeschichte von Incidents | Die Benutzeranfrage, Tool Call, die Argumente, das Ergebnis, die Entscheidung gemäß der Richtlinie sowie der Genehmiger werden persistent gespeichert. |
| Guardrails | P1 | Unsichere Eingabedaten und Ausgabetexte | Nützlich, reicht aber nicht aus, um eine autoritative Tool-Position zu erreichen. |
| Red-Teaming mit Evals | P1 | Bekannte Angriffswege | Testen Sie Prompt Injection, Tool-Vergiftung, Datenextraktion sowie Umgehungen von Berechtigungsregeln. |
Was zuerst implementiert werden sollte
Entfernen Sie zunächst die entsprechenden Funktionalitäten. Wenn der Agent nicht auf GitHub schreiben muss, sollten ihm keine Schreibrechte Token erteilt werden. Fällt seine Anforderung lediglich auf die Überprüfung der Kalenderverfügbarkeit, so ist ein vollständiger Zugriff auf den Posteingang nicht erforderlich. Eine eingeschränkte Berechtigung ist sicherer als allumfassende Prompt.
Überprüfen Sie anschließend die Richtlinien vor jedem Aufruf von Tool Call. Prüfen Sie dabei den Namen des Tools, die übergebenen Argumente, das Zielressourcensystem, den Benutzer, die Umgebung sowie mögliche Nebeneffekte. Selbst eine auf den ersten Blick harmlose Anfrage kann zu einem gefährlichen Shell-Befehl führen.
Fügen Sie Sandboxes hinzu, um Codeausführung, Browserautomatisierung, Dateizugriff sowie die Verarbeitung unzuverlässiger Dokumente zu ermöglichen. Ein Sandbox macht die Aktion zwar nicht korrekt, verringert aber den Schaden durch einen kompromittierten Tool Result oder verwirrte Model.
Verwenden Sie die Zustimmung eines Menschen für irreversible Aktionen. Genehmigen Sie nicht jeden einzelnen Schritt. Genehmigen Sie stattdessen nur Grenzbereiche: Produktionseinrichtungen, Datenlöschungen, E-Mail-Verteilungen, Geldtransfers, Berechtigungsänderungen sowie regulatorisch relevanten Entscheidungen.
Risiken, die spezifisch für MCP gelten
MCP ist nützlich, da er den Zugriff auf Tools standardisiert. Gleichzeitig birgt er Risiken, denn Toolbeschreibungen, Schemata, Serveridentitäten, OAuth-Scope-Berechtigungen sowie die Ausgaben der Tools werden alle Teil des Entscheidungskontextes von Model.
Für MCP würde ich diese Regeln bei der Code-Review beibehalten:
- Prüfen Sie die Beschreibungen sowie Schemata der Tools vor der Freigabe.
- Verwenden Sie vorzugsweise eng gefasste Zugangsdaten pro Server.
- Trennen Sie unzuverlässige MCP-Server von sensiblen Tools ab.
- Achten Sie auf Änderungen in den Tool-Definitionen nach der Installation.
- Behandeln Sie die Ausgabe der Tools als unzuverlässige Eingabedaten.
- Protokollieren Sie jeden Server, jedes Tool, jede Argumente sowie jedes Ergebnis.
Guardrails reichen nicht aus
Guardrails kann Eingaben und Ausgaben validieren. Sie lösen jedoch nicht die Probleme im Zusammenhang mit dem Prinzip des geringsten Privilegs, dem Gültigkeitsbereich von Zugangsdaten, dem Sandboxing, dem Tool-Poisoning oder der Genehmigungspolitik. Behalten Sie sie bei, platzieren Sie sie jedoch nach der Konzeption der Funktionalitäten und vor der für den Benutzer sichtbaren Ausgabe.
Weitere Lektüre
- AI Agent Sicherheit im Jahr 2026 dies ist der vollständige Architekturleitfaden. AI Agent Tool Use im Jahr 2026 erläutert MCP, die verwendeten Tools, die CLI, erforderliche Fähigkeiten sowie den Ablauf der Codeausführung.
- AI Agent Runtime im Jahr 2026 er umfasst die Grenzen von Runtime für langlaufende Agents.