Axonius fügt seiner Cybersecurity-SaaS-Plattform KI-Agenten hinzu, ohne das kundenweise Isolationsmodell aufzugeben, das seiner bestehenden AWS-Bereitstellung zugrunde liegt, wie eine neue Fallstudie im AWS Machine Learning Blog berichtet.

Das Unternehmen nutzte Amazon Bedrock AgentCore, um Agenten für Hunderte separater Kundenumgebungen auszuführen. Das Design adressiert ein zentrales Problem für Softwareanbieter, die agentische Funktionen hinzufügen: Ein Agent muss über viele Mandanten hinweg nützlich sein und gleichzeitig auf die Daten, APIs, Identitätskontrollen und Betriebskosten des jeweiligen Kunden beschränkt bleiben.

AWS beschreibt die Architektur und die gemeldeten Vorteile in einem Beitrag des Anbieters selbst. Die Quelle liefert keine unabhängigen Leistungstests oder Kundenkommentare von Axonius, daher sollten Behauptungen über Bereitstellungsumfang und operative Ergebnisse als von AWS berichtet betrachtet werden.

Axonius behält sein silo-basiertes SaaS-Modell bei

Axonius bietet eine Asset-Intelligence-Plattform für Sicherheits- und IT-Teams. AWS zufolge gleicht der Dienst Informationen aus mehr als 1.400 Systemen ab und betreibt Hunderte isolierter Kundenumgebungen. Jede Kunden-Workload läuft in einer dedizierten Amazon Virtual Private Cloud, oder Amazon VPC, die Komponenten wie Load Balancer, Datenbanken und allgemeine Compute-Infrastruktur enthält.

Der im Beitrag beschriebene erste KI-Agent analysiert große Unternehmensumgebungen, identifiziert Lücken und Risiken und interpretiert Millionen von Datenpunkten, die aus mehreren Integrationen eintreffen. AWS sagt, die Funktion solle jüngeren Analysten ermöglichen, komplexe Analysen durchzuführen, ohne dass Senior-Analysten stundenlang manuelle Untersuchungen durchführen müssen.

Anstatt diese Workload in eine geteilte SaaS-Architektur zu verlagern, wollte Axonius, dass der Agent seinem bestehenden Mandantenmodell folgt. Diese Entscheidung prägte die technischen Anforderungen: Ein Agent, der die Umgebung eines Kunden verarbeitet, darf nicht auf die Daten eines anderen Kunden zugreifen, muss aber dennoch mit den etablierten Authentifizierungs-, Bereitstellungs- und API-Mustern des Dienstes integriert werden.

Für KI-Entwickler ist der wichtige Punkt, dass Multi-Tenancy hier nicht nur bedeutet, einer Anfrage eine Kunden-ID zuzuweisen. Der Agent muss so bereitgestellt, autorisiert, verbunden, überwacht und abgerechnet werden, dass die Grenzen gewahrt bleiben, die von einem Sicherheitsprodukt bereits erwartet werden.

Drei Bereitstellungsmuster mit unterschiedlichen Kompromissen

AWS ordnet die Designentscheidungen drei gängigen Mustern für SaaS-Agent-Bereitstellungen zu: Silo, Pool und Bridge.

In einer Silo-Architektur erhält jeder Mandant dedizierte Ressourcen. Auf AgentCore Runtime angewendet kann das bedeuten, für jeden Kunden einen eigenen Agenten bereitzustellen. Das bietet eine klare Infrastrukturgrenze, erhöht aber die Zahl der Ressourcen, die provisioniert, aktualisiert, überwacht und außer Betrieb genommen werden müssen.

Das Pool-Modell nutzt gemeinsam genutzte Ressourcen. Ein einzelner Agent kann mehrere Mandanten bedienen, wobei jede Sitzung eine eigene Session-ID erhält. AWS zufolge stellt AgentCore Runtime für jede Sitzung eine dedizierte MicroVM bereit, während auf Anwendungsebene die Trennung zwischen Mandanten gesteuert wird.

Dieser Ansatz vereinfacht die Bereitstellung und das Onboarding von Kunden, verlagert aber mehr Verantwortung auf die Anwendung. Der Agent muss den Mandantenkontext bei jeder Anfrage korrekt interpretieren und einen mandantenübergreifenden Zugriff verhindern. Mandantenspezifisches Verhalten kann zudem zusätzliche bedingte Logik in einer geteilten Bereitstellung erfordern.

