Libérez vos agents et donnez-leur un accès SSH

Chaque plateforme moderne offre à votre agent les trois mêmes options d'intégration : un serveur MCP à enregistrer, une clé API à stocker et à renouveler, ou un fichier de compétence à installer qui apprend à l'agent comment faire les deux premières. Quelque chose à configurer. Quelque chose qui fuit. Quelque chose qui devient obsolète.

Oberik offre à votre agent un accès SSH à la place.

Pas à vous, vous agissez comme un proxy dans ce contexte, il donne en fait un accès SSH à votre agent.

1 ssh ssh.oberik.com

SSH est la surface qu'un agent de codage utilise chaque fois qu'il doit interagir avec Oberik (par exemple, créer un espace de travail, définir son plafond de capacités, générer des jetons, discuter avec l'agent que nous hébergeons, etc.). Pas de fichier de configuration, pas de jeton dans une variable d'environnement, rien à installer. Votre machine possède déjà le client, et elle sait déjà comment gérer l'unique identifiant impliqué.

Pourquoi pas MCP ?

Pour faire court, le problème de sortie.

MCP est devenu la norme de l'industrie parce qu'il a résolu un vrai problème. Vous écrivez un outil une fois, et chaque agent peut l'appeler de la même manière. Nous ne sommes pas contre. Oberik charge vos propres serveurs MCP directement dans l'agent que nous hébergeons, par locataire, et c'est un bon moyen pour un agent de se connecter à des outils. Nous parlons ici d'une autre direction : comment quelque chose configure le compte en premier lieu.

Aussi facile soit-il à utiliser, MCP a un défaut à sa base : lorsqu'un outil s'exécute, la totalité de la sortie est poussée dans le contexte du modèle. Le modèle doit tout lire. Il ne peut pas décider "Je ne voulais que le troisième champ" car au moment où le texte arrive, le filtrage a déjà échoué.

MCP prend en charge le filtrage et la pagination en principe. En pratique, quelqu'un doit intégrer cela dans chaque outil et quand c'est manquant, ce qui peut arriver assez souvent grâce au vibe coding, le modèle avale simplement la charge utile brute et la paie en jetons et en attention.

Avec SSH, l'agent compose sa propre vue au lieu d'accepter celle qu'un outil lui donne.

1$ ssh ssh.oberik.com 'documents --json' | jq -r '.data[].name'
2$ ssh ssh.oberik.com 'audit --limit 20 --json' | jq -r '.data[] | "\(.at) \(.command)"'

Le filtre s'exécute dans un tube sur la machine. Instantané, gratuit, exactement aussi précis que l'agent le souhaitait. Le modèle lit une ligne au lieu de dix pages.

Il y a deux choses qui font que cela fonctionne. Premièrement, chaque réponse utilise un format sur une seule ligne comme {"ok":…, "command":…, "message":…, "data":…}. Cela fait de jq la manière prévue de lire la sortie, et non une solution de contournement.

Le mode JSON empêche également l'interaction d'interrompre votre flux. Si une commande a un champ obligatoire manquant, elle vous indique ce qui manque au lieu d'ouvrir un formulaire. Si une commande pourrait être destructive, elle vous dit de la relancer avec --yes au lieu de s'arrêter pour demander une confirmation.

Pour une ligne avec plusieurs commandes, mettez format json; au début. Cela définit le format une fois, vous n'avez donc pas besoin de répéter le drapeau.

Il y a un détail à connaître. Le drapeau doit être à l'intérieur des guillemets. ssh ssh.oberik.com --json 'documents' ne fonctionne pas car ssh traite les options après la destination comme les siennes. Il ignore le drapeau, et le client répond avec sa propre sortie d'utilisation. Comme cette sortie ne mentionne ni Oberik ni le drapeau, cela peut donner l'impression que l'hôte est cassé.

Ce que nous essayons de dire ici, c'est que nous avons formé ces modèles à utiliser l'ordinateur, laissez-les utiliser l'ordinateur.

Pourquoi pas une API ?

Pour faire court, le problème d'identifiant.

Ne vous méprenez pas, nous avons une API dans Oberik et elle est bonne. C'est ce que votre produit appelle en production, et c'est ce que la passerelle SSH elle-même appelle en coulisses.

Mais si vous regardez ce qu'elle demande à l'appelant :

1. obtenir un jeton
2. le stocker
3. le renouveler
4. le garder hors des journaux et du contexte du modèle.

Chacune de ces étapes devient la responsabilité de l'agent, et le contexte d'un agent n'est pas un endroit sûr pour un secret. Quiconque a regardé un modèle renvoyer ses propres variables d'environnement le sait. Je veux dire, si vous faites attention, vous réaliseriez que votre agent de codage préféré fait comme s'il fermait les yeux par défaut lorsqu'il détecte une clé sensible dans votre invite. Cependant, une clé collée dans un agent ne reste pas seulement dans l'historique du shell ; elle va aussi chez un fournisseur de modèle, dans les journaux, dans toute transcription que le harnais conserve.

L'API est là, mais ce n'est pas la voie principale que nous avons conçue pour que les agents se configurent eux-mêmes. Via SSH, l'agent détient le seul type d'identifiant que votre système d'exploitation était déjà conçu pour protéger, une clé SSH, et la moitié privée ne se transmet jamais du tout. S'authentifier auprès d'Oberik ne met rien de secret dans le contexte du modèle, car il n'y a rien à y mettre.

Pourquoi pas un CLI ?

Pour faire court, le problème d'obsolescence.

Installer un CLI est un engagement à demander à chaque harnais d'intégrateur et nous ne voulions pas être aussi audacieux car nous n'en sommes qu'à nos premiers pas. Pour être honnête, nous ne voulions pas du tout de CLI car c'est essentiellement une copie figée du produit. Le plan de contrôle d'Oberik va s'enrichir d'une fonctionnalité au fur et à mesure que nous recevrons plus de retours, ce qui signifie que si nous étions partis sur un CLI, nous devrions constamment publier une nouvelle version et demander à l'utilisateur de mettre à jour.

Nous avons essentiellement résolu ce problème car notre surface SSH est générée, non écrite. Chaque route de notre plan de contrôle s'enregistre avec sa description et cette description est la commande SSH. Une route ajoutée au tableau de bord apparaît immédiatement via SSH, donc nous n'avons pas à nous soucier d'un changement de passerelle.

Rien à mettre à jour, car rien n'est installé.

Pourquoi pas une compétence ?

Pour faire court, le problème d'instructions.

L'approche tendance pour être livré avec tout produit destiné aux agents est les compétences. Une procédure écrite que votre agent installe, lui indiquant comment appeler le produit. Les compétences sont vraiment utiles, mais c'est essentiellement un fichier README sophistiqué. Une compétence est de la documentation, pas une capacité. Elle ne donne pas à votre agent un moyen d'agir ; il a toujours besoin de MCP ou d'une API en dessous pour faire quoi que ce soit, et vous héritez aussi de ce problème.

En plus de cela, une compétence est une copie figée de la façon d'utiliser un produit en évolution. La même obsolescence qu'un CLI. Elle se trouve dans le contexte de l'agent avant que l'agent n'ait rien fait, dépensant de l'attention et des jetons sur des instructions que la surface pourrait simplement imprimer lorsqu'on le lui demande.

Notre réponse à "comment l'agent sait-il ce qu'Oberik peut faire" n'est pas un fichier qu'il installe. C'est un appel à découvrir pour l'agent :

1$ ssh ssh.oberik.com 'discover'                  # chaque commande, ses paramètres et leurs types
2$ ssh ssh.oberik.com 'docs'                      # chaque page, avec ce qu'elle couvre
3$ ssh ssh.oberik.com 'docs search capability'    # les lignes mentionnant quelque chose

La surface se décrit elle-même, au moment de la connexion, à partir du produit en direct. Et docs est le même texte que le site de documentation, donc rien n'est un résumé d'autre chose. Les instructions ne peuvent jamais devenir obsolètes, car elles sont le produit.

Pourquoi SSH ?

Pour faire court, cela résout les cinq problèmes à la fois.

1. Les clés sont l'identifiant que les agents peuvent réellement détenir. L'authentification par clé SSH a des décennies, a été éprouvée des milliards de fois et le protocole vérifie la signature avant que nous ne regardions jamais une empreinte. Nous n'avons pas ressenti le besoin de réinventer la roue ici. Nous avons simplement arrêté de demander au modèle de surveiller un secret et laissé la machine faire le seul travail pour lequel elle a toujours été conçue.
2. Vous restez dans la boucle sans partager de mot de passe. Lorsque l'agent n'a pas encore de clé, par exemple lors de sa première connexion à Oberik, il lance un flux de connexion par appareil. L'agent exécute le lien de connexion, qui renvoie immédiatement une URL et un code et vous montre les deux. Vous ouvrez l'URL dans votre propre navigateur. La page identifie l'empreinte exacte de la clé qui sera attachée, vous donne des options pour approuver ou refuser, et affiche un code que vous pouvez comparer avec celui imprimé par l'agent. Pendant ce temps, l'agent exécute l'attente de connexion et attend votre décision. Ce sont des commandes séparées par conception. Si une seule commande générait le lien et attendait, l'agent vous montrerait le lien seulement après l'expiration de la demande. Une fois que vous approuvez, la clé est enregistrée et toutes les connexions futures sont automatiquement connectées. Vous n'aurez pas besoin d'un autre lien. Aucun secret n'est jamais écrit dans l'historique de chat de l'agent car le processus n'en utilise pas.
3. La sortie est conçue pour les tubes. Demandez du JSON avec --json sur une commande, ou utilisez format json; une fois au début d'une ligne, et chaque réponse revient sous forme d'enveloppe sur une seule ligne. Cela fait de jq '.data[0].name' la manière prévue de lire la sortie, et non une solution de contournement. Le filtre s'exécute sur la machine, donc le modèle ne voit que ce qui reste après le filtrage. Les erreurs utilisent la même enveloppe et incluent le statut HTTP sous-jacent. Cela permet à une nouvelle tentative de distinguer un 429 d'un 400. Les tubes fonctionnent aussi dans les deux sens. La passerelle ne peut pas lire votre disque, donc les commandes qui acceptent des fichiers prennent le nom du fichier comme argument et lisent le contenu du fichier à partir de la connexion. Par exemple, ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf télécharge le fichier.
4. Installation zéro. Rien à enregistrer, rien à stocker, rien à garder en contexte. Pas de serveur MCP dans la configuration de votre agent, pas de jeton dans une variable d'environnement, pas de CLI dans le PATH, pas de fichier de compétence. Nous construisons un produit de développement, donc nous avons utilisé l'outil qui était déjà là et que chaque agent sait utiliser : SSH.
5. Auto-descriptif et prudent par conception. discover imprime le catalogue complet des commandes. Il inclut chaque commande, ses paramètres et types, et toute exigence de confirmation. Le catalogue est généré en direct à partir du produit. Il indique également au client quels champs attendent des octets de fichier au lieu d'une chaîne, donc les téléchargements ne peuvent pas être devinés incorrectement. Ce qu'il ne permet pas, c'est de cibler une ligne par son numéro. Les commandes destructives nécessitent un nom, et le serveur vérifie ce nom par rapport au projet sélectionné par la connexion. Si Staging est demandé alors que Support Bot est sélectionné, le serveur renvoie un 400 et laisse l'espace de travail intact.

Rien à enseigner, car la surface s'enseigne elle-même.

Voici à quoi ressemble le flux de connexion Oberik :

Flux de connexion Oberik

Une porte SSH dans votre produit n'est-elle pas un risque ?

C'est une question légitime, mais la réalité est presque l'inverse.

La passerelle n'a aucun état ou privilège propre. Chaque commande s'exécute via une session HTTP du plan de contrôle, exactement comme dans l'application React. Un client SSH ne peut donc pas faire plus que ce que le même compte peut faire dans un navigateur. Si vous vous déconnectez, révoquez la clé ou supprimez le compte, le changement prend effet immédiatement car il n'y a rien d'autre à révoquer.

Ce terminal est exposé à l'internet public, donc n'importe qui peut se connecter de manière anonyme. Chaque commande est journalisée, y compris l'identité de la connexion, l'adresse IP, la clé et le résultat. Les identifiants ne sont jamais stockés. Un mot de passe saisi avec login, ou une clé de fournisseur passée via --values, est remplacé par <redacted> avant que l'enregistrement ne soit écrit. Le système stocke également un hachage de la commande d'origine afin que les commandes répétées puissent être corrélées sans rendre l'identifiant récupérable. Les enregistrements sont conservés pendant 30 jours ou 100 000 commandes, selon la première éventualité.

Les échecs de connexion répétés deviennent plus lents au lieu de déclencher un verrouillage. Quelqu'un qui a oublié quel mot de passe il a utilisé peut continuer à essayer sans trop de friction, tandis qu'une boucle de nouvelle tentative automatisée utilisant le mauvais mot de passe devient progressivement moins utile. C'est le compromis voulu.

TLDR

Tous les autres donnent à votre agent une API, un serveur MCP ou un fichier de compétence. Nous lui avons donné un terminal. Il s'avère que c'est ce qu'il voulait.