Show HN : panorama des outils pour agents IA, registre, scanner et boîte de réception

À la fin septembre, la plupart des discussions sur les agents en entreprise portent sur les tableaux de bord de gouvernance et les plans de contrôle. Les outils sous-jacents arrivent par des canaux plus discrets : les posts Show HN.

Quatre projets y ont fait leur apparition, esquisçant ensemble à quoi ressemble une pile d'agents auto-hébergée assemblée à partir de composants plutôt qu'achetée sous forme de plateforme. Aucun n'est un lancement de produit au sens habituel. Ce sont des dépôts, des binaires uniques et des sites de documentation, publiés avec le code source disponible et, dans la plupart des cas, la promesse explicite que les fonctionnalités intéressantes ne sont pas réservées à un niveau payant.

Un runtime qui veut être le plancher, pas le plafond

Soma, publié sur Show HN le 2 décembre, se décrit dans sa propre documentation comme un runtime open source et auto-hébergeable pour agents IA et workflows, destiné à tous, des startups aux grandes entreprises. La proposition est délibérément sobre : définir des agents et des fonctions MCP dans du code ordinaire, apporter le framework que l'on utilise déjà, et laisser Soma gérer la tolérance aux pannes, la reprise et la tuyauterie associée.

La documentation liste un binaire unique, des endpoints A2A (Agent2Agent) automatiques avec une compatibilité OpenAI Streaming marquée « à venir », un serveur MCP pré-intégré avec des fournisseurs SaaS tiers qui gère le chiffrement et la rotation des identifiants, une interface de débogage des agents et des fonctions MCP, une gestion fine des clés API, une passerelle IA sortante qui intercepte les requêtes vers les fournisseurs de modèles, et une gestion des secrets via KMS local, AWS ou GCP prévu. Le support TypeScript est disponible aujourd'hui ; Python est listé comme à venir, et Rust comme non encore disponible.

Le tableau des plateformes dans la documentation marque macOS, Linux GNU pour x86 et ARM comme disponibles pour TypeScript et Python, avec Windows non pris en charge. La documentation attribue l'absence de support Windows à l'utilisation de sockets Unix dans Rust, et renvoie vers un problème lié plutôt que de promettre une date.

La documentation présente Soma comme « le bas de la pyramide », fournissant les blocs de construction fondamentaux et une expérience développeur, en laissant la logique des agents au framework que l'équipe utilise déjà.

Ce positionnement compte pour les acheteurs en entreprise. Un runtime qui refuse explicitement de posséder la couche framework est plus facile à intégrer dans une évaluation existante qu'une plateforme qui demande une réécriture. Cela signifie aussi que la question du fournisseur passe de « quel framework agent » à « qui opère le runtime », ce qui est un engagement plus restreint.

Un registre d'artefacts qui traite les agents comme un autre format de paquet

Artifact Keeper, publié le 6 février, n'est pas du tout un framework d'agents. C'est un registre d'artefacts auto-hébergé présenté comme un remplacement direct pour JFrog Artifactory et Sonatype Nexus, et son README est inhabituellement direct sur le modèle commercial : pas d'open-core, pas d'édition entreprise, pas de factures surprises.

Le tableau des dépôts liste un backend Rust, Axum, SQLx, PostgreSQL et Wasmtime avec plus de 45 gestionnaires de formats, un tableau de bord web Next.js 15, des applications iOS et macOS SwiftUI, une application Android Jetpack Compose, un CLI Rust prévu, des modules d'infrastructure Helm et Terraform, une spécification OpenAPI 3.1 avec 277 opérations, et un modèle de plugin WASM d'exemple conçu pour le format .unitypackage de Unity. Pour les équipes exécutant des pipelines d'agents, les pièces pertinentes sont les dépôts proxy et virtuels, qui mettent en cache les artefacts depuis npmjs.com, PyPI, Maven Central et Docker Hub à la première requête et résolvent les paquets privés avant les publics, ainsi que la détection de vulnérabilités Trivy, l'analyse SBOM OWASP Dependency-Track, l'audit de conformité OpenSCAP, la signature GPG et PGP avec gestion des clés, et un moteur de politique avec des portes de qualité, des seuils de sévérité et l'application d'un scan avant téléchargement.

La réplication entre pairs utilise un modèle maillé avec des politiques de synchronisation basées sur les étiquettes, des abonnements réactifs et des transferts P2P entre pairs, ce que le README suggère pour placer les caches près des agents de build. L'authentification couvre OpenID Connect, LDAP, SAML 2.0, JWT et jetons API, avec RBAC par dépôt. L'observabilité inclut des métriques Prometheus décrites comme plus de 30 jauges, compteurs et histogrammes ak_*, un traçage OpenTelemetry optionnel avec export OTLP vers Jaeger, Tempo ou Datadog, et des sondes de santé Kubernetes à /livez, /readyz et /healthz.

La prise en main rapide se fait en trois commandes : cloner le dépôt, changer de répertoire, exécuter docker compose up -d, puis visiter localhost:9080. Le déploiement en production pointe vers un dépôt d'infrastructure séparé avec un diagramme Helm, des modules Terraform pour EKS, RDS et S3, ArgoCD GitOps et une pile de monitoring. Les outils de migration depuis JFrog Artifactory sont intégrés et décrits comme une opération en une commande couvrant les dépôts, les artefacts, les utilisateurs et les permissions.

La question de savoir si un registre doit faire partie d'une pile d'agents est légitime. La réponse du README est implicite : les agents produisent et consomment des paquets, des images de conteneur et des artefacts signés, et les mêmes contrôles de chaîne d'approvisionnement qui s'appliquent au code écrit par l'homme s'appliquent à eux.