Das Bridge-Modell kombiniert die beiden Ansätze. Eine Agent-Runtime kann gemeinsam genutzt werden, während auf der Tool-Ebene strengere Mandantenkontrollen angewendet werden. In der von AWS beschriebenen Architektur sitzt AgentCore Gateway zwischen dem Agenten und den ausgehenden Tools und ermöglicht, dass Tool-Aufrufe vor der Ausführung gegen Mandantengrenzen geprüft werden.

AWS stellt dieses hybride Muster als Möglichkeit dar, den Infrastruktur-Overhead zu reduzieren und gleichzeitig einen stärkeren Kontrollpunkt für den Zugriff auf Kundensysteme zu behalten. Die Fallstudie legt nicht alle Details der Produktionsimplementierung offen, daher ist es anhand der verfügbaren Belege nicht möglich zu beurteilen, wie Axonius jede Komponente zwischen geteilten und dedizierten Ressourcen aufgeteilt hat.

Identität und Tool-Zugriff sind Teil der Isolationsgrenze

Axonius verfügte bereits über ein Authentifizierungs- und Autorisierungsmodul, das auf mandantenspezifischer Amazon-EC2-Infrastruktur lief. Die Anforderung bestand darin, Agenten hinzuzufügen, ohne diesen Identitätsfluss zu ersetzen.

AWS beschreibt ein Design, bei dem sich Mandanten über einen OAuth-2.0-Identity-Provider wie Amazon Cognito authentifizieren. Tokens enthalten einen mandantenspezifischen Claim, etwa eine benutzerdefinierte Mandanten-ID. Der integrierte JWT-Authorizer in AgentCore Runtime validiert das Token über den Discovery-Endpunkt des Identity-Providers, während der Agent den Claim liest, um Anfragen an die richtige Kundenumgebung weiterzuleiten.

Diese Aufteilung ist bedeutend. Die Token-Validierung stellt fest, dass eine Anfrage von einem akzeptierten Identity-Provider stammt, aber der Agent und seine Tools müssen den Mandanten-Claim dennoch korrekt anwenden. In der Praxis hängt die Sicherheitsgrenze sowohl vom Autorisierungsmechanismus der Plattform als auch vom Code ab, der Identität auf APIs, Datenspeicher und Tools abbildet.

Dasselbe Prinzip gilt für die Dienstintegration. AWS sagt, der einem Mandanten zugeordnete Agent müsse sicheren Zugriff auf die APIs dieses Mandanten haben. Der Beitrag stellt AgentCore Gateway als möglichen Durchsetzungspunkt für ausgehende Tool-Aufrufe dar und schafft damit eine Ebene, auf der der Mandantenkontext geprüft werden kann, bevor ein Tool mit der Kunden-Workload interagiert.

Nachweise, Kostenkontrolle und operative Skalierung

AWS nennt die Kostenverfolgung als eine der zentralen Anforderungen von Axonius, da Modellaufrufe voraussichtlich einen großen Teil der Ausgaben eines Agenten ausmachen. Eine mandantenweise Abrechnung kann einem SaaS-Anbieter helfen, zu entscheiden, wie eine KI-Funktion bepreist, Nutzungsgrenzen festgelegt und Kunden oder Workflows mit ungewöhnlich hohem Verbrauch identifiziert werden.

Das Unternehmen musste den Agent-Workload außerdem in seinen bestehenden silo-basierten Continuous-Delivery-Prozess integrieren. Diese Anforderung wird leicht übersehen: Eine Architektur, die im Prototyp funktioniert, kann im Betrieb schwierig werden, wenn jede Kundenumgebung ihren eigenen Bereitstellungslebenszyklus hat.

Observability war ein weiteres genanntes Anliegen. AWS zufolge benötigte Axonius Monitoring, Alarme und Tracing auf Fleet-Ebene für eine große Zahl von Agenten, mit ausreichend Details, um Ausfälle zu untersuchen. Diese Anforderungen machen den Agent-Betrieb anders als gewöhnliches Anwendungsmonitoring. Teams müssen nicht nur wissen, ob ein Dienst verfügbar ist, sondern auch, welche Modellaufrufe, Tools, Sitzungen und Mandantenberechtigungen zu einem Ergebnis beigetragen haben.

