Warum das Agent-Gateway nicht die erste Schutzschicht für KI-Agenten sein sollte

Nik Kale, Spezialist für Plattformen für Unternehmens-KI und Sicherheit, ist der Ansicht, dass viele Unternehmen mit dem Agenten-Laufzeit-Gateway als zentralem Kontrollpunkt beginnen, obwohl diese Gateways auf Identitäts- und Zuordnungsschichten angewiesen sind, die nicht vorhanden oder nicht ausgereift genug sind. Das Ergebnis ist, dass das Gateway zwar die Gültigkeit des Tokens und die Anfrage an die Anwendungsprogrammierschnittstelle überprüfen kann, aber nicht immer weiß, welcher Agent die Anfrage ausgeführt hat, wer ihn autorisiert hat, welche Aufgabe er erledigt hat oder ob die Anfrage Teil einer Tool-Kette war, die von einer nicht vertrauenswürdigen Komponente gestartet wurde.

Dieses Problem gewinnt mit der zunehmenden Verbreitung von Agenten praktische Bedeutung. Im Juni nahm die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) eine Schwachstelle in LiteLLM in ihren Katalog bekannter, ausgenutzter Schwachstellen auf, nachdem ihre tatsächliche Ausnutzung beobachtet worden war. Die Schwachstelle ermöglichte die Ausführung von Befehlen auf dem Host über das Gateway selbst; in Kombination mit einer zweiten Schwachstelle konnte sie zudem ohne Zugangsdaten ausgenutzt werden. Der Quelle zufolge wurden innerhalb eines Monats sieben Common Vulnerabilities and Exposures (CVEs) im Gateway offengelegt.

Sicherheit ist hier eine Vertrauenskette, kein einzelner Kontrollpunkt

Kale schlägt vor, was er „vertrauensgesteuerte Bereitstellung“ nennt. Demnach sollte keine nachgelagerte Schicht als operativ vollständig gelten, bevor die erforderlichen Prüfungen der vorgelagerten Schichten bestanden wurden. Die Kontrollen können parallel entwickelt werden, ihre Aktivierung in der Produktion sollte jedoch einer klaren Reihenfolge folgen:

• Bestandsaufnahme der Agenten und verantwortliche Eigentümerschaft: Jeder Produktionsagent sollte einen bekannten Eigentümer, einen bestimmten Zweck, genehmigte Tools und einen Status innerhalb seines Lebenszyklus haben.
• Unabhängige Identität und Autorisierungskontext: Das System sollte den Agenten, seinen Eigentümer sowie den Benutzer oder die Stelle kennen, in deren Namen der Agent die Arbeit ausführt.
• Kurzlebige, aufgabenspezifische Zugangsdaten: Ein kompromittierter Agent darf nicht auf Ressourcen zugreifen können, die nicht mit der ihm zugewiesenen Aufgabe verbunden sind.
• Zuordenbare Messbarkeit: Die Aufgabe sollte von ihrem Beginn bis zu ihren endgültigen Auswirkungen auf andere Systeme rekonstruiert werden können.
• Durchsetzung von Laufzeitmaßnahmen: Richtlinienentscheidungen sollten auf der Identität des Agenten, der autorisierenden Stelle, der Aufgabe und der Aktion beruhen, nicht allein auf der Gültigkeit des Tokens.
• Verhaltensbaselining und systemübergreifender Abschaltpfad: Sicherheitsteams sollten in der Lage sein, die tatsächliche Berechtigung des Agenten an allen Orten zu entziehen, auf die er zugreift.

Beginnen Sie mit dem, was definiert und zugeordnet werden kann

Der erste Schritt des vorgeschlagenen Rahmens besteht darin, die vorhandenen Produktionsagenten innerhalb von Open-Source-Frameworks, Cloud-Diensten, Software-as-a-Service-Produkten und Entwicklerwerkzeugen zu erfassen. Das Register umfasst den Eigentümer des Agenten, seine Verantwortlichkeit, die Phase seines Lebenszyklus, die zulässigen Tools, die Datenbereiche und die Quellen der Zugangsdaten. Das Fehlen dieser Bestandsaufnahme ist nicht nur ein Dokumentationsproblem; ein Teil der Zeit bei der Reaktion auf Vorfälle kann dadurch für den Versuch verloren gehen, die Herkunft zu bestimmen, die das Unternehmen eigentlich im Voraus kennen sollte.

Der Autor betont, dass die Identität des Agenten nicht in Entwicklercode, einem gemeinsam genutzten Dienstkonto oder einer Benutzersitzung verborgen werden sollte. Zu wissen, dass der Aufrufer ein „Agent“ ist, reicht nicht aus. Zusätzlich müssen der Auftraggeber der Arbeit, die konkrete Aufgabe und die Ressourcen erfasst werden, die der Agent verwenden muss. Die Identität bestimmt den Akteur, während die Autorisierung verdeutlicht, in wessen Auftrag der Agent handelt und aus welchem Grund ihm diese Befugnis erteilt wurde.

Beschränken Sie Berechtigungen vor der Verhaltensanalyse

