Ein Agent erledigte seine erste Supportaufgabe korrekt und legte danach das eigentliche Sicherheitsproblem offen. Mit demselben Credential konnte er eine Bestellung lesen, erstatten, den Kunden ändern und den Datensatz löschen. Der Prompt verbot es. Für das System war dieser Satz trotzdem keine Sicherheitsgrenze.
Ein Agent mit breitem API Schlüssel ist kein Assistent mit gutem Urteil. Er ist eine Integration mit übermässiger Autorität und einem probabilistischen Controller.
Mit Fähigkeiten beginnen, nicht mit Konten
Die erste Frage lautet nicht, welches Mitarbeiterkonto der Agent nutzen soll. Benötigte Operationen werden einzeln aufgelistet. Bestellstatus lesen, eine interne Notiz ergänzen und eine Antwort entwerfen sind verschiedene Fähigkeiten. Antwort senden, Erstattung auslösen und Adresse ändern ebenfalls.
Diese Fähigkeiten werden als enge Tools mit typisierten Eingaben und klaren Ausgaben bereitgestellt. Ein Tool namens manage_order versteckt zu viel. Namen wie get_order_status, draft_support_note und request_refund_approval machen Autorität in Code und Logs sichtbar. Kennungen, erlaubte Zustände und Beträge werden ausserhalb des Modells validiert. Der Agent darf ein Tool wählen, aber nicht dessen Befugnis definieren.
Das Credential hinter dem Tool begrenzen
Ein wiederverwendbares Geheimnis gehört nie in den Modellkontext. Credentials leben in der serverseitigen Toolschicht und werden passend zur Operation gewählt. Getrennte Workflows erhalten getrennte Service Identities und, soweit unterstützt, kurzlebige Tokens. Audience, Ressourcen und Aktionen werden begrenzt.
Das ist gewöhnliches Least Privilege, keine AI Erfindung. Die aktuelle OAuth Sicherheitsempfehlung verlangt, Tokenrechte auf das notwendige Minimum zu reduzieren und an vorgesehene Ressourcen und Aktionen zu binden. Entscheidend ist die Durchsetzung durch den Resource Server, nicht das Versprechen im System Prompt.
Development, Test und Production dürfen keinen gemeinsamen Integrationsschlüssel nutzen. Rotation muss ohne Promptänderung und ohne Deployment anderer Agenten möglich sein.
Read-only ist der sinnvolle Standard
Der Anfang liegt bei Retrieval. Der Agent sammelt Kontext, klassifiziert Arbeit und schlägt eine Aktion vor, während ein Mensch oder deterministischer Dienst schreibt. Nicht jeder Write ist gefährlich. Read Pfade zeigen jedoch fehlende Daten, mehrdeutige Identitäten und unerwartete Randfälle, bevor diese Schwächen Geschäftszustand verändern.
Write Zugriff kommt Operation für Operation hinzu. Idempotente Änderungen mit engem Effekt können früher automatisiert werden. Unumkehrbare Aktionen, Geldbewegung, externe Kommunikation und Rechteänderung brauchen stärkere Schranken. Eine Freigabe muss an den konkreten Payload gebunden sein. Ein allgemeiner Approve Button mit danach neu erzeugter Aktion ist keine Freigabe dieser Aktion.
Ein Audit Trail muss das Warum beantworten
Jeder Tool Call protokolliert Agent Run, authentifizierten Principal, Toolname, validierte Argumente, Policy Entscheidung, Ergebnisreferenz und Zeitpunkt. Rohgeheimnisse und unnötige Personendaten bleiben draussen. Die Spur muss rekonstruieren können, was geändert wurde und auf welche Belege sich der Agent stützte.
Logs unterscheiden Modellvorschlag, Policy Ablehnung, menschliche Freigabe und ausgeführten Side Effect. Diese Trennung hilft im Vorfall und bei Evals. Das Team erkennt, ob ein Fehler aus Retrieval, Reasoning, Policy oder dem nachgelagerten System kam.
Diese Woche einen Workflow enger machen
Ausgewählt wird der Agent mit dem breitesten Credential. Alle vorhandenen Rechte werden mit den in erfolgreichen Läufen tatsächlich verwendeten Tools verglichen. Eine neue Service Identity erhält nur die Schnittmenge. Destruktive oder extern sichtbare Operationen brauchen klare Freigabe. Bei unklarer Policy fällt das System auf Retrieval zurück.
Danach werden verbotene Wege absichtlich getestet: Datensatz eines anderen Tenants, überhöhter Betrag, wiederholte Anfrage, abgelaufenes Token und Tool Call mit unbekanntem Feld. Ein sicherer Agent ist nicht einer, der nie eine falsche Aktion verlangt. Sicher ist das umgebende System, wenn es diese Aktion sauber ablehnt, die Ablehnung festhält und gefahrlos weiterläuft.