Un scanner pour les serveurs MCP déjà sur votre machine

Golf Scanner, publié le 8 mars, aborde un problème que la plupart des inventaires d'entreprise ne couvrent pas encore. C'est un CLI gratuit et open source, écrit en Go pur avec trois dépendances, qui découvre les configurations de serveurs MCP sur une machine et exécute des vérifications de sécurité contre eux. Il est livré sous forme d'un binaire statique unique, sans télémétrie et sans compte requis.

La liste de découverte cite sept IDE : Claude Code, Cursor, VS Code, Windsurf, Gemini CLI, Kiro et Antigravity. Le scanner exécute 20 vérifications de sécurité, divisées en neuf hors ligne et onze en ligne, où les vérifications en ligne interrogent OSV, GitHub, npm, PyPI, les registres OCI et le MCP Registry. Chaque serveur reçoit un score de risque de 0 à 100 utilisant un score pondéré par sévérité avec des plafonds durs.

Les vérifications sont concrètes. La sécurité des commandes cherche des motifs d'élévation de privilèges et d'injection shell. Les vérifications des identifiants trouvent des secrets en clair dans les arguments, les URL et les variables d'environnement. L'emplacement des scripts signale les scripts exécutés depuis /tmp ou les répertoires personnel, et les permissions de scripts détectent les fichiers accessibles en écriture par tous. L'isolation des conteneurs signale le mode --privileged, les capacités dangereuses et le partage de l'espace de noms de l'hôte, tandis que les volumes de conteneur signalent les montages du système de fichiers racine, de /etc ou du socket Docker. La liste du registre confirme l'inclusion dans le MCP Registry. Les vulnérabilités interrogent OSV.dev pour les CVE connues et les malwares dans les paquets npm et PyPI. Le typosquatting identifie les paquets de noms similaires, la distribution évalue les métriques de téléchargement et l'âge des paquets, et la confiance GitHub pondère l'activité du dépôt, la licence et le nombre de contributeurs.

Le score est documenté en détail : chaque vérification produit des résultats, la sévérité la plus élevée fixe le score par vérification de 0 à 10, et les scores se combinent par une moyenne pondérée par sévérité avec critique à 10x, élevé à 7.5x, moyen à 5x et note à 1x. Des plafonds durs s'appliquent. Tout résultat critique plafonne le total à 30 ; tout résultat élevé le plafonne à 59.

Le CLI prend des drapeaux y compris --offline, --format table ou json, --json en abrégé, --fail-on avec des seuils de note à critique, --verbose et --quiet. Les codes de sortie sont 0 pour le succès, 1 pour l'absence d'arguments, des commandes inconnues, une violation du seuil --fail-on ou un conflit de drapeaux, et 2 pour les erreurs JSON ou une valeur --fail-on invalide. Une variable d'environnement GITHUB_TOKEN est optionnelle et augmente la limite de débit de l'API GitHub de 60 à 5 000 requêtes par heure.

Une boîte de réception pour le travail qui survit à la conversation

Pizza Bot, publié le 15 septembre, prend l'approche opposée au même problème. Plutôt que de gouverner les agents, il leur donne un endroit où rendre compte. La description GitHub l'appelle une boîte de réception locale d'abord pour les agents IA à long terme, construite avec DeepAgents et LangGraph, et le README indique qu'il a été développé chez Amazon et publié sous licence Apache 2.0.

Le cadrage du README est une file d'attente, pas un chat. Démarrer ou planifier une tâche, s'éloigner, et revenir à un travail terminé dans Non lu et des décisions en attente dans Action. Les agents continuent de travailler quand vous naviguez ailleurs ou vous déconnectez, et seul le processus api-server doit rester actif. Un runtime DeepAgents et LangGraph avec état sert la même expérience React dans Electron et le navigateur, et l'application de bureau, l'application web et le CLI terminal communiquent tous avec l'api-server via HTTP et SSE.

Les exécution à points de contrôle survivent aux déconnexions du client, et les déclencheurs cron ou webhook peuvent démarrer le travail sans une conversation ouverte. Les compétences deviennent des sous-agents à portée d'outil dont la progression apparaît dans un panneau Activité. Les fournisseurs de modèles incluent Amazon Bedrock, Anthropic, Google Gemini, OpenAI, OpenRouter et Ollama. Les approbations humain dans la boucle, la mémoire à long terme, les pièces jointes de fichiers et les notifications de bureau sont décrites comme intégrées au flux de travail.

Sur l'accès, le README est spécifique. L'api-server se lie à 127.0.0.1, et la liaison non boucle nécessite une authentification et un réglage explicite. Les dossiers doivent être accordés individuellement en lecture seule ou en écriture sous Paramètres, et le projet indique qu'il ne reçoit pas d'accès par défaut au répertoire personnel. Les installateurs de bureau sont joints à chaque version avec un fichier SHA256SUMS ; les builds macOS sont signés et notarisés, Windows x64 livre un exécutable d'installation, et les builds Linux x64 et arm64 pour .deb et .rpm sont non signés et doivent être vérifiés contre le fichier de contrôle.

Pris ensemble, les quatre projets ne forment pas une pile. Ils se chevauchent sur les runtimes, et seuls Artifact Keeper et Golf Scanner s'adressent directement aux préoccupations de conformité qui dominent les titres sur les agents en entreprise. Mais ils montrent où le plancher est posé : valeurs par défaut locale d'abord, permissions de fichiers explicites, versions signées, score documenté et licences ouvertes. C'est un discours de vente différent d'un plan de contrôle, et pour certaines équipes, ce sera plus facile à approuver.