Operationalisierung von „Bring Your Own Agent“ auf Red Hat AI, OpenClaw Edition

Die Welt der KI-Agenten ist komplex. Die Teams greifen auf LangChain, LlamaIndex, CrewAI, AutoGen zurück oder erstellen von Grund auf benutzerdefinierte Lösungen. Gut. So sollte es während der kreativen Phase sein. Sobald ein Agent jedoch den Laptop der Entwickler verlässt und mit Produktionsdaten interagiert, externe APIs (Application Programming Interfaces) aufruft oder auf einer gemeinsam genutzten Infrastruktur ausgeführt wird, ist Freiheit ohne Leitplanken keine Funktion mehr, sondern eine Belastung.

Wir haben die Entwicklung in der Branche in verschiedenen Phasen beobachtet: Modell-APIs (wie Chat-Vervollständigungen), agentenbasierte APIs (wie Assistenten und später die OpenAI Responses API), das Zeitalter der Frameworks und jetzt das Zeitalter von Harnesses und Coding Agents. Die oberste Ebene ändert sich ständig. Sie wird austauschbar. Was sich nicht ändert, ist die Diskrepanz zwischen „Es funktioniert auf meinem Laptop“ und „Es läuft sicher, in großem Umfang und mit Audit-Trails in der Produktion“.

Unsere AgentOps-Strategie basiert auf folgendem Kernprinzip: Bring Your Own Agent (BYOA) Die Plattform ist unabhängig vom Framework. Wichtig ist, dass der Agent eine Identität besitzt, nach dem Least Privilege-Prinzip ausgeführt wird, beobachtet wird, Sicherheitsüberprüfungen besteht und im Nachhinein geprüft werden kann. Die Plattform bietet Sicherheit, Governance, Beobachtbarkeit und Lifecycle Management. Der Agent gehört weiterhin Ihnen.

Das bietet Red Hat AI

Diese Reihe gibt einen Einblick, wie BYOA in der Praxis funktioniert, was aktuell verfügbar ist und was als Nächstes entwickelt wird.

Wir nehmen OpenClaw, einen persönlichen KI-Assistenten, der Agenteninteraktionen über Kanäle (WhatsApp, Telegram, Slack, Discord und mehr) über ein zentrales WebSocket-Gateway weiterleitet, und operationalisieren ihn auf Red Hat AI. Wir binden ihn nicht in ein proprietäres Framework ein, sondern in eine Plattforminfrastruktur. OpenClaw ist nur ein Beispiel – dieser Ansatz funktioniert für beliebige Agenten-Runtime.

OpenClaw führt standardmäßig kaum Sandboxing durch. Es erzwingt keine Role-Based Access Control (RBAC), verfolgt keine Tool-Aufrufe und regelt keinen Zugriff auf externe Services. Red Hat AI fügt jede dieser Schichten mithilfe der nativen Funktionen von Red Hat OpenShift und Red Hat OpenShift AI hinzu, ohne den Code des Agenten zu verändern. Im restlichen Teil des Beitrags werden diese einzelnen Schichten erläutert.

Umwandlung von Cloud-nativ in Agenten-nativ

Wir entwickeln keine Agenteninfrastruktur von Grund auf. Wir wandeln die Tools und Deployment-Muster um, die OpenShift bereits bietet, und erweitern sie für agentenbasierte Workloads mit Red Hat AI.

Agenten benötigen Isolation: OpenShift Sandboxed Containers (basierend auf dem Kata Containers-Projekt und einem mehrschichtigen GA-Produkt) und die kommende Agent-Sandbox-Integration bieten eine kernel-isolierte Ausführung pro Agentensitzung. Die Daten des Hosts und anderer Agenten sind vor einem kompromittierten Agenten geschützt.

Agenten benötigen eine Identität: Service-Account-Token mit eingeschränktem Gültigkeitsbereich, mit SPIFFE/SPIRE für kryptografische Workload-Identität. Keine fest codierten Schlüssel. Stattdessen verifiziert die Plattform den Agenten und injiziert kurzlebige Service-Account-Token mit eingeschränktem Gültigkeitsbereich auf Plattformebene. Dies ist mit der Kagenti-Integration für den Agenten-Lifecycle als Teil von Red Hat AI geplant. 

Agenten benötigen Mandantenfähigkeit: Namespace-Isolation, NetworkPolicy, ResourceQuota mit der Verifizierung, dass Grenzen unter adversen Tests standhalten.

