OX Security CNAPP-Plattform vereint Cloud Posture und Laufzeitverteidigung für KI-Agenten
OX Security hat am 16. September eine CNAPP-Plattform vorgestellt, die etablierte Cloud-Kontrollen mit Echtzeitüberwachung für KI-Agenten kombiniert. Die OX Security CNAPP-Plattform namens OX Cloud zielt auf eine Sicherheitslücke, die entsteht, wenn autonome Software über Identitäten, Berechtigungen und Zugriff auf Unternehmenswerkzeuge verfügt.
Die Einführung ist nicht einfach eine weitere Erweiterung einer Cloud-Sicherheitsfunktionsliste. OX argumentiert, dass Sicherheitsteams einen einzigen Graphen benötigen, der Code, Cloud-Konfiguration, Identitäten, Daten, Prompts und laufende Agentenaktionen verbindet. Diese Behauptung stellt sowohl herkömmliche CNAPP-Produkte als auch separate KI-Sicherheitswerkzeuge infrage.
Palo Alto Networks und andere große Sicherheitsanbieter bieten bereits Laufzeitschutz, KI-Posture-Management und Agentenkontrollen an. OX muss daher nachweisen, dass sein Kontext von Prompt bis Laufzeit bessere Entscheidungen ermöglicht und nicht lediglich ein umfassenderes Dashboard bietet.
Die zentrale Frage lautet, ob die Kombination dieser Signale Verteidigern hilft, erreichbare Risiken und unsicheres Agentenverhalten einzugrenzen. Falls dies gelingt, könnte OX Cloud die Lücke zwischen der Entdeckung einer Cloud-Schwachstelle und dem Verständnis schließen, wie ein autonomes System sie ausnutzen könnte.
Die OX Security CNAPP-Plattform erweitert die Sichtbarkeit auf aktive Agentenaktivitäten
OX Cloud ergänzt die Infrastruktur-, Identitäts-, Schwachstellen- und Datensignale, die Cloud-Sicherheitsplattformen bereits erfassen, um Agentenverhalten.
Eine Cloud-native Application Protection Platform, kurz CNAPP, vereint mehrere Cloud-Sicherheitsfunktionen in einem System. Dazu gehören typischerweise die Überwachung von Konfigurationen, Workload-Schutz, Berechtigungsanalysen, Schwachstellenmanagement und die Abbildung von Angriffspfaden.
OX Cloud umfasst Cloud Security Posture Management, Kubernetes Posture Management, Data Security Posture Management, Laufzeit-Erkennung von Schwachstellen, Cloud-Inventarisierung und graphbasierte Angriffspfadanalysen. Das Unternehmen ergänzt dies außerdem um AI Detection and Response, abgekürzt AIDR.
Der Unterschied liegt darin, was OX von der Plattform beobachten lassen will. Herkömmliche Posture-Tools untersuchen Ressourcen wie Storage-Buckets, Container, Identitäten, Netzwerkpfade und Zugriffsrichtlinien. OX Cloud soll zusätzlich Agenten, Modelle, Prompts und Model Context Protocol-Server identifizieren, die in dieser Umgebung betrieben werden.
MCP ist eine Standardschnittstelle, über die KI-Systeme mit externen Werkzeugen und Daten verbunden werden können. Ein MCP-Server kann einem Agenten etwa eine Datenbank, ein Dateisystem, einen Ticketing-Dienst, ein Code-Repository oder eine interne API bereitstellen.
Diese Verbindung erhöht den Nutzen eines Agenten, verwandelt aber zugleich Modellausgaben in Aktionen. Ein manipulierter Agent könnte eingeschränkte Datensätze abrufen, ein nicht genehmigtes Werkzeug aufrufen oder gültige Anmeldedaten außerhalb des vorgesehenen Workflows verwenden.
OX zufolge verbindet die Plattform solche Aktionen mit dem umgebenden Cloud-Kontext. Laut der OX Cloud-Ankündigung des Unternehmens kann das Produkt Workloads, Identitäten, Datenspeicher, Kubernetes-Cluster und aktive KI-Agenten inventarisieren.
Anschließend nutzt die Plattform Erreichbarkeitsanalysen, um Erkenntnisse zu priorisieren. Die Erreichbarkeit bestimmt, ob eine exponierte Komponente, ein verwundbares Paket oder eine übermäßige Berechtigung tatsächlich eine Verbindung zu einer wertvollen Ressource oder einem Ausführungspfad herstellen kann.
Dieser Ansatz ist relevant, weil Cloud-Scanner lange Listen technisch gültiger Befunde erzeugen können. Ein verwundbares Paket in einem isolierten Workload stellt nicht dasselbe unmittelbare Risiko dar wie dasselbe Paket in einem internetexponierten Dienst mit Zugriff auf Kundendaten.
OX wendet diese Logik auf Agenten an. Ein fragwürdiger Prompt oder ungewöhnlicher Werkzeugaufruf wird wichtiger, wenn der verantwortliche Agent Produktionsdaten, administrative APIs oder Bereitstellungssysteme erreichen kann.
Das Unternehmen erklärt außerdem, dass OX Cloud Laufzeitaktivitäten mit dem Prompt oder Code verknüpfen kann, der sie ausgelöst hat. Diese Verbindung könnte Ermittlern helfen, nachzuvollziehen, warum ein Agent eine Aktion ausgeführt hat, anstatt lediglich zu protokollieren, dass sie stattgefunden hat.
Dabei handelt es sich weiterhin um Herstellerangaben. OX hat Funktionen und Produktarchitektur beschrieben, jedoch für diese Einführung keine vergleichenden Erkennungsraten, Messungen falsch-positiver Ergebnisse, Angaben zum Bereitstellungsaufwand oder unabhängige Bewertungen veröffentlicht.
Diese Evidenzlücke macht das Produkt nicht irrelevant. Sie definiert, was Unternehmenskäufer validieren müssen, bevor sie die neue Plattform als konsolidierte Steuerungsebene behandeln.
Warum KI-Agenten die traditionelle Cloud-Sicherheit unter Druck setzen
Agenten bündeln mehrere bekannte Sicherheitsprobleme in einer schnell agierenden Identität, die schlussfolgern, Werkzeuge auswählen und Änderungen auslösen kann.
Ein traditioneller Workload folgt in der Regel Code, den Ingenieure vor der Bereitstellung überprüfen können. Seine Berechtigungen können dennoch zu weit gefasst sein und seine Abhängigkeiten weiterhin Schwachstellen enthalten. Der erwartete Ausführungspfad ist jedoch relativ stabil.
Ein Agent verhält sich anders. Er interpretiert Anweisungen, ruft Kontext ab, wählt Werkzeuge aus und erstellt zur Laufzeit eine Abfolge von Aktionen. Kleine Änderungen an Prompts, abgerufenen Dokumenten, Modellversionen oder Werkzeugbeschreibungen können diese Abfolge verändern.
Diese Variabilität bedeutet nicht, dass Agentenverhalten nicht nachvollziehbar wäre. Sie bedeutet, dass Verteidiger Telemetriedaten sowohl zum Entscheidungsweg als auch zu den daraus resultierenden Systemaufrufen benötigen.
Identität ist ein zentraler Teil dieses Problems. Ein Agent, der über ein gemeinsam genutztes Dienstkonto handelt, kann Protokolle schwer interpretierbar machen. Ermittler sehen möglicherweise eine Datenbankabfrage oder Dateiveränderung, ohne zu wissen, welcher Agent sie ausgelöst hat, warum er gehandelt hat oder wer den Workflow autorisiert hat.
Die Least-Privilege-Leitlinien von Microsoft empfehlen, jeden Agenten als eigenständigen Principal zu behandeln. Jeder Agent sollte über eine verwaltete Identität, einen klaren Eigentümer, eng abgegrenzte Rollen und ein genehmigtes Werkzeugmanifest verfügen.
Dieses Modell schafft eine messbare Grenze. Teams können bestimmen, welche Werkzeuge ein Agent aufrufen soll, auf welche Ressourcen er zugreifen kann und ob seine Laufzeitaktivität innerhalb seines zugewiesenen Zwecks bleibt.
Das Problem wird gravierender, wenn MCP-Server weitreichende Anmeldedaten übernehmen. MCP unterstützt Autorisierungsmechanismen, einschließlich OAuth, doch das Protokoll erzwingt nicht automatisch für jede Bereitstellung eine sichere Richtlinie.
Microsoft berichtete, dass 15 Prozent der über Defender for Cloud-Signale beobachteten Remote-MCP-Server nicht authentifizierten Zugriff auf sensible Daten oder operative Funktionen erlaubten. Die Erkenntnisse zu MCP-Expositionen umfassten Verbindungen zu Ticketing-Systemen, privaten Repositories und HR-Werkzeugen.
Diese Zahl beschreibt nicht sämtliche MCP-Bereitstellungen. Sie zeigt jedoch, dass die Konnektivität von Agenten reale Unternehmenssysteme offenlegen kann, wenn Authentifizierungs- und Ausführungsgrenzen falsch konfiguriert sind.
Ein Posture-Scan könnte den exponierten Server identifizieren. Ein Identitätsprodukt könnte seine Anmeldedaten finden. Ein Laufzeitwerkzeug könnte einen verdächtigen Aufruf aufzeichnen. OX setzt darauf, dass ein gemeinsamer Graph alle drei Aspekte verbinden kann, bevor ein Analyst die Kette manuell zusammensetzen muss.
Dies ist das stärkste Argument dafür, CNAPP-Daten mit Laufzeitverteidigung für KI-Agenten zu kombinieren. Die Bedrohung ist weder ausschließlich ein Anwendungsproblem noch ausschließlich ein Cloud-Problem.
Man stelle sich einen Agenten vor, der Supportanfragen bearbeiten soll. Er kann Tickets lesen, interne Dokumentation durchsuchen und Kundendaten aktualisieren. Ein indirekter Prompt in einem Ticket könnte den Agenten anweisen, nicht zusammenhängende Datensätze abzurufen oder Daten an einen externen Endpunkt zu senden.
Ein Prompt-Filter könnte die Anweisung markieren. Ihre Schwere hängt jedoch davon ab, welche Identität der Agent verwendet, welche Werkzeuge er aufrufen kann und auf welche Datensätze diese Werkzeuge zugreifen können.
Umgekehrt weist ein ungewöhnlicher API-Aufruf nicht immer auf einen Angriff hin. Der Agent könnte nach einer seltenen Anfrage eine legitime Aufgabe abschließen. Verteidiger benötigen genügend Kontext, um unerwartetes von unautorisiertem Verhalten unterscheiden zu können.
OX Cloud ist auf diese Unterscheidung ausgelegt. Das Versprechen besteht nicht allein darin, seltsame Prompts zu erkennen. Vielmehr soll aktives Verhalten mit erreichbaren Assets, effektiven Berechtigungen und dem ursprünglichen Softwarepfad verbunden werden.
OX Cloud macht Erreichbarkeit zu seinem zentralen Differenzierungsmerkmal
Der zentrale Mechanismus der Plattform ist eine evidenzgestützte Priorisierung, bei der Laufzeitverhalten und Angriffspfade bestimmen, welche Befunde Aufmerksamkeit verdienen.
Cloud-Sicherheitsteams kämpfen bereits mit einem hohen Warnmeldungsaufkommen. Posture-Scanner erkennen Fehlkonfigurationen, Schwachstellenwerkzeuge listen Pakete auf, Identitätssysteme identifizieren übermäßige Berechtigungen, und Datenwerkzeuge klassifizieren sensible Speicherorte.
Das Hinzufügen von Agenten kann ein weiteres Inventar schaffen, ohne diese Fragmentierung aufzulösen. Ein Sicherheitsteam könnte erfahren, dass ein Agent existiert, ein bestimmtes Modell verwendet und mit mehreren Werkzeugen verbunden ist. Diese Fakten zeigen jedoch noch nicht, ob sein Verhalten einen ausnutzbaren Pfad schafft.
OX beschreibt einen Workflow in vier Phasen: identifizieren, priorisieren, untersuchen und steuern. Die Phasen nutzen dieselben Kontextdaten, statt als voneinander getrennte Produktmodule zu funktionieren.
Die Identifizierung umfasst Workloads, Identitäten, Agenten, Datenspeicher und Cloud-Assets. OX zufolge gehören dazu auch Ressourcen, die anhand beobachteter Aktivitäten erkannt werden, und nicht nur solche, die in Konfigurationsdateien deklariert sind.
Die Priorisierung wendet Erreichbarkeit auf Schwachstellen, Berechtigungen, Fehlkonfigurationen und Risiken in der Lieferkette an. Befunde, die keine Verbindung zu einem aktiven Workload oder wertvollen Asset herstellen können, erhalten eine geringere Dringlichkeit.
Die Untersuchung nutzt einen Cloud-Graphen, um die Beziehungen rund um ein Ereignis zu rekonstruieren. Ein Analyst sollte erkennen können, welche Identität gehandelt hat, welche Ressource sie berührt hat und welche weiteren Systeme erreichbar waren.
Die Steuerung wendet Einschränkungen auf Agentenaktivitäten und die KI-Nutzung an. Hier werden die AIDR- und agentischen Angriffsfunktionen von OX mehr als reine Discovery-Funktionen.
Der Mechanismus klingt schlüssig, doch seine Qualität hängt von der Datenverlässlichkeit ab. OX muss Assets zuverlässig entdecken, Berechtigungen interpretieren, Agentenaufrufe nachverfolgen und genug Kontext für Untersuchungen bewahren.
Abdeckungslücken können falsches Vertrauen erzeugen. Ein nicht beobachteter Werkzeugaufruf, eine nicht verwaltete Anmeldedatei, ein verschlüsselter Datenverkehrspfad oder ein nicht unterstütztes Agenten-Framework könnte die Kette zwischen Prompt und Ergebnis unterbrechen.
Auch Datenkorrelation kann mehrdeutige Schlussfolgerungen liefern. Ein Prompt, der kurz vor einem API-Aufruf erscheint, beweist nicht automatisch, dass er den Aufruf verursacht hat. Lang laufende Workflows, parallele Agenten, Wiederholungsversuche und delegierte Teilaufgaben erschweren die Attribution.
OX muss daher innerhalb seiner Benutzeroberfläche zwischen Korrelation und Kausalität unterscheiden. Analysten benötigen Zeitstempel, Aufrufketten, Identitätsaufzeichnungen, Richtlinienentscheidungen und Anwendungstraces, die die vorgeschlagene Beziehung stützen.
Auch die Bereitstellungsarchitektur ist wichtig. Die Laufzeitinspektion kann über Netzwerkabfang, Workload-Sensoren, Anwendungsbibliotheken, API-Gateways, Cloud-Logs oder Integrationen mit Agenten-Frameworks erfolgen.
Jede Methode bietet eine andere Sichtbarkeit. Netzwerkkontrollen können Ziele und Nutzdaten beobachten, aber interne Schlussfolgerungen übersehen. Framework-Instrumentierung kann die Werkzeugauswahl erfassen, jedoch bei benutzerdefinierten Anwendungen unvollständige Abdeckung bieten.
OX erklärt, dass die breitere AINAPP-Plattform die Phasen Prompt, Code, Build, Bereitstellung und Laufzeit verbindet. AINAPP ist die Bezeichnung des Unternehmens für eine KI-native Application Protection Platform.
Das Konzept verschafft OX eine potenziell nützliche Position. Seine Anwendungssicherheitsprodukte untersuchen bereits Quellcode und Software-Lieferketten. OX Cloud erweitert diese Geschichte auf bereitgestellte Infrastruktur und laufende Agentenaktivitäten.
Käufer sollten jedoch fragen, wie die Verbindung für Code und Agenten funktioniert, die nicht bereits über OX-Produkte verwaltet werden. Eine einheitliche Plattform bietet nur begrenzten Nutzen, wenn der reichhaltigste Kontext ausschließlich innerhalb einer streng kontrollierten Toolchain verfügbar ist.
Der Praxistest ist ein realer Vorfall. Ein Sicherheitsteam sollte eine verdächtige Tool-Beschreibung einschleusen, einen unbefugten Zugriffsversuch auslösen und prüfen, ob OX den vollständigen Ablauf rekonstruiert.
Diese Übung sollte den auslösenden Inhalt, die Agentenidentität, das ausgewählte Tool, die Parameter, das Ziel, die wirksame Berechtigung, die betroffenen Daten und das Ergebnis der Durchsetzung zeigen. Alles andere zwingt Analysten dazu, Belege systemübergreifend zusammenzufügen.
OX Security trifft auf etablierte CNAPP- und KI-Sicherheitsplattformen
OX konkurriert mit der von größeren Anbietern vorangetriebenen Plattformkonsolidierung, nicht mit statischen Cloud-Scannern, die KI vollständig ignoriert haben.
Der Markt hat sich bereits in Richtung einer Abdeckung über den gesamten Lebenszyklus bewegt. Große Anbieter kombinieren inzwischen KI-Erkennung, Posture-Analyse, Red Teaming, Laufzeitprüfung, Identitätskontrollen und Policy-Durchsetzung.
Palo Alto Networks präsentiert Prisma AIRS als Plattform für KI-Anwendungen, Modelle, Daten und Agenten. Die Prisma AIRS documentation beschreibt Laufzeit-Firewalls, APIs, Red Teaming, Modellsicherheit, Posture Management und Agentenschutz.
Palo Alto integriert außerdem die KI-Erkennung mit Cortex Cloud. Diese Verbindung kann Modelle, Endpunkte, Datensätze, Agenten und Abhängigkeitsbeziehungen über Amazon Web Services, Microsoft Azure und Google Cloud hinweg identifizieren.
Damit ist der zentrale Wettbewerb breiter als OX gegen eine herkömmliche CNAPP. Es geht um die kontextorientierte Integration von OX gegenüber etablierten Sicherheitsplattformen, die ähnliche Kontrollen über bestehende Produktportfolios hinweg zusammenstellen.
Die etablierten Anbieter bringen installierte Kundenbasen, Cloud-Telemetrie, Threat Intelligence, Identitätsintegrationen und gewachsene Beschaffungsbeziehungen mit. Käufer könnten es vorziehen, einen bestehenden Vertrag zu erweitern, statt eine weitere Sicherheitsplattform einzuführen.
OX kann mit Fokus dagegenhalten. Ein kleinerer Anbieter kann rund um Agenten-Workflows entwickeln, ohne jede Architekturannahme einer älteren Produktsuite bewahren zu müssen.
Seine Code-to-Runtime-Erzählung könnte auch für Anwendungssicherheitsteams attraktiv sein. Diese Teams wollen wissen, ob ein während der Entwicklung eingeführter Befund nach der Bereitstellung weiterhin erreichbar ist und ob ein Agent den verwundbaren Pfad aktivieren kann.
Diese Verbindung könnte Konflikte zwischen Entwicklern und Sicherheitsanalysten verringern. Entwickler erhalten häufig Scanner-Befunde ohne Belege dafür, dass der betroffene Code tatsächlich exponiert ist. Laufzeitkontext kann zeigen, welche Probleme unmittelbare operative Relevanz haben.
Doch größere Anbieter vertreten dasselbe Konsolidierungsargument. Palo Alto meldete nach einem Jahr allgemeiner Verfügbarkeit für Prisma AIRS rund 120 Millionen US-Dollar an jährlich wiederkehrenden Umsätzen.
Das Unternehmen meldete in seiner Präsentation zum vierten Quartal des Geschäftsjahres 2026 außerdem mehr als 800 Prisma-AIRS-Kunden. Diese Zahlen beruhen auf den eigenen Definitionen von Palo Alto für Umsatzzuordnung und gebuchte Angebote, deuten jedoch auf eine nennenswerte kommerzielle Nachfrage hin.
Dieser Wettbewerbsdruck zwingt OX dazu, konkrete Vorteile nachzuweisen. Eine längere Funktionsliste wird nicht ausreichen, da Cloud-Plattformen bereits viele derselben Kategorien abdecken.
OX kann sich durch schnellere Untersuchungen, klarere Priorisierung, breitere Framework-Unterstützung oder eindeutigere Prompt-to-Runtime-Zuordnung differenzieren. Es könnte auch durch flexible Bereitstellung und geringere operative Komplexität konkurrieren.
Kunden sollten Workflows statt Kategorienbezeichnungen vergleichen. Beide Produkte könnten Agentenerkennung, Laufzeitabwehr und Posture Management beanspruchen, dabei jedoch unterschiedliche Telemetrie erfassen oder Richtlinien an unterschiedlichen Punkten durchsetzen.
Eine Plattform könnte bösartige Prompts vor der Modellverarbeitung blockieren. Eine andere könnte Tool-Aufrufe abfangen, Identitätsberechtigungen beschränken oder die Workload nach Erkennung verdächtiger Aktivitäten isolieren.
Diese Kontrollen ergänzen sich, doch ihre Platzierung beeinflusst Latenz, Abdeckung und Fehlermodi. Ein Produkt außerhalb des Ausführungspfads kann sicherer beobachten, verfügt jedoch möglicherweise nicht über unmittelbare Blockierungsbefugnisse.
Eine Inline-Kontrolle kann eine Aktion stoppen, wird dadurch jedoch auch Teil des Verfügbarkeitspfads der Anwendung. Käufer müssen verstehen, was geschieht, wenn der Sicherheitsdienst langsam wird, die Verbindung verliert oder eine Anfrage nicht klassifizieren kann.
OX hat öffentlich noch nicht genügend launchespezifische Belege vorgelegt, um diese Vergleiche abschließend zu entscheiden. Die unmittelbare Herausforderung besteht darin, eine glaubwürdige Architektur in wiederholbare Kundenergebnisse zu überführen.
Laufzeitabwehr kann Agentendesign und Zugriffskontrolle nicht ersetzen
Keine CNAPP kann Agenten ausgleichen, die Identitäten teilen, übermäßige Berechtigungen erhalten oder wirkungsstarke Aktionen ohne unabhängige Autorisierung ausführen.
Laufzeitüberwachung erhält häufig Aufmerksamkeit, weil sie Verhalten erkennen kann, das statische Prüfungen übersehen. Diese Stärke kann Teams jedoch auch dazu verleiten, Beobachtung als Ersatz für eine sicherere Architektur zu behandeln.
Ein Agent sollte nicht umfassenden Zugriff erhalten, nur weil ein Überwachungsprodukt seine Aktionen protokolliert. Die Protokollierung einer unbefugten Datenübertragung macht die Übertragung nicht rückgängig.
Die agentic risk taxonomy von OWASP umfasst Tool-Missbrauch, Missbrauch von Identitäten und Berechtigungen, Memory Poisoning, Kaskadenfehler und das Verhalten abtrünniger Agenten. Diese Risiken überschreiten die Grenzen von Modell, Anwendung, Identität und Infrastruktur.
Verteidiger sollten mit eindeutigen Agentenidentitäten beginnen. Gemeinsame Zugangsdaten verschleiern Zuständigkeiten und erschweren den Entzug von Berechtigungen. Jeder Produktionsagent benötigt einen benannten Verantwortlichen, einen dokumentierten Zweck und eine begrenzte Menge zulässiger Ressourcen.
Auch der Tool-Zugriff sollte ausdrücklich definiert sein. Ein Agent, der Support-Tickets zusammenfassen soll, sollte nicht administrative Zugriffsrechte auf die Ticketing-Plattform erben. Er sollte ausschließlich die für diese Aufgabe nötigen Leseoperationen erhalten.
Schreibzugriff verdient eine separate Entscheidung. Wenn der Workflow auf die Änderung von Datensätzen ausgeweitet wird, sollte das Team neue Berechtigungen und Freigaberegeln schaffen, statt eine bestehende Rolle ungeprüft auszuweiten.
Wirkungsstarke Aktionen benötigen deterministische Durchsetzung. Das Löschen von Daten, die Änderung von Produktionsinfrastruktur, das Auslösen von Zahlungen oder die Veröffentlichung externer Inhalte sollte nicht allein auf der Interpretation natürlicher Sprachinstruktionen durch ein Modell beruhen.
Menschliche Freigabe bleibt für Aktionen mit großen finanziellen, operativen oder rechtlichen Folgen angemessen. Automatisierte Freigabe kann bei Aufgaben mit geringerer Auswirkung funktionieren, wenn die Policy-Bedingungen eng gefasst und unabhängig durchgesetzt werden.
Memory bringt ein weiteres Risiko mit sich. Ein Agent kann Gesprächsverläufe, Präferenzen, abgerufene Fakten oder Zwischenpläne über Sitzungen hinweg speichern. Bösartige Inhalte können in diesem Speicher bestehen bleiben und spätere Entscheidungen beeinflussen.
Ein Laufzeitprodukt sollte Memory-Lese- und Schreibvorgänge soweit möglich offenlegen. Es sollte auch zeigen, ob ein Agent abgerufene Inhalte bei der Auswahl eines Tools oder der Konstruktion von Parametern verwendet hat.
Der Memory-Zugriff kann jedoch innerhalb eines Frameworks oder Modelldienstes erfolgen, der nur begrenzte Telemetrie bereitstellt. Käufer sollten testen, ob OX Cloud diese Interaktionen über ihren tatsächlichen Bereitstellungs-Stack hinweg erfasst.
False Positives stellen eine eigene Herausforderung dar. Agenten-Workflows erzeugen naturgemäß ungewöhnliche Aktionsfolgen, weil sie sich an Nutzeranfragen anpassen. Einfache Anomalieerkennung kann legitime Abweichungen markieren und Analysten überlasten.
OX sagt, dass Erreichbarkeit dazu beiträgt, dieses Rauschen zu verringern. Die Behauptung ist plausibel, doch Erreichbarkeit beweist keine böswillige Absicht. Ein erreichbarer Pfad kann einen legitimen Workflow unterstützen, während ein nicht erreichbarer Softwarefehler nach einer Konfigurationsänderung relevant werden kann.
Unternehmen sollten die Präzision während einer kontrollierten Bereitstellung messen. Nützliche Kennzahlen umfassen bestätigte Vorfälle, False Positives, Untersuchungszeit, blockierte legitime Aufgaben, nicht unterstützte Workflows und Telemetrielücken.
Sie sollten außerdem die Auswirkungen auf die Leistung messen. Laufzeitprüfung kann Latenz hinzufügen, wenn sie Prompts, Tool-Aufrufe, Datenflüsse oder Identitätsrichtlinien synchron auswertet.
OX hat keine allgemeinen Latenz- oder Overhead-Zahlen für OX Cloud veröffentlicht. Die Ergebnisse werden wahrscheinlich von Bereitstellungsmethode, Verkehrsvolumen, Richtlinienkomplexität und dem Umfang des erfassten Kontexts abhängen.
Eine weitere Unsicherheit betrifft die Konsistenz der Durchsetzung. Eine Organisation kann Agenten betreiben, die mit mehreren Frameworks über mehrere Clouds und SaaS-Plattformen hinweg erstellt wurden. Eine Policy muss diese architektonischen Unterschiede überstehen.
Ein Dashboard, das jeden Agenten entdeckt, aber nur einen Teil davon steuert, schafft ungleichmäßigen Schutz. Sicherheitsteams benötigen eine klare Kompatibilitätsmatrix und Belege dafür, dass nicht unterstützte Pfade sichtbar bleiben.
Die angemessene Schlussfolgerung lautet nicht, dass Laufzeitabwehr keinen Wert hat. Vielmehr funktioniert Laufzeitüberwachung am besten als eine Schicht innerhalb eines größeren Kontrollsystems.
Sicheres Agentendesign beginnt mit begrenzter Autorität. Die Laufzeitabwehr prüft anschließend, ob das Verhalten innerhalb dieser Grenzen bleibt, und hilft Ermittlern, Abweichungen zu verstehen.
Drei Signale werden zeigen, ob OX Cloud liefert
Der nächste Test sind operative Belege, darunter Kundenvalidierung, messbare Rauschreduzierung und umfassende Durchsetzung über reale Agenten-Stacks hinweg.
Das erste Signal sind unabhängige Kundenbelege. OX sollte zeigen, wie die Plattform in Produktionsumgebungen mit mehreren Clouds, Agenten-Frameworks, Identitätsanbietern und MCP-Servern funktioniert.
Nützliche Fallstudien würden quantifizieren, wie viele Agenten und nichtmenschliche Identitäten entdeckt wurden. Sie sollten außerdem berichten, welche riskanten Pfade bestätigt wurden, wie viele Warnungen unterdrückt wurden und wie sich die Untersuchungszeit verändert hat.
Das zweite Signal ist die vergleichende Leistung. Käufer benötigen Erkennungs- und Durchsetzungstests für Prompt Injection, vergiftete Tool-Beschreibungen, übermäßige Berechtigungen, ungewöhnliche API-Sequenzen und versuchte Datenexfiltration.
Diese Tests sollten gutartige Variationen einbeziehen, um False Positives zu messen. Ein System, das jede ungewöhnliche Aktion blockiert, bietet für adaptive Workflows wenig Wert.
OX sollte außerdem offenlegen, wo die Durchsetzung stattfindet. Kunden müssen wissen, ob Kontrollen innerhalb von Workloads, über Netzwerkprüfung, innerhalb von Agenten-Frameworks oder über Cloud-APIs arbeiten.
Das dritte Signal ist die Reaktion des Wettbewerbs. Palo Alto Networks, Microsoft und andere Sicherheitsanbieter integrieren Agentenidentität, Posture, Laufzeitprüfung und Governance in größere Plattformen.
Wenn diese Anbieter Code, Prompts, Identitäten, Cloud-Ressourcen und Tool-Aufrufe mit ähnlicher Präzision verbinden, wird sich die architektonische Differenzierung von OX verringern. OX wird dann bei Bereitstellungsqualität, Untersuchungsgeschwindigkeit, Abdeckung und Kundenservice konkurrieren.
Wenn die etablierten Anbieter diese Kontrollen fragmentiert halten, kann OX argumentieren, dass ein kontextbezogener Graph schnellere und besser begründbare Entscheidungen ermöglicht. Kundenbewertungen werden bestimmen, welches Ergebnis die Produktionsrealität widerspiegelt.
Sicherheitsverantwortliche, die die CNAPP-Plattform von OX Security bewerten, sollten mit einem begrenzten Agenten-Workflow beginnen. Sie können dessen Identität, genehmigte Tools, erreichbare Daten, erwartete Aktionen und Eskalationsregeln abbilden, bevor sie eine breitere Abdeckung aktivieren.
Die Bewertung sollte anschließend kontrollierte Fehler einführen. Testen Sie einen exponierten MCP-Server, eine überprivilegierte Identität, ein vergiftetes Dokument, einen unbefugten Tool-Aufruf und eine verwundbare erreichbare Workload.
Die Plattform sollte nicht nur zeigen, dass etwas Ungewöhnliches passiert ist, sondern auch, warum es relevant war. Sie sollte die ursprüngliche Anweisung mit der handelnden Identität, dem ausgewählten Tool, dem erreichbaren Asset, der Policy-Entscheidung und dem Endergebnis verbinden.
Dieser Maßstab gilt über OX hinaus. Produkte für Agentensicherheit müssen komplexe Telemetrie in verlässliche Durchsetzung und nachvollziehbare Untersuchungen überführen.
Der Start spiegelt einen echten Wandel in der Cloud-Sicherheit wider. Agents werden zu aktiven Teilnehmern in der Cloud, statt lediglich eine weitere Asset-Klasse zu sein, die inventarisiert werden muss.
OX Cloud reagiert darauf, indem es Laufzeitverhalten im selben Graphen wie Code, Workloads, Identitäten und Daten abbildet. Das Design wirkt glaubwürdig, doch die weitreichendsten Behauptungen bedürfen weiterhin einer unabhängigen Validierung.
Teams, die OX Cloud in Erwägung ziehen, sollten einen produktionsnahen Test verlangen, keine aufpolierte Funktionsdemonstration. Kann die Plattform jeden Agent identifizieren, legitime Abweichungen von Missbrauch unterscheiden und eine vollständige Aktionskette rekonstruieren? Kann sie Grenzen durchsetzen, ohne die normale Arbeit zu verzögern oder eine weitere Alert-Queue zu schaffen? Diese Ergebnisse werden entscheiden, ob die OX Security CNAPP-Plattform zu einer bedeutenden Steuerungsebene wird oder zu einer weiteren Schicht, die Sicherheitsteams miteinander abgleichen müssen.