Nach der Identifizierung des Agenten sollten seine Fähigkeiten zeitlich sowie nach den dafür erforderlichen Aufgaben, Tools und Ressourcen eingeschränkt werden. Die Quelle weist darauf hin, dass vorhandene Funktionen in Identity-and-Access-Management-Systemen (IAM) genutzt werden können, etwa Workload-Identitäten, Token-Austausch, bedingter Zugriff und zeitlich begrenzte Berechtigungen.

Kale verweist auf eine Studie von Teleport aus dem Jahr 2026 mit 205 Sicherheitsverantwortlichen. Unternehmen, die eine übermäßig privilegierte künstliche Intelligenz einsetzten, meldeten demnach eine Vorfallrate von 76 %, gegenüber 17 % bei Unternehmen, die das Prinzip der geringsten Berechtigung anwendeten. Seiner Analyse zufolge deutet dies darauf hin, dass der Zugriffsbereich in der Vertrauenskette ein früherer Faktor sein kann als die Durchsetzung kontextbezogener Laufzeitrichtlinien.

Das vom Autor formulierte Prinzip lautet „monotone Autorisierung“: Jeder Übergang der Verantwortung muss die Befugnisse bewahren oder verringern; sie dürfen nicht erweitert werden. Beim Beispiel eines Agenten für den Zahlungsabgleich bedeutet dies, ihm die Berechtigung zum Anzeigen eines bestimmten Hauptbuchs zu erteilen, statt ihm alle Systeme zu vererben, auf die der anfragende Mitarbeiter zugreifen kann.

Wann wird das Gateway tatsächlich nützlich?

Ein Laufzeit-Gateway schöpft seinen vollständigen Wert erst aus, wenn eine registrierte Identität des Agenten, ein ausdrücklicher Autorisierungskontext, spezifische Zugangsdaten und zuordenbare Protokolle vorhanden sind. Dann kann es bewerten, ob der Agent berechtigt ist, eine bestimmte Aktion für eine bestimmte Stelle, im Rahmen einer bestimmten Aufgabe und auf einer bestimmten Ressource auszuführen. Das Benutzertoken kann gültig sein, um dem Abgleichsagenten Schreibberechtigungen zu erteilen; der vollständige Kontext kann jedoch zeigen, dass die Aktion außerhalb des Aufgabenbereichs liegt.

Die strengsten Kontrollen sollten auf Grenzen gerichtet werden, deren Auswirkungen sich nur schwer rückgängig machen lassen, etwa Zahlungen, Änderungen an Zugriffsrichtlinien, Löschungen, Änderungen an Produktionsumgebungen und Datenexporte. Verhaltensbaselines kommen später, nachdem die Aktivitäten des Agenten unterscheidbar und zuordenbar geworden sind; dann können ungewöhnliche Tool-Nutzung, unerwarteter Zugriff zwischen Datenbereichen oder Abweichungen von der Aufgabe erkannt werden.

Der Abschaltpfad beschränkt sich nicht auf die Deaktivierung eines einzelnen Objekts im Identitätsverzeichnis. Eine vollständige Abschaltung erfordert der Quelle zufolge die Deaktivierung der Agentenidentität, den Widerruf aktiver und abgeleiteter Zugangsdaten, die Verhinderung der Tool-Ausführung, die Beendigung laufender Aufgaben und die Isolierung der Workload, die den Agenten enthält.

Ein Testplan für 30 Tage

Der Autor schlägt nicht vor, das bestehende Identitätsmanagementprogramm zu ersetzen. Wenn der Identitätsanbieter Agenten nicht als native Ressourcentypen behandelt, kann mit einem verlässlichen Register begonnen werden, das mit den vorhandenen Workload-Identitäten verknüpft ist. Anschließend können Agenten- und Aufgabenkennungen als vertrauenswürdige Ausführungskontexte ergänzt, kurzlebige Zugangsdaten verwendet und diese Kennungen in den Protokollen der Tool-Aufrufe erfasst werden.

In der Praxis schlägt er vor, mit zehn Produktionsagenten zu beginnen und für jeden dessen Eigentümer, Zweck, Tools und Zugangsdaten zu dokumentieren. Danach sollte geprüft werden, ob die Identitäts- und Protokollierungssysteme den Agenten von dem Menschen oder Dienst unterscheiden, der die Aufgabe autorisiert hat. Anschließend sollte eine vollständige Aufgabe von Anfang bis Ende rekonstruiert werden, einschließlich ihrer nachgelagerten Auswirkungen. Die Stelle, an der die Kette unterbrochen ist, zeigt die Lücke auf, die vor der Einführung einer weiteren Laufzeitdurchsetzung behoben werden sollte.

Redaktionelle Einordnung: Der Wert dieses Rahmens liegt nicht im Vorschlag eines neuen Gateways, sondern in der Neuanordnung des Ausgangspunkts. Die genannten Fakten zu LiteLLM sowie die Zahlen von Teleport und Okta unterstreichen die Bedeutung der Berechtigungsbeschränkung und der Zuordnung; sie beweisen jedoch allein nicht, dass die vorgeschlagene Reihenfolge der Schichten die einzige Lösung ist oder für jede Unternehmensarchitektur geeignet wäre. Außerdem handelt es sich bei dem Material um eine Analyse des Autors und nicht um einen offiziellen Standard. Daher muss seine Anwendung an die Details der in jedem Unternehmen vorhandenen Identitäts-, Protokollierungs- und Abschaltpfade angepasst werden.