À propos du projet

Obot est une plateforme open source pour gérer, sécuriser et gouverner l'écosystème d'IA d'une organisation. Plutôt que d'imposer un client d'IA, un fournisseur de modèles ou un écosystème d'outils unique, elle fournit une infrastructure partagée que les agents de bureau et les outils tels que Claude Code, Codex, Cursor, VS Code, ainsi que d'autres IDE et CLI, peuvent utiliser lorsque cela est pertinent. Architecture La plateforme s'étend sur les appareils des utilisateurs et un serveur Obot central. Sur les appareils, les clients d'IA se connectent aux passerelles Obot, tandis qu'Obot Sentry analyse, audite et applique les politiques sur l'activité d'IA locale. Le CLI Obot permet aux utilisateurs et aux clients d'IA de découvrir, d'installer et de gérer les serveurs MCP et les compétences approuvés. Le serveur Obot fournit des passerelles MCP et LLM, une exécution en bac à sable pour les serveurs MCP et les agents hébergés, la gestion des identités et des accès avec permissions et secrets, des journaux d'audit corrélés, ainsi que des registres MCP et Skills construits sur des catalogues organisés et versionnés dans Git. Il s'intègre aux serveurs MCP distants, aux fournisseurs de LLM, au stockage objet compatible S3, aux fournisseurs Git et aux fournisseurs d'authentification. Capacités principales Passerelle MCP : un point d'entrée unique et gouverné vers chaque serveur MCP auquel un utilisateur peut accéder. Elle peut proxyfier des serveurs hébergés par Obot ou exécutés en externe, créer des serveurs composites exposant des outils sélectionnés de plusieurs serveurs, contrôler l'accès aux serveurs et aux outils par utilisateur ou par groupe de fournisseur d'identité, gérer l'OAuth MCP et les identifiants utilisateur/partagés ainsi que les liaisons de secrets Kubernetes, et inspecter, rejeter ou modifier les requêtes et les réponses via des filtres MCP ou webhook. Passerelle LLM : des points de terminaison compatibles avec les fournisseurs pour les modèles approuvés. Elle connecte les clients externes à OpenAI, Anthropic, Amazon Bedrock, Azure et aux fournisseurs compatibles Generic Responses, conserve les identifiants des fournisseurs à l'intérieur d'Obot, authentifie les clients avec des clés API à portée limitée, restreint les modèles visibles et appelables par utilisateur via des Model Access Policies, et enregistre les requêtes, les réponses, les métadonnées de client et de session, l'utilisation des tokens et le coût estimé des modèles. Serveurs MCP et agents en bac à sable : Obot peut exécuter des agents et des serveurs MCP dans des environnements isolés en dehors du processus principal du serveur, héberger des serveurs MCP npx, uvx et conteneurisés en tant que conteneurs Docker ou charges de travail Kubernetes, exécuter de la même manière des agents hébergés, et appliquer des règles de sortie réseau basées sur le domaine via un fournisseur de politique réseau configuré. Registres MCP et Skills : découverte, installation et gestion centralisées des serveurs MCP et des Agent Skills. Les catalogues peuvent être organisés dans Obot ou indexés à partir de dépôts versionnés dans Git, exposés via l'API standard MCP Registry, publiés auprès des utilisateurs et des clients d'IA, et gouvernés par des politiques d'accès au niveau de l'entrée, du dépôt ou du catalogue. Les identifiants Git gérés de manière centralisée peuvent être réutilisés entre les sources, avec une intégration pour GitHub, GitLab et d'autres fournisseurs Git. CLI et Skill Obot : le CLI met à disposition des utilisateurs et des clients d'IA locaux les serveurs MCP et les compétences approuvés, en prenant en charge la recherche et l'installation des compétences et des serveurs MCP approuvés, l'exécution et la gestion des compétences depuis la ligne de commande, et l'installation de la compétence Obot afin qu'un agent puisse lui-même utiliser le CLI. Obot Sentry : étend la gouvernance à l'activité d'IA directement sur les appareils des utilisateurs (Device Management est actuellement en version bêta). Il enrôle les appareils, inventorie les clients d'IA, les serveurs MCP, les compétences et les plugins installés, installe des hooks pour Claude Code, Codex, Cursor et VS Code, enregistre les appels d'outils locaux aux côtés de l'activité de la passerelle, prend en charge les politiques de surveillance et d'application, et peut être installé manuellement ou déployé via des MDM tels que Microsoft Intune. Gestion des identités et des accès : authentification via les fournisseurs d'identité configurés, rôles et permissions de plateforme, contrôle d'accès pour les serveurs MCP, les outils, les compétences, les modèles et les API administratives, politiques basées sur les utilisateurs ou les groupes de fournisseurs d'identité, identifiants à portée limitée pour les clients d'IA et les charges de travail des agents, et restriction du contenu d'audit sensible selon le rôle. Journaux d'audit et visibilité : activité corrélée entre les serveurs MCP, les fournisseurs de LLM, les charges de travail hébergées et les appareils des utilisateurs, y compris les requêtes et réponses MCP, les requêtes et réponses de la passerelle LLM, l'utilisation des tokens et le coût des modèles, ainsi que les appels d'outils locaux capturés par Sentry. L'activité peut être filtrée par utilisateur, serveur, outil, fournisseur, modèle, client, appareil ou session, l'utilisation suivie entre les utilisateurs et les ressources, et les données d'audit exportées une fois ou selon un calendrier. Pour commencer Pour le développement local ou l'évaluation, Obot s'exécute avec Docker à l'aide d'une seule commande qui mappe le port 8080, monte un volume de données et le socket Docker de l'hôte, active l'authentification et définit un jeton d'amorçage d'au moins six caractères (s'il est omis, Obot en génère un et l'affiche dans les journaux du conteneur). Après avoir ouvert localhost:8080 et s'être connecté avec le jeton d'amorçage, un fournisseur d'authentification est configuré ; un fournisseur de modèles n'est requis que pour la passerelle LLM. Comme la configuration Docker monte le socket Docker de l'hôte afin qu'Obot puisse lancer des serveurs MCP hébergés en tant que conteneurs frères, elle est destinée uniquement au développement, à l'évaluation ou aux environnements mono-locataires de confiance ; un déploiement Kubernetes est recommandé pour les installations de production ou multi-locataires. Un guide d'installation couvre Kubernetes, PostgreSQL externe, le chiffrement, l'authentification et la configuration de production. Processus de conception et communauté Les changements importants commencent sous forme d'Obot Design Proposals afin que l'architecture puisse être discutée avant la mise en œuvre, et les décisions architecturales livrées sont consignées sous forme d'Architecture Decision Records dans le dépôt. La documentation se trouve sur docs.obot.ai et il existe une communauté Discord. Obot est distribué sous licence MIT.