Mise en œuvre de « Bring Your Own Agent » (BYOA) sur Red Hat AI, édition OpenClaw

Le monde des agents d'IA est complexe. Les équipes utilisent LangChain, LlamaIndex, CrewAI, AutoGen, ou créent des solutions personnalisées à partir de zéro. Bien. C'est ainsi que cela devrait se passer pendant la phase de création. Mais une fois qu'un agent quitte l'ordinateur portable d'un développeur et commence à communiquer avec des données de production, à appeler des interfaces de programmation d'applications (API) externes ou à s'exécuter sur une infrastructure partagée, la liberté sans garde-fous cesse d'être un avantage et devient une responsabilité.

Nous avons observé les évolutions du secteur : Les API de modèles (telles que les complétions de chat), les API d'agents (telles que les assistants et, plus tard, l'API de réponses OpenAI), l'ère des frameworks, et maintenant l'ère des harnais et des agents de codage. La couche supérieure ne cesse de changer. Il devient fongible. Ce qui reste inchangé, c'est l'écart entre « cela fonctionne sur mon ordinateur portable » et « cela fonctionne en production, de manière sécurisée, à l'échelle et avec des pistes d'audit ».

Notre stratégie AgentOps repose sur un principe fondamental : Bring Your Own Agent (BYOA). La plateforme est indépendante des frameworks. L'important est que l'agent ait une identité, fonctionne avec le moindre privilège, soit observé, réussisse les contrôles de sécurité et puisse être audité après coup. La plateforme assure la sécurité, la gouvernance, l'observabilité et la gestion du cycle de vie. L'agent reste le vôtre.

Ce que Red Hat AI fournit

Cette série présente le fonctionnement pratique du BYOA, en abordant ce qui est disponible actuellement et ce que nous construirons par la suite.

Nous prenons OpenClaw, un assistant d'IA personnel qui achemine les interactions avec les agents sur différents canaux (WhatsApp, Telegram, Slack, Discord, etc.) via une passerelle WebSocket centrale, et nous le mettons en œuvre sur Red Hat AI. Nous ne l'intégrons pas dans un framework propriétaire, mais dans une infrastructure de plateforme. OpenClaw n'est qu'un exemple : cette approche fonctionne pour tout environnement d'exécution d'agent.

Par défaut, OpenClaw n'offre pas beaucoup de sandboxing. Il n'impose pas de contrôle d'accès basé sur les rôles (RBAC), de suivi des appels d'outils, ni de contrôle d'accès aux services externes. Red Hat AI ajoute chacune de ces couches à l'aide des fonctionnalités natives de Red Hat OpenShift et de Red Hat OpenShift AI, sans toucher au code de l'agent. La suite de cet article de blog présente chacune de ces couches.

Réaffectation du cloud-native au agent-native

Nous ne construisons pas l'infrastructure d'agent à partir de zéro. Nous réaffectons les outils et les modèles de déploiement dont OpenShift dispose déjà et nous les étendons aux charges de travail d'agents avec Red Hat AI.

Les agents ont besoin d'isolement : Les conteneurs sandbox d'OpenShift (basés sur le projet Kata Containers et sur un produit en couches GA) et l'intégration prochaine de sandbox avec un agent permettent une exécution isolée du noyau par session d'agent. Les données de l'hôte et des autres agents sont protégées contre un agent compromis.

Les agents ont besoin d'une identité : Jetons de compte de service délimités, avec SPIFFE/SPIRE pour l'identité de charge de travail cryptographique. Aucune clé codée en dur. Au lieu de cela, la plateforme vérifie l'agent et injecte des jetons de compte de service délimités et de courte durée au niveau de la plateforme. Ceci est prévu avec l'intégration de Kagenti pour le cycle de vie des agents dans le cadre de Red Hat AI. 

Les agents ont besoin d’une architecture multi-client : Isolement de l'espace de noms, NetworkPolicy, ResourceQuota, avec vérification que les limites sont respectées lors des tests contradictoires.

