Governance der Tool-Nutzung von Agenten in Finanzworkflows

Ein Agent, der Tools aufrufen kann, kann Geld bewegen, und die Autorisierungsschicht entscheidet, ob er es darf. Bevor ein Agent ein Finanzsystem berührt, setzen wir rund um jedes Tool vier Dinge voraus: eine eng gefasste Identität, die sowohl den Agenten als auch die Person benennt, für die er handelt; eine Policy-Prüfung, die auf dem Tool-Server läuft und nicht im Prompt; Limits pro Aktion und pro Zeitfenster; und einen Append-only-Datensatz jedes einzelnen Versuchs.

Das Modell schlägt vor, die Tool-Schicht entscheidet. Der Fehler, den sich alle vorstellen, ist das Modell, das etwas Falsches sagt. Der Fehler, der tatsächlich teuer wird, ist das Modell, das ein korrekt aussehendes transfers.create mit der falschen Gegenpartei absetzt oder eine Zahlung dreimal wiederholt, weil ein Timeout wie ein Fehlschlag aussah. Ein Sprachmodell ist ein Generator plausibler nächster Schritte, und eine Payment-API tut genau das, was ihr gesagt wird. Nichts im Transformer weiß, dass genau dieser POST zum Quartalsende ein Betriebskonto leerräumt. Die Governance kann also nicht im Reasoning selbst liegen. Sie muss auf der Leitung zwischen dem Agenten und dem System of Record sitzen.

Identität und Least Privilege an der Tool-Grenze

Fangen Sie damit an, dem Agenten die vollen Berechtigungen eines Menschen zu verweigern. Ein Support-Agent, der die Transaktionshistorie eines Kunden liest, braucht nicht den Scope, der eine Rückerstattung anstößt, und keiner von beiden braucht den Scope, der einen Begünstigten ändert. Modellieren Sie jedes Tool als eigene Berechtigung, nicht jedes System.

Wir geben dem Agenten eine eigene Service-Identität und übergeben den handelnden Nutzer als separaten Principal bei jeder Anfrage. Der Tool-Server bildet dann die Schnittmenge aus zwei Dingen: was diese Agentenklasse überhaupt tun darf und was dieser konkrete Nutzer berechtigt ist zu tun. Ein Rückerstattungs-Tool, das ein Nutzer von Hand aufrufen könnte, wird für den Agenten nur innerhalb dieser Schnittmenge aufrufbar. Das behebt auch das Confused-Deputy-Problem, bei dem der Agent weitreichende Credentials hält und ein manipulierter Prompt sie sich ausleiht. Ist der eigene Scope des Agenten eng, hat ein gekaperter Prompt wenig zu leihen.

Konkret bedeutet Least Privilege hier:

• Ein Credential pro Tool-Surface, kurzlebig ausgestellt, niemals ein geteilter Plattform-Key.
• Scopes als Verben auf Ressourcen ausgedrückt (invoices.read, payments.initiate_below_1000), nicht als grobe Rollen wie finance_admin.
• Lese- und Schreibzugriff in verschiedene Tools aufgeteilt, selbst wenn dieselbe API beides bedient, damit ein reiner Lese-Workflow niemals versehentlich Schreibrechte erhält.
• Berechtigungsprüfungen gegen denselben Authorization Service aufgelöst, den auch Ihre menschlichen Nutzer treffen, sodass es eine Single Source of Truth und einen Ort zum Entziehen gibt.

Validieren Sie die Aktion, nicht den Satz

Der Tool-Call des Agenten ist eine Behauptung, und Sie sollten ihn so behandeln wie jeden Client-Input: nicht vertrauenswürdig, bis der Server seine Ungefährlichkeit beweist. Die Validierung gehört auf den Tool-Server oder einen vorgelagerten Proxy, denn das ist der einzige Ort, den eine Prompt Injection nicht erreichen kann.