Agenten benötigen Policy-Leitplanken auf mehreren Ebenen: OPA/Gatekeeper- und Kyverno-Richtlinien auf Kubernetes-Ebene. Das Model Context Protocol (MCP) Gateway für die Autorisierung auf Tool-Ebene. Der Leitplanken-Orchestrator und NeMo Guardrails an der Modellinferenzgrenze (mehr dazu im nächsten Abschnitt).

Sichere und produktionsbereite Agenten

Für viele Unternehmensteams wird die Sicherheit zum Haupthindernis, um Agenten und Modelle in die Produktion zu bringen. Nicht die Performance. Nicht die Kosten. Vertrauen. Unternehmen benötigen die Gewissheit, dass ihre KI die Vorschriften einhält und ihre Marke vor Reputations- und rechtlichen Risiken schützt, insbesondere wenn sie von externen Nutzenden verwendet wird.

Red Hat AI verfolgt einen ganzheitlichen Sicherheitsansatz, der den gesamten Lifecycle abdeckt – einschließlich Erkennung, Tests und Risikominderung, bevor die Lösungen in die Produktion gehen – und vor Bedrohungen schützt, die während der Laufzeit auftreten.

Bevor ein Agent live geht: Garak (als Teil von Red Hat AI geplant) bietet Adversarial Vulnerability Scanning für Jailbreaks, Prompt Injection und andere Angriffsvektoren auf Modellebene. Die Integration ist über den TrustyAI Operator geplant und kann über EvalHub (eine Control Plane für die Evaluierung) und Kubeflow Pipelines genutzt werden, wodurch Adversarial Scans in CI/CD vor der Promotion ermöglicht werden.

Zur Laufzeit (Leitplanken an der Inferenzgrenze): Der TrustyAI Leitplanken-Orchestrator (allgemein verfügbar ab OpenShift AI 3.0) überprüft Modelleingaben und -ausgaben. NeMo Guardrails (Tech Preview) fügt programmierbare Konversationsleitplanken hinzu. Beide arbeiten an der Inferenzgrenze und fangen einzelne Large Language Model (LLM)-Aufrufe ab, um die Sicherheit zu gewährleisten, bevor eine Antwort den Agenten erreicht. Eine geplante Ansicht der Modellrisiken im Modellkatalog zeigt diese Sicherheitssignale zusammen mit den Modellmetadaten, damit Teams das Risiko von Use Cases berücksichtigen können, bevor sie ein Modell auswählen.

Beobachtbarkeit, Tracing und Evaluierung:

Agenten verhalten sich stochastisch. Sie können sie ohne Ausführungs-Traces nicht debuggen oder ihnen in der Produktion vertrauen.

Red Hat AI bietet die Grundlage für die Beobachtbarkeit von Agenten, beginnend mit First Party-Support für MLflow, der sich derzeit in der Developer Preview befindet und für eine zukünftige Version als General Availability geplant ist. 

MLflow Tracing erfasst Prompts, Reasoning-Schritte, Tool-Aufrufe, LLM-API-Anfragen und Token-Kosten. Alle Traces sind OpenTelemetry-kompatibel, sodass jedes OTEL-kompatible Zielsystem integriert werden kann. Über das Tracing hinaus können MLflow-Funktionen für Scoring und Evaluierung verwendet werden, um die Agentenqualität im Laufe der Zeit zu beurteilen. Diese Workflows sollen über Eval Hub aufgerufen werden, eine Control Plane für die Evaluierung, die Teil von OpenShift AI ist.  

Governance von Tool-Aufrufen in großem Umfang

Agenten rufen Tools auf. Die Frage ist, wie diese Aufrufe gesteuert werden.

Das MCP-Gateway (entwickelt mit dem OpenShift-Netzwerkteam, Envoy-basiert), das sich derzeit in der Developer Preview befindet, ist allen Ihren MCP-Servern als einzelner, sicherer Endpunkt vorgeschaltet. Es bietet außerdem eine identitätsbasierte Tool-Filterung, sodass Agenten nur autorisierte Tools sehen, einen OAuth2-Token-Austausch für eingeschränkten Zugriff pro Backend und ein Credential-Management, damit sensible Tool-Aufrufe die ordnungsgemäße Autorisierung durchlaufen. Die Plattform regelt den Zugriff. Die Anwendung verwaltet Anmeldedaten, sodass es zu keinem serverübergreifenden Datenleck kommt.