Les agents ont besoin de garde-fous de politique à plusieurs niveaux : Politiques OPA/Gatekeeper et Kyverno au niveau de Kubernetes. La passerelle MCP (Model Context Protocol) pour l'autorisation au niveau de l'outil. L'orchestrateur de mesures de sécurité et les mesures NeMo à la limite de l'inférence du modèle (plus d'informations à ce sujet dans la section suivante).

Rendre les agents plus sûrs et prêts pour la production

Pour de nombreuses entreprises, la sécurité devient un obstacle majeur à la mise en production des agents et des modèles. Pas les performances. Pas le coût. La confiance. Les entreprises doivent être sûres que leur IA reste conforme aux réglementations et protège leur marque des risques de réputation et juridiques, en particulier une fois qu'elle est utilisée par des utilisateurs externes.

Red Hat AI propose une approche de la sécurité qui couvre l'ensemble du cycle de vie, y compris la détection, les tests et l'atténuation des risques avant qu'ils n'atteignent la production, et protège contre les menaces qui apparaissent lors de l'exécution.

Avant qu'un agent ne soit mis en service : Garak (prévu dans le cadre de Red Hat AI) fournit une analyse contradictoire des vulnérabilités pour les jailbreaks, l'injection d'invites et d'autres vecteurs d'attaque au niveau du modèle. L'intégration est prévue via l'opérateur TrustyAI et utilisable via EvalHub (un plan de contrôle de l'évaluation) et Kubeflow Pipelines, ce qui permet d'effectuer des analyses contradictoires dans les pipelines CI/CD avant la promotion.

Au moment de l'exécution (garde-fous à la limite de l'inférence) : L'Orchestrateur de garde-fous TrustyAI (généralement disponible à partir d'OpenShift AI 3.0) filtre les entrées et les sorties du modèle. NeMo Guardrails (aperçu technologique) ajoute des rails conversationnels programmables. Les deux fonctionnent à la limite de l'inférence, interceptant les appels individuels de grands modèles de langage (LLM) pour assurer la sécurité avant qu'une réponse n'atteigne l'agent. Une vue planifiée des risques liés aux modèles dans le catalogue de modèles affichera ces signaux de sécurité à côté des métadonnées des modèles, afin que les équipes puissent tenir compte des risques liés aux cas d'utilisation avant de choisir un modèle.

Observabilité, traçage et évaluation

Les agents sont stochastiques. Vous ne pouvez pas les déboguer ou leur faire confiance en production sans traces d'exécution.

Red Hat AI fournit les bases de l'observabilité des agents, en commençant par la prise en charge directe de MLflow, qui est actuellement en version préliminaire pour les développeurs et dont la disponibilité générale est prévue dans une prochaine version. 

MLflow Tracing capture les invites, les étapes de raisonnement, les appels d'outils, les demandes d'API LLM et les coûts des jetons. Toutes les traces sont compatibles avec OpenTelemetry, de sorte que tout récepteur compatible OTEL peut s'intégrer. Au-delà du traçage, les fonctionnalités MLflow de notation et d'évaluation peuvent être utilisées pour évaluer la qualité des agents au fil du temps, et il est prévu que ces flux de travail soient invoqués via Eval Hub, un plan de contrôle d'évaluation qui fait partie d'OpenShift AI.  

Gouvernance des appels d'outils à l'échelle

Les agents appellent des outils. La question est de savoir comment gouverner ces appels.

La passerelle MCP (construite avec l'équipe de mise en réseau d'OpenShift et basée sur Envoy), actuellement en version préliminaire pour les développeurs, se trouve devant tous vos serveurs MCP en tant que point de terminaison unique et sécurisé. Elle ajoute un filtrage des outils basé sur l'identité afin que les agents ne voient que les outils autorisés, l'échange de jetons OAuth2 pour un accès étendu par backend et la gestion des informations d'identification afin que les appels d'outils sensibles passent par une autorisation appropriée. La plateforme applique l'accès. L'application gère les informations d'identification, il n'y a donc pas de fuite entre les serveurs.

