Stellen Sie sich folgendes hypothetisches Szenario vor: Ein Agent in einer KI-Fabrik ruft ein Dokument ab. Darin verbirgt sich eine Anweisung, deren Ausführung durch den Agenten der Benutzer nie beabsichtigt hatte. Der Agent befolgt sie: Er stellt eine Verbindung her, ruft über das Model Context Protocol (MCP) ein Tool auf, ruft einen Datensatz ab, nach dem niemand gefragt hat, und sendet ihn an ein Ziel, das niemand genehmigt hat. Der Schutzmechanismus, der dies hätte erkennen sollen, lief als Sidecar im selben Container, also schaltete der Agent ihn zuerst aus. Das Protokoll stand unter der Kontrolle des Agenten, sodass der Vorfall nie aufgezeichnet wurde. Verstrichene Zeit: weniger als eine Sekunde. Niemand bemerkte etwas, weil keine Komponente auf dem Übertragungsweg dazu in der Lage war.
Das ist kein exotischer Fehlerfall. Vielmehr ist dies der Regelfall, wenn sich die Kontrollmechanismen direkt neben dem Agenten in derselben Vertrauensdomäne befinden, wo ein kompromittierter oder fehlgeleiteter Agent sie deaktivieren, umgehen oder die Beweisdaten manipulieren kann. Einfach ausgedrückt: Der Agent kann sich nicht selbst kontrollieren.
Die F5 Application Delivery and Security Platform stellt jede Anwendung und API bereit und schützt sie. Als Nächstes kommen KI-Agenten, die sich anders verhalten: Ein Agent ruft Modelle auf, nutzt Tools über MCP, kommuniziert mit anderen Agenten und greift auf APIs innerhalb und außerhalb der Factory zu. Um einen Mehrwert zu schaffen, benötigen Agenten kontrollierten Zugriff auf Modelle, Tools, APIs und Daten außerhalb ihrer Sandbox. Diese Interaktionen müssen dabei durchsetzbaren Richtlinien unterliegen. Die NVIDIA OpenShell Reference Architecture, die NVIDIA auf der NVIDIA GTC Berlin vorstellt, ist genau darauf ausgelegt. Sie verteilt die Laufzeitberechtigungen des Agenten, die hardwaregestützte Durchsetzung und die Inferenz auf drei Ebenen von NVIDIA-Hardware und bietet Partnern Raum auf dem Weg zwischen diesen Ebenen. Am deutlichsten lässt sich die Aufgabenverteilung veranschaulichen, indem man eine Anfrage auf ihrem Weg aus der Sandbox verfolgt.
Was die NVIDIA OpenShell-Referenzarchitektur leistet
Die Referenzarchitektur geht davon aus, dass der Agent nicht vertrauenswürdig ist, und trennt die Hardware entsprechend.
Innerhalb der NVIDIA OpenShell-Referenzarchitektur für sichere KI-Agenten wird NVIDIA OpenShell auf NVIDIA Vera-CPUs ausgeführt und verwaltet die Laufzeitberechtigungen des Agenten. Der zugehörige Supervisor prüft ausgehende Anfragen, wendet detaillierte Kontrollen auf den konfigurierten HTTP-, GraphQL- und MCP-Datenverkehr an, schützt Anmeldedaten und protokolliert jede Richtlinienentscheidung. Der Agent wird in einer Sandbox ausgeführt. Der Supervisor, der ihn verwaltet, hingegen nicht.
NVIDIA Sentry fügt eine unabhängige hardwarebasierte Überwachungs- und Durchsetzungsebene auf NVIDIA BlueField-4 DPUs hinzu, die sich in einer isolierten Sicherheitsdomäne befindet, auf die der Agent weder zugreifen noch die er verändern kann: Bedrohungserkennung, Prüfung von Anfragen und Antworten, Agenten-Governance und Eindämmung innerhalb von Millisekunden. NVIDIA Sentry ist eine optionale Ebene und befindet sich in NVIDIA Vera Rubin-Systemen im Zugriffspfad zu den Modellen.
Die NVIDIA Vera Rubin NVL72-Infrastruktur führt die Modelle aus, die von den Agenten aufgerufen werden. Damit entscheidet die Architektur bereits, ob ein Agent handeln darf, und überwacht zugleich dessen Aktivitäten – über eine Infrastruktur, auf die der Agent keinen Zugriff hat. F5 ergänzt diese Kontrollen durch eine speziell für KI-Datenverkehr entwickelte Inhaltsprüfung, Red Teaming und Anwendungsbereitstellung und baut dabei auf unserer Zusammenarbeit mit NVIDIA im Bereich der Cybersicherheit für Agenten auf.
Was OpenShell und NVIDIA Sentry entscheiden
OpenShell weiß, welcher Agent eine Anfrage gestellt hat, welche Richtlinie dabei gilt und ob das Ziel und die Methode zulässig sind. Für zusätzlichen Schutz wird NVIDIA Sentry auf NVIDIA BlueField-4 unter Verwendung von NVIDIA DOCA ausgeführt, um Agenten unabhängig zu überwachen, Richtlinien direkt im Silizium durchzusetzen und Agenten innerhalb von Millisekunden unter Quarantäne zu stellen. Gemeinsam sorgen sie dafür, dass die Entscheidung darüber, ob der Agent handeln darf, außerhalb seiner Kontrolle getroffen wird. Genau das ist der Sinn dieses Designs.
Laufzeitberechtigungen, Verhaltensüberwachung und KI-spezifische Inhaltsprüfung bieten sich ergänzende Schutzebenen. F5 ergänzt die Prüfung unterstützter Prompts, Modellantworten und Tool-Aufrufe auf Prompt-Injection-Angriffe, Jailbreaks und die Offenlegung sensibler Daten und erweitert damit die Laufzeit-Governance von OpenShell sowie die kontinuierliche Verhaltensüberwachung und hardwareisolierte Richtliniendurchsetzung von NVIDIA Sentry.
F5 prüft, was der Agent sendet und empfängt
F5 AI Guardrails prüft unterstützten Datenverkehr, der über den Durchsetzungspfad dorthin geleitet wird. Dazu gehören Prompts, Modellantworten und Tool-Aufrufe, die über von OpenShell kontrollierte Protokolle übertragen werden. Mit den erkannten Inhalten führt die Lösung drei Maßnahmen durch: Sie blockiert Prompt-Injection-Angriffe, Jailbreaks und Tool-Aufrufe, die gegen Richtlinien verstoßen. Sie schwärzt sensible Daten, bevor diese die Umgebung verlassen. Und sie protokolliert jede Entscheidung im Sitzungsprotokoll. Die Ergebnisse und Telemetriedaten stehen OpenShell und NVIDIA Sentry zur Verfügung, sodass eine blockierte Anfrage gemäß den Richtlinien des Betreibers eine Entscheidung auf Agentenebene bis hin zur Eindämmung auslösen kann. Da die Überprüfung im Durchsetzungspfad und nicht im Container des Agenten erfolgt, kann der Agent Guardrails weder deaktivieren noch umgehen. Es gibt keinen Sidecar, der abgeschaltet werden könnte.
F5 AI Red Team stellt sicher, dass die Schutzmechanismen zuverlässig bleiben. Es greift die Agenten und Modelle über denselben Pfad an, den auch ein Benutzer nehmen würde – unabhängig davon, ob sie privat oder öffentlich sind. Die dabei gewonnenen Erkenntnisse fließen in die Richtlinien der Schutzmechanismen ein, sodass die Abwehrmaßnahmen mit den von ihnen kontrollierten Agenten Schritt halten.
Die Kontrolle eines Agenten bedeutet auch, nachweisen zu können, was er getan hat. Die F5-Steuerungsebene enthält das Sitzungsprotokoll: Benutzer, Prompt-Kontext, Tool-Aufrufe und genehmigte Parameter. OpenShell hält seine Richtlinienentscheidungen fest. NVIDIA Sentry enthält das Systemprotokoll: Dateizugriffe, Kernel-Aufrufe und DPU-Paketmetriken. Durch die Korrelation dieser Aufzeichnungen entsteht eine einheitliche Zeitleiste dessen, was das Modell beabsichtigte, was der Agent versuchte und was er tatsächlich tat – basierend auf Quellen, auf die der Agent keinen Zugriff hatte.
Die F5 AI Security Platform-Steuerungsebene und das AI Red Team werden innerhalb der Factory serverseitig ausgeführt. Die von den Agenten aufgerufenen produktiven Inferenzmodelle laufen auf NVIDIA Vera Rubin NVL72. Das AI Red Team nutzt zudem GPU-Ressourcen für Sicherheitstests. AI Guardrails benötigen lediglich eine Arm-CPU und können daher auf NVIDIA Vera und BlueField-4 ausgeführt werden. Die beiden folgenden Referenzarchitekturen zeigen, wo die einzelnen Komponenten angesiedelt sind.
Zwei F5-Referenzarchitekturen auf NVIDIA OpenShell
Auf die drei Ebenen von NVIDIA übertragen: AI Guardrails auf Vera, angewendet auf das Agenten-Framework innerhalb von OpenShell; erneut AI Guardrails auf NVIDIA BlueField-4, außerhalb des Wirkungsbereichs des Agenten, zusammen mit der Datenebene, wenn die Factory sie benötigt; die Steuerungsebene und AI Red Team auf Vera Rubin NVL72 zusammen mit den Modellen. Daraus ergeben sich zwei Referenzarchitekturen. Beide basieren auf der NVIDIA OpenShell Reference Architecture, beide verwenden dieselben Richtlinien und dieselbe Steuerungsebene; der Unterschied besteht darin, was sich im Pfad des Agenten befindet.
Referenzarchitektur 1: F5 AI Guardrails mit NVIDIA OpenShell und NVIDIA Sentry
Für Betreiber, die den NVIDIA-Stack wie vorgesehen einsetzen. F5 AI Guardrails wird unter einer einheitlichen Richtlinie an zwei Stellen ausgeführt: auf NVIDIA Vera, wo es auf das Agenten-Framework innerhalb von OpenShell angewendet wird, und auf der in NVIDIA Sentry integrierten BlueField-4-DPU, auf die der Agent keinen Zugriff hat. Die erste Instanz erfasst die vom Agenten gesendeten Daten unmittelbar beim Senden. Die zweite kann der Agent nicht deaktivieren. Guardrails blockiert, schwärzt und protokolliert den unterstützten, an das System weitergeleiteten Datenverkehr. Auf BlueField stehen die Entscheidungen zudem NVIDIA Sentry zur sofortigen Eindämmung des Agenten zur Verfügung. Zusätzliche Hardware ist nicht erforderlich. Ein NVIDIA Cloud Partner, der auf den NVIDIA-Stack standardisiert, erhält so eine Inhaltsprüfung, ohne weitere Änderungen vornehmen zu müssen.
Für höhere Skalierbarkeit und eine Bereitstellung auf Enterprise-Niveau. F5 BIG-IP Next for Kubernetes wird als Datenebene der Factory auf der NVIDIA BlueField-4 DPU neben NVIDIA Sentry oder auf der Host-CPU ausgeführt; F5 AI Guardrails wird darin unter derselben Richtlinie ausgeführt. NVIDIA Sentry übernimmt die grundlegende Durchsetzung, während BIG-IP Next for Kubernetes den Datenverkehr abwickelt. BIG-IP Next for Kubernetes leitet den Agenten- und Anwendungsdatenverkehr an Modellinstanzen auf Vera Rubin NVL72 weiter und verteilt die Last, wobei es in NVIDIA Dynamo integriert ist. Es isoliert Mandanten, skaliert und sichert Verbindungen über das Model Context Protocol (MCP), steuert die Token-Nutzung pro Mandant und bietet dem Betreiber eine zentrale Übersicht über alle Mandanten und Modelle. BIG-IP Next for Kubernetes wendet außerdem die externen Egress-Richtlinien des Betreibers auf den darüber geleiteten Datenverkehr an und ergänzt damit die Laufzeit-Zugriffskontrollen von OpenShell sowie die Durchsetzung von Infrastrukturrichtlinien durch NVIDIA Sentry.
Die Entscheidung liegt beim Betreiber. Integrieren Sie AI Guardrails in OpenShell und NVIDIA Sentry oder fügen Sie BIG-IP Next for Kubernetes mit integrierten AI Guardrails hinzu. Richtlinien und Steuerungsebene sind bei beiden identisch. Die zweite Option ergänzt Mandantenisolierung, Kontrolle des ausgehenden Datenverkehrs und Traffic-Management für die gesamte Factory.
Eine Kennzahl, die getrennt von der Sicherheitsarchitektur betrachtet wird, da sie separat gemessen wurde. In Tests der Tolly Group mit BIG-IP Next for Kubernetes auf NVIDIA BlueField-3-DPUs (Bericht Nr. 226104, veröffentlicht im März 2026) erzielte BIG-IP Next for Kubernetes einen um 40 % höheren Token-Durchsatz als die getestete Baseline, wobei der Datenpfad von den Host-CPUs ausgelagert wurde. Dabei handelt es sich um eine isolierte Messung der Datenebene von BIG-IP Next for Kubernetes. Die hier beschriebenen Prüffunktionen sind darin nicht enthalten. Bei KI ist Leistung ein Wirtschaftsfaktor.
Sicherheit, die in der Factory verbleibt
Bei einer vollständig selbst gehosteten Bereitstellung verbleiben die F5-Sicherheitsverarbeitung und die Auditprotokolle in der Umgebung des Betreibers: die Steuerungsebene und das Red Team serverseitig bei den Modellen, die Überprüfung auf Vera und BlueField-4. Der Zugriff auf externe Modelle und Dienste unterliegt weiterhin den Unternehmensrichtlinien; die öffentlichen Ziele sind nicht ohne Grund im Diagramm dargestellt. Damit sämtliche Prompts und Antworten innerhalb der KI-Fabrik verbleiben, sind außerdem lokal gehostete Ziele und Beschränkungen für ausgehenden externen Datenverkehr erforderlich. Die Architektur ermöglicht dies. Ob es umgesetzt wird, entscheidet die Richtlinie des Betreibers, und BIG-IP Next for Kubernetes setzt diese Richtlinie für ausgehenden Datenverkehr durch.
Die Ära der KI-Agenten hat weniger eine neue Sicherheitsanforderung geschaffen, als vielmehr den wichtigsten Kontrollpunkt an den ausgehenden Datenverkehr des Agenten verlagert – auf eine Infrastruktur, auf die der Agent keinen Zugriff hat. F5 befasst sich seit drei Jahrzehnten mit genau solchen Datenpfaden. In der NVIDIA OpenShell Reference Architecture ist dies ein Pfad, den der Agent nicht durch geschickte Kommunikation umgehen kann.
Weitere Informationen finden Sie auf unseren Webseiten zu F5 AI Security Platform, F5 AI Guardrails, F5 AI Red Team, und F5 BIG-IP Next for Kubernetes.
Über den Autor
Kunal Anand leitet als Chief Product Officer die Produktorganisation von F5. Er ist für Produktvision, Strategie und Umsetzung verantwortlich und stellt die Entwicklung wegweisender Lösungen sicher, die kritische Herausforderungen bewältigen und außergewöhnliche Kundenerlebnisse schaffen. In seiner vorherigen Funktion als Chief Technology and AI Officer bestimmte Kunal die Technologie- und KI-Strategie sowie die entsprechende Vision des Unternehmens. Vor seiner Zeit bei F5 hatte Kunal bei Imperva die Doppelfunktion des Chief Technology Officer und Chief Information Security Officer inne. Sein Weg zu Imperva begann 2018 mit der Übernahme von Prevoty, einem 2013 von ihm mitgegründeten Start-up für Anwendungssicherheit. Vor seinem Wechsel zu Prevoty war er Director of Technology bei BBC Worldwide. Kunal verfügt über langjährige Innovations- und umfassende technische Erfahrung und leitete bei Gravity, MySpace und dem NASA Jet Propulsion Lab Teams in den Bereichen Sicherheit, Daten, Technologie und Engineering. Kunal verfügt über mehr als 15 Jahre Erfahrung in den Bereichen KI und maschinelles Lernen – von Modelltraining und dem Einsatz KI-gestützter Algorithmen zur Produktoptimierung bis hin zur Konzeption und Implementierung von KI-Architekturen. Kunal hat einen Bachelor-of-Science-Abschluss in Informatik vom Babson College.
Weitere Blogbeiträge von Kunal AnandÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...