Jeder Modellaufruf eines KI-Agenten enthält ein Menü aller Werkzeuge, die er verwenden könnte. Sogar diejenigen, die es niemals berühren wird.
Dies gilt unabhängig davon, ob der Agent eine Verbindung zu Google Workspace, Slack oder einem internen MCP-Server herstellt, an den im Laufe mehrerer Jahre hundert Tools angebunden wurden. Jedes Tool, das ein MCP-Server bereitstellt, wird als Schema, Name, Beschreibung und Parameter in den Prompt des Modells eingefügt, und dies geschieht bei jedem einzelnen Durchlauf. Sie müssen dafür bezahlen, dass das Modell dieses Tool evaluiert, unabhängig davon, ob es dieses jemals aufruft.
Wir nennen dies die Tool-Steuer. Und es war für die meisten KI-Teams unsichtbar, da es nicht als abgelehnter Anruf oder Sicherheitsvorfall erscheint. Es taucht als Token-Rechnung auf, die schwerer zu erklären ist, als sie sein sollte.
KI-Agenten sind nur so leistungsfähig wie das, womit sie verbunden sind
MCP-Server sind eine der am schnellsten wachsenden Methoden, mit denen Unternehmen Agenten mit Tools und Daten verbinden. Dieses Wachstum hat in der IT einen „Wir müssen alles mit allem verbinden“-Druck erzeugt. Teams stellen mehr MCP-Server schneller bereit, als sie diese verwalten können, was sowohl zu einem Sicherheitsrisiko als auch zu einem Kostenproblem führt.
Mehr bereitgestellte Tools pro Server bedeuten, dass pro Entscheidung des Agenten mehr Tokens allein für die Tool-Auswahl verbraucht werden, bevor die eigentliche Arbeit überhaupt beginnt. Ein einzelner beliebter MCP-Server kann Tausende aktive Nutzer haben, und jeder von ihnen zahlt bei jedem Schritt die Tool-Steuer. Das Problem der Anzahl der Tools und das Problem der Anzahl der Nutzer verstärken sich.
Das nachträgliche Ablehnen eines nicht autorisierten Tool-Aufrufs bringt diese Tokens nicht zurück. Sie waren bereits in der Prompt-Phase aufgebraucht, bevor das Modell irgendetwas unternahm. Und sobald ein Agent ein Tool verwendet hat, auf das er keinen Zugriff haben sollte, ist es ein eigenes Projekt, dies rückgängig zu machen: Jemand muss dies bemerken, untersuchen und den Zugriff widerrufen. Die Token bleiben trotzdem verfallen.
Scoping im Vorfeld bedeutet, dass es gar nicht erst etwas zurückzunehmen gibt.
Oktas Blueprint stellt eine spezifischere Version der Frage „Womit können sie sich verbinden?“
Die Blaupause für das sichere agentenbasierte Unternehmen fordert jedes Unternehmen, das KI-Agenten einsetzt, dazu auf, drei Fragen zu beantworten: Wo befinden sich meine Agenten, womit können sie sich verbinden und was können sie tun?
Diese Fähigkeit ist das direkte Ergebnis der zweiten Frage, die detaillierter beantwortet wird, als die meisten Teams zu prüfen bedenken. „Womit können sie sich verbinden“ bezieht sich nicht nur auf die MCP-Server, die ein Agent erreichen kann, sondern auch auf die spezifischen Tools, die dieser Agent für eine:n bestimmte:n Benutzer:in verwenden darf.
Zugriff mit minimalen Rechten bedeutet, dass ein Agent niemals Kenntnis von Ressourcen, Datenbanken oder Tools haben sollte, für deren Nutzung er nicht explizit autorisiert ist. Die Beseitigung nicht autorisierter Tools zur Absicherung des Unternehmens senkt zudem die Tool-Kosten.
So funktioniert's
Okta grenzt die Tool-Liste an dem Punkt ein, an dem sich ein Agent mit einem MCP-Server verbindet. Im Okta-Dashboard konfiguriert ein Administrator, welche Tools eine bestimmte Identität nutzen darf. Okta gibt dann nur die eingegrenzte Menge zurück und nicht alles, was der Server bereitstellt.
Bei jeder Interaktion wird eine kürzere Liste in den Prompt des Agenten eingefügt, was einen geringeren Token-Verbrauch pro Interaktion bedeutet, bevor der Agent überhaupt einen Aufruf versucht. Nicht autorisierte Tools sind nicht in der Liste enthalten, die das Modell sieht, und der Berechtigungsbereich wird zur Laufzeit erneut geprüft, bevor ein Tool-Aufruf ausgeführt wird.
Was das wert ist
Durch das Scoping der Tool-Liste auf das, worauf die Identität eines Agenten tatsächlich zugreifen darf, wird der Großteil des Katalogs entfernt, bevor er das Modell überhaupt erreicht. Bei internen Modellierungen über eine realistische Mischung von Berechtigungsstufen hinweg reduzierten einige Szenarien die sichtbaren Tools um mehr als 90 %. Die Kosten für das Tool-Schema, der Teil der Rechnung, der mit der Beschreibung von Tools im Prompt verbunden ist, sinken in etwa gleichem Maße.*
Warum dies ein Identitäts- und Autorisierungsproblem ist, kein Gateway-Problem
Gateways begrenzen die Ausgaben nach Schlüssel, Team oder Gruppe in der feinsten Granularität, die ihre Daten erlauben. Das ist eine echte Funktion, und für Routing und Rate-Limiting ist es die richtige Ebene, um dafür zuständig zu sein. Aber die Ausgaben im Nachhinein zu deckeln, macht die Person, die das Gateway besitzt, fast schon automatisch zur Token-Polizei: Jemand muss die Limits festlegen, sie verteidigen, wenn ein Team Einwände erhebt, und den Anruf entgegennehmen, wenn ein Benutzer mitten in der Aufgabe nicht weiterkommt. Das ist kein Fehler des Gateways. Das passiert, wenn der einzige Hebel eine Ausgabenobergrenze anstelle des Berechtigungsumfangs ist.
Gateways erfassen, was bereits geschehen ist: eingehende Tokens, ausgehende Tokens, ausgegebene Dollar. Sie können den Schaden begrenzen, nachdem eine Entscheidung teuer geworden ist. Sie können von vornherein nicht verhindern, dass die Entscheidung teuer wird, da Informationen auf Gruppenebene keinen Aufschluss darüber geben, worauf ein bestimmter Agent oder die Person hinter diesem Agenten tatsächlich zugreifen darf.
Die Identity-Ebene kann. Mit Berechtigungen pro Benutzer und pro Agent anstelle von Gruppenmitgliedschaften filtert Okta eine Toolliste mit einer Detailgenauigkeit, auf die Gateways keinen Zugriff haben. Das Gateway misst, was durchkommt. Die Identity-Ebene reduziert das, was gemessen werden muss, sodass weniger zu überwachen bleibt.
„Die Kostenkontrolle für Agenten wird am besten durch Identity-Governance-Tools erreicht, die eine granularere Kontrolle und Präzision bieten, ohne Geschäftsprozesse zu stören.“ Der Ansatz von Okta ist eine elegante Lösung, da er dieselben Berechtigungsdaten nutzt, die auch die Sicherheit steuern, und keine separate Messschicht ohne diese Einblicke,“ sagt Paul Webber, Principal Cybersecurity Industry Analyst bei Software Analyst Cyber Research.
Der wichtigere Punkt
Die Kosten sind nur ein Teil davon. Wenn einer Identität Tools entzogen werden, für deren Nutzung sie nicht autorisiert ist, entfallen auch die Möglichkeiten, die diese Identität im Falle einer Kompromittierung hätte. Dasselbe Abgrenzungskonzept, das den Prompt schlank hält, hält den Schadensradius klein.
Das Least-Privilege-MCP reduziert sowohl die Token, die ein Modell verarbeiten muss, als auch den Schaden, den ein Angreifer mit den verbleibenden Werkzeugen anrichten könnte.
Wie geht es weiter? Nutzen Sie unseren KI-Simulator, um reale Angriffsszenarien durchzuführen, Ihre Abdeckung zu bewerten, Sicherheitslücken aufzudecken und zu verstehen, wie verschiedene Kontrollen das Risiko und den Wirkungsradius verringern können.
*Methodik. Die Reduktionszahlen in diesem Beitrag stammen aus internen Modellierungen von Okta unter ausschließlicher Verwendung von Okta-Produktdaten und öffentlicher Anbieterdokumentation. Es wurden keine Kundendaten verwendet. Wir modellierten einen einzelnen MCP-Client mit Zugriff auf einen Katalog von Unternehmenstools und verglichen anschließend die Anzahl der für das Modell sichtbaren Tools vor und nach dem identitätsbasierten Scoping. Die Reduzierung der Tool-Anzahl wird berechnet als eins minus das Verhältnis von Tools im Geltungsbereich zu Tools außerhalb des Geltungsbereichs. Um die bereichsbezogene Gefährdung abzuschätzen, haben wir die Okta MCP Server-Tools den OAuth-Scopes zugeordnet, die sie freischalten, repräsentative Benutzersegmente definiert (Helpdesk schreibgeschützt, Helpdesk-Operator, App-Administrator:in, Marken- und E-Mail-Administrator:in und Super-Administrator:in) und jedes Segment nach einem angenommenen Anteil am monatlichen Datenverkehr gewichtet. Die Token-Kosten für das Tool-Schema verhalten sich nahezu linear zur Anzahl der Tools, da jedes Tool bei jedem Durchgang einen Namen, eine Beschreibung und ein Parameter-Schema zum Prompt beisteuert. Daher folgen prozentuale Reduzierungen der Schema-Kosten eng den prozentualen Reduzierungen der Tool-Anzahl. Absolute token- und Dollarbeträge hängen von der durchschnittlichen Schemagröße, dem Anfragevolumen und den Modellpreisen ab. Da all diese Faktoren je nach Bereitstellung variieren, werden die Reduzierungen in diesem Beitrag als Prozentsätze und nicht in Dollar angegeben. Die tatsächlichen Ergebnisse variieren je nach Ihrem Tool-Katalog, der Berechtigungsverteilung und der Modellauswahl.
