Security-Checkliste für AI Agents: Berechtigungen und Sandboxes
Automatische Übersetzung Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Bei der Agent-Security geht es um die Kontrolle von Aktionen. Ein Chatbot kann eine falsche Antwort liefern. Ein Agent kann echte Credentials verwenden, ein Tool aufrufen und Produktionsdaten ändern.
Die Standardregel ist einfach: Geben Sie einem Agent keine Capabilities, die er nicht benötigt. Beginnen Sie mit eingeschränkten Tools, Policy Checks vor jedem Tool Call, isolierten Sandboxes, begrenzten Credentials, Human Approval Gates und Audit Traces. Fügen Sie außerdem Guardrails und Output-Filter hinzu, betrachten Sie diese aber nicht als zentrale Security Boundary.
Bedrohungsmodell und Review-Datum: 2026-08-10. Diese Prioritäten setzen voraus, dass ein Tool-using Agent vom Angreifer kontrollierte Eingaben verarbeiten sowie Daten lesen oder externe Side Effects auslösen kann. Assistants mit geringeren Capabilities benötigen weniger Controls; Aktionen mit höherem Impact erfordern strengere Isolation und Freigaben.
Ranking der Patterns
| Pattern | Priorität | Schutz vor | Implementierungshinweis |
|---|---|---|---|
| Least-Privilege-Tools | P0 | Übermäßiger Handlungsspielraum | Befolgen Sie die OWASP MCP Guidance: Stellen Sie keine Tools bereit, die der Agent niemals verwenden sollte. |
| Pre-Tool-Policy-Checks | P0 | Gefährlichen Aktionen | Prüfen Sie die konkrete Aktion unmittelbar vor der Ausführung. |
| Sandboxes | P0 | Schäden an Dateien, Shell, Browser und Netzwerk | Isolieren Sie Code und nicht vertrauenswürdige Inhalte; verweigern Sie Network Egress standardmäßig. |
| Human Approvals | P0 | Irreversiblen oder regulierten Aktionen | Sichern Sie Writes, Deployments, Payments, externe Sends und privilegierte Änderungen durch Freigaben ab. |
| Scoped Credentials | P0 | Überdehnten Berechtigungen und Confused-Deputy-Fehlern | Verwenden Sie enge Scopes pro Server und pro Tool. |
| MCP-Server-Isolation | P1 | Tool Poisoning, Tool Shadowing und Cross-Server-Angriffen | Mischen Sie nicht ohne Review nicht vertrauenswürdige Server und leistungsstarke Tools in einem Context. |
| Audit Traces | P1 | Unbekannter Incident-Historie | Persistieren Sie User Request, Tool Call, Args, Result, Policy Decision und Approver. |
| Guardrails | P1 | Unsicherem Input- und Output-Text | Nützlich, aber nicht ausreichend für Tool Authority. |
| Red-Team-Evals | P1 | Bekannten Angriffswegen | Testen Sie Prompt Injection, Tool Poisoning, Data Exfiltration und Permission Bypasses. |
Was zuerst implementiert werden sollte
Entfernen Sie zuerst Capabilities. Wenn der Agent nicht auf GitHub schreiben muss, geben Sie ihm kein Write Token. Wenn er nur die Kalenderverfügbarkeit benötigt, gewähren Sie keinen vollständigen Mailbox-Zugriff. Eine eingeschränkte Berechtigung ist sicherer als ein strenger Prompt.
Prüfen Sie anschließend die Policy vor jedem Tool Call. Untersuchen Sie Tool Name, Arguments, Target Resource, User, Environment und Side Effect. Eine harmlos wirkende Anfrage kann dennoch einen gefährlichen Shell-Befehl erzeugen.
Fügen Sie Sandboxes für Code Execution, Browser Automation, File Access und die Verarbeitung nicht vertrauenswürdiger Dokumente hinzu. Eine Sandbox macht die Aktion nicht korrekt, reduziert aber den Schaden durch ein kompromittiertes Tool Result oder ein Confused Model.
Kontrollieren Sie den Data Flow ebenso wie die Execution. Beschränken Sie ausgehende Network Destinations, redigieren Sie Secrets aus Tool Results, trennen Sie nicht vertrauenswürdige Inhalte von Credentials und loggen Sie versuchte Egress-Aktionen. Eine Filesystem Sandbox, die weiterhin beliebigen Network Access erlaubt, lässt einen direkten Exfiltration Path offen.
Verwenden Sie Human Approval für irreversible Aktionen. Genehmigen Sie nicht jeden einzelnen Schritt. Genehmigen Sie Boundaries: Production Deployments, Data Deletion, Email Sends, Money Movement, Permission Changes und regulierte Entscheidungen.
MCP-spezifische Risiken
MCP ist nützlich, weil es den Tool Access standardisiert. Es ist riskant, weil Tool Descriptions, Schemas, Server Identities, OAuth Scopes und Tool Outputs allesamt Teil des Decision Context des Models werden.
Für MCP würde ich diese Regeln im Code Review fest verankern:
- Prüfen Sie Tool Descriptions und Schemas vor der Freigabe.
- Bevorzugen Sie enge Credentials pro Server.
- Isolieren Sie nicht vertrauenswürdige MCP-Server von sensiblen Tools.
- Achten Sie nach der Installation auf Änderungen an Tool Definitions.
- Behandeln Sie Tool Output als nicht vertrauenswürdigen Input.
- Loggen Sie jeden Server, jedes Tool, jedes Argument und jedes Result.
Guardrails reichen nicht aus
Guardrails können Input und Output validieren. Sie lösen weder Least Privilege noch Credential Scope, Sandboxing, Tool Poisoning oder Approval Policy. Behalten Sie sie bei, platzieren Sie sie aber nach dem Capability Design und vor dem User-visible Output.
Weiterführende Lektüre
- AI Agent Security ist der vollständige Architecture Guide.
- AI Agent Tool Use erklärt MCP, Tools, CLI, Skills und Code Execution.
- Long-Running AI Agent Runtime behandelt Runtime Boundaries für Long-Running Agents.