Bei einer Zahlungs- oder Ledger-Aktion prüfen wir serverseitig, bevor irgendetwas ausgeführt wird:

• Schema- und Typkorrektheit, einschließlich der Frage, ob der Betrag positiv ist, in der Währung, die das Konto tatsächlich hält, und innerhalb der Präzision, die das Ledger verwendet.
• Geschäftsinvarianten, für die das Modell keine verlässliche Sicht hat: Die Gegenpartei existiert und steht nicht auf einer Sanktions- oder internen Sperrliste, das Quellkonto hat gedecktes Guthaben, die Aktion durchbricht keine Freigabeschwelle, die einen Menschen erfordert.
• Point-in-time-Korrektheit jeder Zahl, die der Agent berechnet hat. Hat der Agent ein Exposure summiert, um eine Limiterhöhung zu begründen, berechnen Sie es zum Entscheidungszeitpunkt aus dem Feature Store neu, statt der Zahl im Prompt zu vertrauen.
• Idempotenz. Jeder mutierende Call trägt einen client-generierten Key, sodass ein Retry, ein duplizierter Plan-Schritt oder ein Netzwerk-Timeout, den der Agent als Fehlschlag fehldeutet, nicht doppelt ausführen kann. Straight-through processing ohne Idempotency Key ist der Weg, wie aus einer Anweisung zwei Zahlungen werden.

Alles oberhalb eines konfigurierten Werts wird an einen menschlichen Freigeber weitergeleitet, statt ausgeführt zu werden. Die Schwelle ist Policy, versioniert am selben Ort wie die Scopes, sodass ihr Absenken während eines Incidents eine Config-Änderung ist und kein Code-Deploy.

Rate Limits, Budgets und der Audit-Trail

Die Autorisierung sagt Ihnen, ob eine einzelne Aktion erlaubt ist. Das Rate Limiting sagt Ihnen, ob das Muster der Aktionen vernünftig ist. Ein Agent, der in einer Schleife feststeckt, ist im klassischen Sinne kein Sicherheitsvorfall, aber er wird bereitwillig payments.initiate vierzigmal in einer Minute aufrufen, wenn eine Retry-Policy falsch ist und nichts ihn stoppt.

Wir setzen Obergrenzen auf Frequenz und kumulierten Wert. Ein Tool bekommt ein Aufruflimit pro Minute, und ein mutierendes Tool bekommt zusätzlich ein rollierendes Geldbudget: nicht mehr als N Transfers oder X Gesamtwert pro Stunde für diese Agenten-Identität, unabhängig davon, ob jeder einzelne die Autorisierung besteht. Das Durchbrechen eines Budgets versetzt den Agenten in einen Degraded Mode, in dem er lesen und entwerfen kann, aber jeden Schreibvorgang an einen Menschen übergeben muss. Das ist dieselbe False-positive-Budget-Logik, die Sie bereits im Transaction Monitoring fahren, angewendet auf den Agenten selbst als Akteur.

Der darunterliegende Datensatz ist nicht optional. Jeder Tool-Call, ob erlaubt oder abgelehnt, schreibt ein Append-only-Event: die Agenten-Identität, den handelnden Principal, den aufgelösten Scope, die exakten Argumente nach der Validierung, die Entscheidung und die Policy-Version, die sie getroffen hat. Das gibt Ihnen Lineage von einem Ledger-Eintrag zurück zum konkreten Agent-Run und dem Prompt, der ihn ausgelöst hat. Wenn ein Controller fragt, warum am letzten Tag des Quartals um 2 Uhr nachts eine Zahlung rausging, ist die Antwort eine Query, keine Untersuchung. Es ist außerdem das, was Drift sichtbar macht: Steigt die Deny-Rate auf einem Tool Woche für Woche, hat entweder das Modell sein Verhalten geändert oder jemand sondiert es, und beides sind Dinge, die Sie sehen wollen, bevor die Reconciliation es tut.