L'autorisation est appliquée par le biais de la politique d'authentification de Kuadrant, qui intègre Authorino pour la validation des jetons Web JSON (JWT) et l'évaluation des règles Open Policy Agent (OPA) au niveau de l'API de passerelle.

Pour OpenClaw, cela signifie que l'agent définit une variable d'environnement MCP_URL et obtient l'accès à un catalogue d'outils agrégé. Les outils qu'il peut réellement appeler sont déterminés par ses revendications de jetons, et non par l'invite. Les attaques par injection d'invite qui tentent d'amener l'agent à appeler des outils non autorisés sont bloquées au niveau de l'infrastructure, car la passerelle ignore complètement le contenu de l'invite. Elle valide les revendications des jetons.

Choisir les surfaces d'API pour les agents de production

De nombreuses équipes ont commencé avec le chat, puis sont passées aux complétions de chat et aux API OpenAI, puis aux frameworks, et maintenant aux harnais d'agents. Les API que les agents utilisent se consolident. L'une des principales API pour les charges de travail d'agents est l'API Responses, et OpenAI a maintenant ouvert cette voie grâce à la spécification OpenResponses.

Red Hat AI fournit une implémentation entièrement conforme à la spécification OpenResponses. Cela permet aux équipes d'exécuter des charges de travail d'agents sur une infrastructure auto-hébergée ou hybride, plutôt que d'acheminer chaque invite, appel d'outil et artefact de raisonnement via des services tiers.

Les environnements d'exécution compatibles avec OpenResponses pour les environnements autogérés et hybrides restent limités. Red Hat AI fournit l'une des implémentations les plus abouties de la spécification qui cible cette lacune, ce qui en fait une voie pratique pour les utilisateurs d'OpenClaw qui souhaitent préserver le comportement d'un agent orienté vers l'API de réponses d'OpenAI tout en déplaçant l'exécution vers l'infrastructure qu'ils contrôlent.

Pour les équipes qui souhaitent une voie auto-hébergée sans couche d'orchestration de l'API de réponses, vLLM, qui fait partie de Red Hat AI, fournit un point de terminaison /v1/chat/completions compatible avec OpenAI, que OpenClaw peut consommer directement.

Cycle de vie des agents avec Kagenti

De nombreuses équipes ont du mal à transférer un agent d'un ordinateur portable à la production. Kagenti, prévu dans le cadre d'OpenShift AI, comble cette lacune. L'opérateur kagenti découvre automatiquement les agents via les CRD AgentCard basés sur A2A et injecte l'identité (SPIFFE/SPIRE), le traçage et la gouvernance des outils (passerelle MCP) sans modifier le code de l'agent via une construction AgentRuntime. L'ensemble du cycle de vie, de la découverte à la gouvernance de l'exécution, est géré par la plateforme. Le catalogue et le registre des agents figurent sur la feuille de route de l'interface utilisateur d'OpenShift AI, ainsi qu'un catalogue MCP pour les serveurs d'outils.

Cette série

Cette série d'articles de blog vous présente ces couches en détail en utilisant OpenClaw comme exemple d'environnement d'exécution d'agent. Chaque article est autonome. Lisez-les dans l'ordre ou passez directement à ce qui correspond à votre problème actuel.

Le seul élément constant dans chaque article est le principe du BYOA. Nous ne vous demandons jamais de réécrire votre agent. Nous apportons la rigueur de l'entreprise à l'agent, et non l'inverse.

Pour plus d'informations sur la pile de produits Red Hat AI permettant de créer, d'évaluer et d'appliquer la sécurité aux applications d'IA, consultez la documentation officielle du produit ainsi que les projets en amont suivants, essentiels à l'histoire de Red Hat AI AgentOps :

• vLLM
• Passerelle MCP
• Open Responses/Llama Stack
• Authorino
• Garak
• Opérateur de service TrustyAI
• Garde-fous NeMo
• Kagenti
• Opérateur Kagenti