Tokenmaxxing ist Identitätsmanagement, kein Gateway

Tokenmaxxing gilt mittlerweile als eine der drängendsten Herausforderungen für Unternehmen geworden. Die Lösung besteht jedoch nicht darin, schlicht Gateways für das Routing einzuführen, sondern den Zugriff der KI-Agenten durch das Identitätsmanagement (IAM) auf die ausschließlich benötigten Funktionen im Sinne des Least Privilege-Ansatzes zu beschränken.

Gateways begrenzen die Token so detailliert, wie es ihre Daten zulassen. Das ist für das Routing richtig, allerdings macht die nachträgliche Begrenzung der Token das Gateway zur ‘Token-Polizei’. Hier wird das Limit für den Token-Gebrauch festgelegt und bei der Überschreitung der Grenzen einfach gestoppt. Das kann auf Dauer nicht funktionieren und führt nicht zum gewünschten Effekt.

Die andere Seite: MCP-Server gehören zu den am schnellsten wachsenden Lösungen, mit denen Unternehmen ihre KI-Agenten mit Tools und Daten verbinden. Dieses Wachstum lässt das Bedürfnis innerhalb von IT-Abteilungen wachsen, möglichst viele Komponenten per MCP anzubinden, um ein Maximum an Mehrwert durch KI gestützte Geschäftsabläufe zu erzeugen. Dies erhöht den Druck auf IT-Entscheider, bei der ordnungsgemäßen Bereitstellung dieser Tools Schritt zu halten. Jeder KI-Agent sollte auch nur eine Sichtbarkeit über diejenigen Tools haben, die für ihn freigegeben wurden. So können Sicherheitsrisiken wie Kosten reduziert werden.

Bezogen auf die Kosten, also den durch einen KI-Agenten produzierten Token-Verbrauch, bedeutet das, dass die Tool-Auswahl von vornherein eingeschränkt wird, noch bevor überhaupt mit der eigentlichen Arbeit begonnen wird. Ein einzelner beliebter MCP-Server kann Tausende aktiver Nutzer haben und jeder von ihnen zahlt bei jedem Schritt diese ‘Tool-Token-Steuer’. Die Schwierigkeiten mit der schieren Anzahl von Tools und Nutzern verstärken sich gegenseitig.

Das nachträgliche Ablehnen eines unbefugten Tool-Aufrufs, wie es bei Gateway-Lösungen der Fall ist, bringt die Kosten für diese Token nicht zurück. Sie wurden bereits in der Prompt-Phase verbraucht, noch bevor das Modell irgendetwas versucht hat. Außerdem: sobald ein KI-Agent ein Tool genutzt hat, auf das er keinen Zugriff haben sollte, ist die Rückabwicklung ein Thema für sich. Darüber hinaus muss das überhaupt erst jemand bemerken, untersuchen und den Zugriff widerrufen. Die Token bleiben unabhängig davon verbraucht.

Eine passende Blaupause für das sichere KI-Agenten-Unternehmen fasst die Herausforderung in drei einfachen Fragen zusammen, die als Orientierung dienen können:

• Wo befinden sich meine KI-Agenten?
• Was dürfen sie tun?
• Womit können sie sich verbinden?

Die Frage nach der Konnektivität bezieht sich dabei nicht ausschließlich auf die MCP-Server, die ein Agent erreichen kann, sondern auch auf die spezifischen Tools, die er für einen bestimmten Benutzer bedienen darf. Um hier die Kontrolle zu erlangen, empfiehlt es sich, auf das bekannte Least-Privilege-Prinzip samt Zero Trust als Konzept zu setzen.

Das schränkt die Rechte von Agenten ein und erlaubt ihnen nur den Zugriff auf autorisierte Tools in einem abgesteckten Bereich. Dadurch werden Token gespart und gleichzeitig die KI-Agenten sowie deren Bewegungsmuster festgelegt. Das Ziel: Viele wertvolle Token sparen, die KI-Agenten in definierte Bahnen lenken und die Geschäftsergebnisse, die aus dem Mehrwert des Agenten-Einsatzes entspringen sollen, sicherstellen.

Felix Colaci, Senior Solutions Engineer für Auth0 bei Okta

Okta