Ein AI-Agent wird sicherheitsrelevant, sobald er nicht nur Text erzeugt, sondern Werkzeuge aufruft. Lesen, Schreiben, Senden, Ausführen und Löschen sind unterschiedliche Befugnisse. Ein Modell darf diese Grenzen weder aus einem Prompt ableiten noch durch Inhalte in einem Dokument verändern können.
Das Modell ist kein Berechtigungssystem
Ein Sprachmodell kann eine Aktion vorschlagen. Die Anwendung entscheidet, ob sie zulässig ist. Nutzerrolle, Mandant, Projekt, Datenklasse und aktueller Prozesszustand werden außerhalb des Modells geprüft. Selbst eine perfekt formulierte Tool-Anfrage erhält keine zusätzlichen Rechte.
Ein häufiger Architekturfehler ist ein generisches Werkzeug wie execute_command oder call_api. Es verlagert die Sicherheitsentscheidung in frei erzeugten Text. Besser sind kleine Verträge wie search_documents, create_ticket_draft oder run_authorised_scan, die ein enges Eingabeschema und bekannte Seiteneffekte besitzen.
Jeder Werkzeugvertrag braucht Grenzen
Ein guter Vertrag beschreibt:
- erlaubte Parameter und Wertebereiche,
- notwendige Nutzer- und Systemrechte,
- erreichbare Datenquellen oder Ziele,
- maximale Laufzeit und Ergebnismenge,
- mögliche Seiteneffekte,
- protokollierte Ein- und Ausgaben,
- Fehler- und Wiederholungsverhalten.
Die Eingabe wird mit einem Schema validiert. Ziel-IDs und Mandanten werden serverseitig aufgelöst. Freie URLs, SQL oder Shell-Fragmente sind nur zulässig, wenn genau diese Freiheit erforderlich und zusätzlich isoliert ist.
Prompt Injection als Vertrauensgrenzenproblem
Ein Agent liest untrusted content. Webseiten, Tickets, E-Mails und Dokumente können Text enthalten, der wie eine Systemanweisung aussieht. Das Modell kann Inhalt und Befehl nicht zuverlässig anhand der Formulierung trennen.
Deshalb darf gelesener Inhalt keine Werkzeugrechte erweitern. Schutz entsteht durch:
- feste Berechtigungen außerhalb des Kontexts,
- Trennung von Daten und Instruktionen im Workflow,
- Filterung und Kennzeichnung externer Inhalte,
- Bestätigung riskanter Aktionen,
- Ausgabekontrolle vor einem Tool-Aufruf,
- minimale Datenrückgabe aus Werkzeugen.
Ein Prompt allein ist keine verlässliche Sicherheitsgrenze.
Freigaben nach Auswirkung staffeln
Nicht jede Aktion benötigt einen Menschen. Eine interne Suche darf automatisch laufen, wenn ihre Ergebnisse korrekt autorisiert werden. Eine E-Mail an einen Kunden, Änderung produktiver Daten oder aktiver Sicherheitstest benötigt dagegen häufig eine Freigabe.
| Wirkung | Beispiel | Kontrolle |
|---|---|---|
| nur lesen | erlaubte Wissenssuche | automatische Policy-Prüfung |
| reversibel schreiben | Ticketentwurf | Vorschau und Nutzerbestätigung |
| extern kommunizieren | E-Mail versenden | explizite Freigabe des finalen Inhalts |
| hohe Auswirkung | Deployment oder aktiver Scan | zusätzliche Rolle und Vier-Augen-Prinzip |
Die Freigabe zeigt konkrete Parameter und erwartete Wirkung. Ein allgemeines „Agent fortsetzen“ ist zu ungenau.
Budgets begrenzen technische und wirtschaftliche Schäden
Agenten können in Schleifen geraten, zu große Kontexte laden oder ein Werkzeug unnötig wiederholen. Jeder Lauf braucht Limits für Zeit, Token, Kosten, Tool-Aufrufe und gleichartige Wiederholungen. Wird ein Limit erreicht, endet der Lauf mit einem nachvollziehbaren Zwischenstand.
Für schreibende Werkzeuge sind Idempotenz-Schlüssel wichtig. Eine Wiederholung nach Timeout darf nicht zwei Rechnungen, Tickets oder Scans erzeugen. Circuit Breaker schützen externe Dienste, wenn deren Fehlerquote steigt.
Protokollierung ohne neues Datenleck
Für eine Untersuchung muss sichtbar sein, welches Modell welche Aktion mit welcher Policy vorgeschlagen hat. Gleichzeitig können vollständige Prompts Passwörter, Personendaten oder vertrauliche Dokumente enthalten. Logging braucht deshalb Datenminimierung, Maskierung, Zugriffskontrolle und Löschfristen.
Sinnvolle Auditdaten sind Lauf-ID, Nutzer- und Mandantenreferenz, Modellversion, Policy-Version, Werkzeugname, normalisierte Parameter, Entscheidung, Freigabe und Ergebnisstatus. Geheimnisse und vollständige Dokumente gehören in der Regel nicht hinein.
Evals für Missbrauchsfälle
Neben normalen Aufgaben braucht ein Agent Sicherheitsfälle: manipulierte Dokumente, unerlaubte Ziele, Rechtewechsel, wiederholte Tool-Antworten, Zeitüberschreitung und widersprüchliche Anweisungen. Erfolgreich ist nicht die kreativste Antwort, sondern der richtige kontrollierte Abbruch.
Ein Tool-Gate als ausführbare Policy
Vor jedem Aufruf bewertet die Anwendung eine strukturierte Anfrage. Das Modell liefert Parameter, aber niemals Identität, Mandant oder effektive Rechte:
{
"tool": "create_ticket_draft",
"actor_id": "usr_842",
"tenant_id": "tenant_17",
"arguments": {"project_id": "prj_9", "title": "..."},
"limits": {"calls_remaining": 4, "deadline_ms": 1500},
"required_approval": "before_external_send",
"policy_version": "agent-tools-12"
}
Das Gate prüft Schema, Beziehung von Actor, Tenant und Projekt, Datenklasse, Budget sowie Seiteneffekt. Es gibt allow, deny oder approval_required mit maschinenlesbarem Grund zurück. Diese Entscheidung wird unabhängig vom Prompt getestet. Ein manipulierter Dokumentinhalt muss denselben Deny-Fall erzeugen wie eine direkte unerlaubte Anfrage.
Die übergeordnete Produktionsarchitektur steht in Wie werden AI-Agenten produktionsreif?. Für sensible Datenwege ergänzt die Modellentscheidung zwischen lokal und Frontier das Routing.
Quellen und Vertiefung
- OWASP Top 10 for LLM Applications
- NIST AI Risk Management Framework
- MITRE ATLAS
- OWASP Authorization Cheat Sheet
Fazit
Ein sicherer Agent besitzt keine allgemeine Macht über ein System. Er arbeitet mit kleinen Werkzeugen, minimalen Rechten, messbaren Budgets und Freigaben an klaren Wirkungsgrenzen. Das Modell schlägt vor. Die Anwendung erzwingt die Regeln.