Sichere Tool-Entdeckung für Unternehmens-KI-Agenten: Register, Gateway und Richtlinien.
Ein Design für Agenten im Finanzdienstleistungsbereich: Ein Tool-Register, gefilterte Entdeckung, ein deterministisches Tool-Gateway, Autorisierung auf Intent-Ebene sowie dauerhafte Nebeneffekte.
Quellen: From Chatbots to Action-Bots: Designing Safe Tool Discovery and Authorization for Agentic AI
Die Frage hinter den Agenten-Tools
Geben Sie einem Agenten einige APIs, lassen Sie das Modell entscheiden, welche verwendet werden sollen – dann scheint der Zugriff auf Tools gelöst zu sein. Ein Unternehmen verändert jedoch das Bild: Dort enthält das Katalogsystem Hunderte oder Tausende von Tools. Einige sind harmlose, nur zum Lesen bestimmte Abfragen, andere können Kundendaten oder personenbezogene Informationen ändern, und eine kleinere Gruppe kann finanzielle Transaktionen starten, Konten umkonfigurieren oder administrative Operationen durchführen. „Wie findet der Agent das richtige Tool?“ ist die einfache Frage. Die schwierigere ist, wie man sicherstellen kann, dass der Agent nur die Tools sehen und verwenden kann, die für diese spezifische Benutzeranfrage erlaubt sind.
Das wird hier als Designstudie untersucht. Es handelt sich um eine durchdachte Architektur für den Bereich der Finanzdienstleistungen und sollte nicht als Bericht über ein bereits implementiertes Zahlungssystem verstanden werden.
Halten Sie das Modell außerhalb der Sicherheitsgrenze
Die Praxis des maschinellen Lernens lehrt eine wichtige Lektion: Der für das Geschäft entscheidende Prozess befindet sich nicht im Modell. Ein Modell kann vorhersagen, empfehlen oder klassifizieren, während Sicherheit, Validierung, Geschäftsregeln, Autorisierung und Transaktionsverarbeitung zu deterministischem Softwarecode außerhalb des Modells gehören. Agenten machen diese Regeln strenger und nicht lockerer, denn sie können Maßnahmen ergreifen. Ein großes Sprachmodell mag ein leistungsstarker Denker sein, ist aber dennoch oft keine gute Wahl für die Sicherheitsgrenzen eines Unternehmenssystems.
Ein einfaches Finanzszenario zeigt, warum. Ein Kunde bittet einen Agenten, sich eine kürzliche Transaktion anzusehen und zu bestimmen, ob ein Rückerstattungsvorgang abgewickelt wurde. Der Agent muss die Anfrage verstehen und Tools zur Suche nach Kunden sowie Transaktionen verwenden, was Routinearbeit ist.
Ändern Sie nun die Anfrage: Falls die Rückerstattung noch nicht abgewickelt wurde, leiten Sie sie aus. Der Agent sammelt nicht mehr nur Informationen, da dies finanzielle Folgen haben kann. Diese kleine Veränderung unterstreicht das Prinzip, auf dem alles andere beruht:
Der Agent kann über eine Aktion nachdenken und sie vorschlagen. Ob diese Aktion tatsächlich ausgeführt wird, entscheidet die deterministische Plattform.
Die Trennung zwischen Denken und Ausführen ermöglicht es einem System, die Stärken von LLMs zu nutzen, ohne auf sie angewiesen zu sein, wenn es um Aufgaben geht, die sie nicht zuverlässig erledigen können.
Ein Tool-Register anstelle einer riesigen Liste
Wie sollte der Agent erfahren, welche Tools vorhanden sind? Eine Möglichkeit besteht darin, dem Modell eine sehr lange Liste von Tool-Definitionen zur Verfügung zu stellen und es die Relevanz selbst ermitteln zu lassen. Das mag für ein Prototyp ausreichen, funktioniert aber nicht im Unternehmensumfeld. Tausende von Beschreibungen führen zu zusätzlichen Kosten hinsichtlich Kontext und Latenz, und eine unbegrenzte Suche erhöht ohne Nutzen das Sicherheitsrisiko.
Besser geeignet ist ein Tool Registry, ein Unternehmenskatalog mit Funktionen. Er enthält mehr als nur API-Names und -Schemata. Jeder Eintrag weist Metadaten auf, die die Plattform zur Suche, Steuerung sowie Entscheidungsfindung hinsichtlich Richtlinien nutzen kann:
- Business-Bereich, Eigentümer und Version
- Ob das Tool nur zum Lesen oder auch zum Schreiben geeignet ist
- Risikoklassifizierung und erforderliche Funktionalitäten
- Datenschutzklassifizierung
- Eingangs- und Ausgabeschemata
- Idempotenzmerkmale
- Auditing-Anforderungen
Die Metadaten sind am wichtigsten bei der Unterscheidung verschiedener Operationstypen. Eine Abfrage von Transaktionen ist eine eher risikoarme Leseoperation, ein Rückerstattungsvorgang ist eine stark einflussreiche Schreiboperation im Finanzbereich, und eine administrative Operation kann noch höheres Risiko mit sich bringen. Solche Unterschiede können nicht nur in der Dokumentation bleiben – sie müssen auf der Plattform vorhanden sein, damit eine deterministische Infrastruktur darauf reagieren kann.
Entdeckung ist keine Autorisierung
Das könnte der nützlichste Unterschied in der gesamten Konzeption sein: das Entdecken eines Tools und die Autorisierung, es zu verwenden, sind zwei verschiedene Dinge.
Die Entdeckung beantwortet die Frage, welche Tools diesem Agenten für diese Aufgabe zur Verfügung gestellt werden sollten. Die Autorisierung beantwortet die Frage, ob dieser spezifische Aufruf gerade erlaubt ist.
Die Metadaten des Registriersystems ermöglichen somit eine Filterstufe, die bereits vor dem Auswählen von Optionen durch das LLM stattfindet. Zunächst klärt die Plattform, wer der Benutzer ist, welcher Agent handelt, um welchen Tenant es geht, welcher Kontext vorliegt und was die Anfrage erreichen soll. Anschließend erstellt sie eine Liste von Tools, die zu diesem Zweck passen, und reduziert diese Liste anschließend unter Berücksichtigung der Fähigkeiten des Agents, der Berechtigungen des Benutzers, der Grenzen des Tenants, der Region sowie der Risikopolitiken. Das Modell sieht nur noch das, was übrig bleibt.
Auch dieser Filter kann nicht die letzte Verteidigungslinie sein. Das Modell könnte einen Aufruf tätigen, den niemand erwartet hat, die Absicht des Benutzers falsch interpretieren oder durch Prompt-Injection beeinflusst werden. Deshalb durchläuft jede Aufrufung auf dem Weg zur zugrunde liegenden Unternehmens-API ein kontrolliertes Tool Gateway.
Im Grunde prüft das Gateway eine Reihe von Fakten gemeinsam (wer der Benutzer ist, welcher Agent anruft, was angefordert wird, auf welcher Ressource, mit welchen Parametern, in welchem Kontext) und wendet die entsprechende Richtlinie an.
Die Absicht autorisieren, nicht nur das Tool
Das Beispiel mit der Rückerstattung zeigt einen weiteren Punkt: Die Autorisierung darf nicht allein davon abhängen, welches Tool verwendet wird. Sie muss auch die Absicht sowie die daraus resultierende Aktion berücksichtigen.
Die Überprüfung des Rückerstattungsstatus und das Starten einer Rückerstattung sind keine identischen Funktionen: Die eine ist eine Leseoperation, die andere hat finanzielle Auswirkungen. Die Plattform sollte sie explizit modellieren. Eine als Anfrage nach dem Rückerstattungsstatus klassifizierte Anfrage kann Tools zur Kunden- und Transaktionsabfrage erreichen, doch diese Klassifizierung gewährt nicht automatisch die Erlaubnis, die Rückerstattung durchzuführen. Selbst wenn das Modell fälschlicherweise entscheidet, dass eine Rückerstattung auszustellen ist, kann die Autorisierungsstufe die tatsächlich angeforderte Aktion mit der erlaubten Absicht vergleichen und sie ablehnen.
Der Sicherheitsansatz verschiebt sich hier von der Frage, ob ein Agent auf die Rückerstattungs-API zugreifen kann, zur Frage, ob dieser Benutzer, Agent, Zweck, Ressource und Aktion in diesem Kontext erlaubt sind.
Wenn ein Teil des Workflows fehlschlägt
Sobald eine Aktion erlaubt ist, taucht ein weiteres Problem auf: Was passiert, wenn ein Teil eines Workflows erfolgreich ist und ein anderer fehlschlägt? Angenommen, die Rückerstattung erfolgt, aber die Bestätigungs-E-Mail nicht. Das Neustarten des gesamten Agent-Workflows könnte die Rückerstattung zweimal ausführen.
Ein sichereres Muster macht den Nebeneffekt zu einem Schritt in einem dauerhaften Workflow. Die Autorisierung genehmigt die Rückerstattung, die Rückerstattungs-API wird ausgeführt und das Erfolgsergebnis wird gespeichert. Dieses gespeicherte Ergebnis sendet ein RefundCompleted-Event, das die Benachrichtigungen auslöst. Eine fehlgeschlagene E-Mail führt dann nur zu einem erneuten Versuch der Benachrichtigung, wobei die finanzielle Transaktion nicht wiederholt wird.
Das Vorhandensein eines LLM im System bedeutet nicht das Ende des klassischen Unternehmens-Toolkits. Wiederholte Versuche und Deduplizierung, Circuit Breaker sowie kompensierende Aktionen, idempotente Operationen, dauerhafte Zustände und ereignisgesteuertes Verarbeiten gelten weiterhin. Agenten können dazu beitragen, zu entscheiden, was geschehen soll, während deterministische Infrastrukturen die kritischen Zustandsänderungen verwalten.
Genehmigungen gehören zur Richtlinie
Das LLM sollte auch nicht entscheiden, wann ein Mensch etwas genehmigen muss. Das ist eine Richtlinienfrage. Eine Organisation kann Rückerstattungen unter einem bestimmten Schwellenwert automatisch zulassen und für Beträge darüber eine Genehmigung erforderlich machen, stets eine Genehmigung für administrative Vorgänge verlangen sowie Kontrollmechanismen für Transaktionen mit ungewöhnlichen Empfängern oder erhöhtem Risiko einbauen. Das Modell kann anzeigen, dass möglicherweise eine Aktion erforderlich ist. Das Richtliniensystem entscheidet, ob eine Genehmigung nötig ist, und die Tool Gateway setzt diese Entscheidung um. Auch die Governance profitiert davon, da die Regeln klar definiert, überprüfbar, versioniert und nachvollziehbar sind und nicht in einem Prompt versteckt sind.
Kontrollfläche und Ausführungsfläche
Nach Prüfung dieser Szenarien sieht das Design weitaus weniger wie ein einfacher Ablauf von Benutzer zu LLM zu Tools aus und eher wie eine Unternehmensgovernance-Plattform. Es teilt sich dabei natürlicherweise in zwei Bereiche auf.
Die Control Plane ist der Bereich, in dem die Organisation ihre Regeln festlegt. Sie umfasst den Agentenkatalog, das Tool Registry, Definitionen von Funktionalitäten, Risikoklassen, Autorisierungs- und Genehmigungsrichtlinien sowie allgemeine Verwaltungs-Einstellungen.
Die Execution Plane ist der Bereich, in dem die Abläufe tatsächlich ausgeführt werden. Sie enthält die Gateways für APIs und Agenten, die Agenten selbst, bereits gefilterte Erkennungsfunktionen, die Durchsetzung von Richtlinien, den Austausch von Zugangsdaten, die ausgeführten Tools, den Workflow-Zustand sowie den Strom der Prüfungsereignisse. Die Regeln können zentral verwaltet werden, während die Durchsetzung näher am Ort stattfindet, an dem die Arbeitslasten ausgeführt werden.
Diese Trennung ist im großen Maßstab von Bedeutung. Bei Hunderten oder Tausenden von Agenten sowie einer riesigen Anzahl an Tools möchte niemand, dass jede Autorisierungsprüfung auf einem einzigen zentralen Service wartet. Die Richtlinien werden an einem Ort verwaltet, während die Durchsetzungsstellen dezentral sind und die Richtliniendaten bei Bedarf gekachtet oder repliziert werden.
Auswertung von Aktionen, nicht nur von Antworten
Das Design passt gut zum Unternehmens-ML und fügt gleichzeitig eine neue Kategorie von Problemen hinzu. Traditionelles ML konzentriert sich auf Genauigkeit, Datenqualität, Drift, Latenz, Sicherheit, Überwachung und betriebliche Zuverlässigkeit. Die Agenten beinhalten all diese Aspekte und fügen zusätzlich die Auswertung von Aktionen hinzu.
Eine korrekte Endlösung reicht nicht aus. Die Prüfer müssen außerdem wissen, ob der Agent das richtige Werkzeug gewählt und die richtigen Parameter übergeben hat, sich innerhalb der Berechtigungsgrenzen gehalten hat, Aktionen vermieden hat, die ihm nicht gestattet waren, dem vorgesehenen Workflow gefolgt ist, bei Bedarf eine menschliche Genehmigung eingeholt hat und die erwarteten Nebenwirkungen hervorgerufen hat. Die Bewertung wandelt sich dabei von der Bewertung der Antworten zur Bewertung der Aktionen.
Das geltende Prinzip
Eine Regel bleibt immer wieder bestehen: Behandeln Sie den LLM als einen unzuverlässigen Entscheidungsbaustein und niemals als Sicherheitsgrenze. Der Agent kann argumentieren, relevante Fähigkeiten entdecken und Aktionen vorschlagen. Die deterministische Unternehmensinfrastruktur entscheidet darüber, was der Agent tun darf, welche Ressourcen er nutzen kann, welche Parameter zulässig sind, ob eine menschliche Genehmigung erforderlich ist, wie Nebenwirkungen sicher ablaufen sollen und wie der gesamte Prozess auditiert wird.
Das ist die eigentliche architektonische Herausforderung künstlicher Intelligenz mit Agentenfunktionen. Ein Agenten zu schaffen, der intelligent genug ist, ein Tool aufzurufen, ist der einfachere Teil. Eine Plattform, auf der Tausende von Agenten für Millionen von Nutzern agieren, wobei Identität, Autorisierung, Geschäftsregeln und betriebliche Zuverlässigkeit weiterhin unter Kontrolle bleiben, ist der schwierige Teil.