Die Autorisierung wird durch die AuthPolicy von Kuadrant erzwungen, die Authorino für die Validierung von JSON Web Token (JWT) und die Auswertung von Open Policy Agent (OPA)-Regeln auf Gateway API-Ebene integriert.

Für OpenClaw bedeutet dies, dass der Agent eine MCP_URL-Umgebungsvariable festlegt und Zugriff auf einen aggregierten Tool-Katalog erhält. Welche Tools tatsächlich aufgerufen werden können, wird durch seine Token-Ansprüche und nicht durch den Prompt bestimmt. Prompt Injection-Angriffe, die versuchen, den Agenten dazu zu bringen, nicht autorisierte Tools aufzurufen, werden auf der Infrastrukturebene gestoppt, da das Gateway Prompt-Inhalte vollständig ignoriert. Es validiert Token-Ansprüche.

Auswahl von API-Oberflächen für Produktionsagenten

Viele Teams begannen mit Chat, wechselten zu Chat-Vervollständigungen und OpenAI-APIs, dann zu Frameworks und jetzt zu Agent Harnesses. Die von Agenten verwendeten APIs konsolidieren sich. Eine der führenden APIs für agentenbasierte Workloads ist die Responses API, und OpenAI hat diese Richtung nun durch die OpenResponses-Spezifikation eröffnet.

Red Hat AI bietet eine Implementierung, die vollständig mit der OpenResponses-Spezifikation konform ist. Dies ermöglicht es Teams, Agenten-Workloads auf selbst gehosteter oder Hybrid Modell-Infrastruktur auszuführen, anstatt jeden Prompt, Tool-Aufruf und jedes Reasoning-Artefakt über Drittanbieterdienste zu leiten.

OpenResponses-kompatible Runtimes für selbst gemanagte und hybride Umgebungen sind weiterhin begrenzt. Red Hat AI bietet eine der ausgereiftesten Implementierungen der Spezifikation, die auf diese Lücke abzielt. Damit ist Red Hat AI ein praktischer Weg für OpenClaw-Benutzer, die das API-orientierte Agentenverhalten von OpenAI Responses beibehalten und gleichzeitig die Ausführung auf eine von ihnen kontrollierte Infrastruktur verlagern möchten.

Für Teams, die einen selbst gehosteten Pfad ohne eine Responses-API-Orchestrierungsebene wünschen, bietet vLLM, ein Teil von Red Hat AI, einen OpenAI-kompatiblen /v1/chat/completions-Endpunkt, den OpenClaw direkt nutzen kann.

Agenten-Lifecycle mit Kagenti

Viele Teams bleiben beim Verschieben eines Agenten vom Laptop in die Produktion stecken. Kagenti, geplant als Teil von OpenShift AI, schließt diese Lücke. Der kagenti-operator erkennt Agents automatisch über A2A-basierte AgentCard-CRDs und injiziert Identität (SPIFFE/SPIRE), Tracing und Tool Governance (MCP-Gateway) ohne Änderungen am Agenten-Code über ein AgentRuntime-Konstrukt vorzunehmen. Der gesamte Lifecycle, von der Discovery bis zur Runtime Governance, wird von der Plattform verwaltet. Ein Agentenkatalog und eine Registry sind neben einem MCP-Katalog für Tool-Server auf der Roadmap für die Benutzeroberfläche von OpenShift AI.

Diese Reihe

Diese Blogreihe führt Sie detailliert durch diese Schichten, wobei OpenClaw als Beispiel für eine Agenten-Runtime dient. Jeder Beitrag ist in sich abgeschlossen. Lesen Sie sie der Reihe nach, oder springen Sie zu dem Punkt, der zu Ihrem aktuellen Problem passt.

Die einzige Konstante in jedem Beitrag ist das BYOA-Prinzip. Wir fordern Sie niemals auf, Ihren Agenten umzuschreiben. Wir bringen strenge unternehmerische Standards in den Agenten ein, und nicht umgekehrt.

Weitere Informationen zum Produkt-Stack von Red Hat AI zum Entwickeln, Evaluieren und Durchsetzen der Sicherheit von KI-Anwendungen finden Sie in der offiziellen Produktdokumentation sowie in den folgenden Upstream-Projekten, die für Red Hat AI AgentOps von zentraler Bedeutung sind:

• vLLM
• MCP-Gateway
• Open Responses/Llama Stack
• Authorino
• Garak
• TrustyAI Service Operator
• NeMo Guardrails
• Kagenti
• Kagenti Operator