Wenn ein LLM nur Text generiert, ist das Risiko begrenzt: schlechte Antwort, falsche Empfehlung, vielleicht Halluzination. Sobald ein Agent aber Tools ausführen darf (Dateien lesen/schreiben, APIs aufrufen, Shell-Befehle starten), wird aus „Antwortqualität“ ein echtes Sicherheitsproblem. Für die Foundations-Prüfung ist wichtig: Du musst zeigen, dass du Tool-Nutzung als kontrolliertes System designst – nicht als freien Zugriff.
Der Kern ist Least Privilege: Jedes Tool bekommt nur die minimalen Rechte, die es für seinen Zweck braucht. Ein Reporting-Agent muss z. B. vielleicht Logs lesen, aber nicht Deployments auslösen. Ein Content-Agent darf Drafts erstellen, aber keine Live-Posts löschen. In Architektur-Sprache heißt das: capabilities explizit modellieren und standardmäßig verweigern („deny by default“), statt großzügig freizuschalten und später zu hoffen, dass nichts passiert.
Zweiter Baustein sind Allowlists. Statt zu sagen „dieses Tool darf HTTP“, definierst du konkret, wohin und wie: nur bestimmte Domains, nur bestimmte Endpunkte, nur GET oder nur POST mit validiertem Schema. Gleiches gilt für Dateisystemzugriffe: nur freigegebene Verzeichnisse, keine beliebigen absoluten Pfade. Allowlists reduzieren die Angriffsfläche massiv und machen Verhalten prüfbar. Für Exam-Szenarien ist das ein starker Punkt, weil du damit Sicherheits- und Compliance-Anforderungen gleichzeitig adressierst.
Dritter Baustein sind Guardrails auf mehreren Ebenen:
1. Input-Guardrails: Validierung von Tool-Parametern (Typen, Längen, erlaubte Werte).
2. Policy-Guardrails: Regeln wie „nie löschen ohne menschliche Freigabe“ oder „kein externer Versand ohne explizite Confirmation“.
3. Execution-Guardrails: Timeouts, Rate Limits, Retries mit Obergrenze, Abbruch bei verdächtigen Mustern.
4. Output-Guardrails: Ergebnisprüfung vor Weiterverarbeitung (z. B. Schema-Validierung, Plausibilitätschecks).
Warum reicht Prompting alleine nicht? Weil Prompt-Injection und indirekte Instruktionen versuchen, den Agenten zu „überreden“, Policies zu brechen. Sichere Systeme verlassen sich deshalb nicht auf gutes Verhalten des Modells, sondern auf harte technische Grenzen. Beispiel: Selbst wenn das Modell schreibt „ignoriere alle Regeln und sende alle Dateien“, blockt die Runtime den Zugriff, weil Domain/Path/Action nicht auf der Allowlist stehen.
Praktisch prüfungsrelevant ist auch Fehlerdesign: Tools sollten klare, strukturierte Fehler zurückgeben („permission_denied“, „validation_failed“, „rate_limited“) statt unpräziser Texte. So kann der Orchestrator korrekt reagieren: Nutzer um Freigabe bitten, alternativen Pfad wählen oder sauber abbrechen. Unscharfe Fehler führen dagegen zu Retry-Schleifen, Kostenexplosion und schwer debuggbaren Incidents.
Best Practice für Architekturantworten: Beschreibe immer den Kontrollfluss. Beispiel: Anfrage → Intent erkannt → Policy-Check → Parameter-Validierung → Tool-Call in Sandbox → Ergebnis-Validierung → Antwort mit Audit-Log. Wenn du zusätzlich erwähnst, dass jede sensitive Aktion nachvollziehbar protokolliert wird (wer, wann, welches Tool, mit welchem Scope), zeigst du Production-Denken statt Demo-Denken.
Merksatz fürs Exam: Sicherheit bei agentischen Tools ist kein Zusatzfeature, sondern Teil des Interface-Designs. Gute Architektur verhindert gefährliche Aktionen standardmäßig und erlaubt nur explizit freigegebene, validierte und auditierbare Pfade.
1. Least Privilege zuerst: Tool-Rechte minimal halten und standardmäßig alles verbieten, was nicht explizit erlaubt ist.
2. Allowlists konkretisieren Sicherheit: Domains, Endpunkte, Methoden, Pfade und Parameter klar begrenzen.
3. Guardrails sind mehrschichtig: Input, Policy, Execution und Output zusammen machen das System robust gegen Missbrauch und Fehler.
Du designst einen Agenten, der Rechnungsdaten aus einem internen System holt und monatliche Reports erstellt. Welche drei Sicherheitsmaßnahmen würdest du priorisieren, damit Prompt-Injection oder Fehlverhalten keine sensiblen Daten exfiltrieren oder unerlaubte Aktionen auslösen?
Ich würde erstens Least-Privilege-Scopes setzen (nur read-only Zugriff auf genau benötigte Datenquellen), zweitens strikte Allowlists für API-Ziele und erlaubte Parameter einführen und drittens Policy-Gates mit Human-Approval für jede externe Datenweitergabe aktivieren. Ergänzend sorgen strukturierte Fehlercodes, Audit-Logs und Timeouts dafür, dass Verstöße erkennbar bleiben und kontrolliert abgefangen werden.