Die verfügbaren Belege stammen von AWS und nicht von einem unabhängigen Prüfer oder einem Kundeninterview. AWS berichtet, dass AgentCore Axonius erlaubte, isolierte, Multi-Tenant-Agenten bereitzustellen, ohne benutzerdefinierte Infrastruktur für Compute-Isolation, Authentifizierung oder Observability von Grund auf zu bauen. Das ist eine Anbieterbehauptung über die Rolle der Plattform, kein unabhängig verifizierter Vergleich von Engineering-Zeit, Sicherheit oder Gesamtkosten.

Was das für Entwickler und Unternehmenskäufer bedeutet

Für SaaS-Unternehmen zeigt das Axonius-Beispiel eine praktische Reihenfolge für das Hinzufügen von Agenten: mit dem bestehenden Mandantenmodell beginnen, die Daten- und Tool-Grenzen identifizieren und dann entscheiden, welche Kontrollen in die Runtime, die Anwendung oder eine Gateway-Ebene gehören.

Die Wahl beeinflusst auch die Produktökonomie. Dedizierte Ressourcen können klarere Isolation und Anpassung bieten, während geteilte Runtimes das Onboarding und den Betrieb vereinfachen können. Ein Bridge-Design kann Redundanz reduzieren, erfordert aber eine sorgfältige Durchsetzung von Richtlinien an jeder Tool-Grenze. Keines der Modelle macht das Testen von Autorisierungsfehlern, fehlerhaften Mandanten-Claims, übermäßigen Tool-Berechtigungen und unbeabsichtigten Datenlecks überflüssig.

Unternehmenskäufer, die KI-Funktionen bewerten, sollten Anbieter fragen, wie die Mandantenidentität einer Agentenanforderung folgt, ob Tool-Aufrufe separat autorisiert werden, wie die Nutzung des Modells zugeordnet wird und wie Traces für die Incident-Response getrennt werden. Diese Fragen sind besonders wichtig für Sicherheitssoftware, in der ein Agent sensible Bestands-, Konfigurations- und Schwachstelleninformationen verarbeiten kann.

Die breitere Marktimplikation ist, dass Agent-Plattformen ebenso sehr um operative Grundbausteine wie um Modellzugang konkurrieren. Runtime-Isolation, Identitätsintegration, Gateways, Bereitstellungsautomatisierung und Observability können entscheiden, ob ein Agent von einer Demo zu einem Produkt wird, das ein SaaS-Anbieter über Hunderte von Umgebungen hinweg unterstützen kann.

Was als Nächstes zu beobachten ist

Die nächsten Signale werden konkrete Produktionsdetails von Axonius oder AWS sein: ob das Unternehmen in der Produktion eine geteilte Runtime, dedizierte Runtimes oder eine Bridge-Anordnung verwendet; wie die Kostenzuordnung auf Mandantenebene implementiert wird; und welche Kontrollen in Anwendungscode versus AgentCore Gateway durchgesetzt werden.

Entwickler sollten auch auf unabhängige Belege zu Bereitstellungsaufwand, Incident-Handling und Isolationstests achten. Mehr Details zu Modellauswahl, Durchsatz, Latenz und den Kosten für den Betrieb des ersten Axonius-Agenten würden es erleichtern, die Architektur jenseits ihrer erklärten Designziele zu bewerten.

Creati.ai-Perspektive

Das Beispiel von Axonius geht weniger darum, einem Sicherheitsprodukt einen Chatbot hinzuzufügen, sondern vielmehr darum, die Ausführung von Agenten in eine bestehende SaaS-Kontrollebene einzupassen. Die schwierige Arbeit besteht darin, Identität, Datenzugriff, Tools, Abrechnung, Releases und Debugging mit dem Mandanten zu verknüpfen, dem die Anfrage gehört.

Die Fallstudie von AWS zeigt, warum verwaltete Agenten-Infrastruktur für ISVs attraktiv ist, beweist aber nicht, dass eine Plattform-Abstraktion das Sicherheitsrisiko auf Anwendungsebene beseitigt. Die wichtigste Lehre für Entwickler ist, Mandanten-Routing und Tool-Autorisierung als produktkritische Kontrollen zu behandeln und die Behauptungen des Anbieters mit Bereitstellungs- und Ausfalldaten zu validieren, bevor man sich für eine Architektur im großen Maßstab entscheidet.