Liberte seus agentes e dê a eles acesso SSH

Toda plataforma moderna oferece ao seu agente as mesmas três opções de integração: um servidor MCP para registrar, uma chave de API para armazenar e atualizar, ou um arquivo de skill para instalar que ensina o agente a fazer as duas primeiras. Algo para configurar. Algo para vazar. Algo que fica desatualizado.

Oberik dá ao seu agente acesso ssh em vez disso.

Não para você, você está atuando como um proxy neste contexto, na verdade dá acesso SSH ao seu agente.

1 ssh ssh.oberik.com

SSH é a superfície que um agente de codificação usa sempre que precisa interagir com Oberik (por exemplo, criar um workspace, definir seu teto de capacidade, gerar tokens, conversar com o agente que hospedamos, etc.). Sem arquivo de configuração, sem token em variável de ambiente, nada instalado. Sua máquina já tem o cliente, e ela já sabe como gerenciar a única credencial envolvida.

Por que não MCP?

Resumindo, o problema da saída.

MCP se tornou o padrão da indústria porque resolveu um problema real. Você escreve uma ferramenta uma vez, e todo agente pode chamá-la da mesma forma. Não somos contra. Oberik carrega seus próprios servidores MCP diretamente no agente que hospedamos, por tenant, e essa é uma boa maneira de um agente alcançar ferramentas. Estamos falando de outra direção aqui: como algo configura a conta em primeiro lugar.

Por mais fácil que seja de usar, o MCP tem uma falha em seu núcleo: quando uma ferramenta é executada, toda a saída é empurrada para o contexto do modelo. O modelo tem que ler tudo. Ele não pode decidir "eu só queria o terceiro campo", pois quando o texto chega, a filtragem já falhou.

MCP suporta filtragem e paginação em princípio. Na prática, alguém tem que construir isso em cada ferramenta e, quando está faltando, o que pode acontecer com frequência graças ao vibe coding, o modelo simplesmente engole o payload bruto e paga por isso em tokens e atenção.

Com SSH, o agente compõe sua própria visão em vez de aceitar a que uma ferramenta lhe entrega.

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)"'

O filtro é executado em um pipe na máquina. Instantâneo, gratuito, exatamente tão estreito quanto o agente queria. O modelo lê uma linha em vez de dez páginas.

Há duas coisas que fazem isso funcionar. Primeiro, toda resposta usa um formato de linha única como {"ok":…, "command":…, "message":…, "data":…}. Isso faz do jq a maneira pretendida de ler a saída, não uma gambiarra.

O modo JSON também evita que a interação interrompa seu fluxo. Se um comando estiver faltando um campo obrigatório, ele informa o que está faltando em vez de abrir um formulário. Se um comando puder ser destrutivo, ele pede para executar novamente com --yes em vez de parar para pedir confirmação.

Para uma linha com vários comandos, coloque format json; no início. Isso define o formato uma vez, então você não precisa repetir a flag.

Há um detalhe que vale a pena saber. A flag deve ficar dentro das aspas. ssh ssh.oberik.com --json 'documents' não funciona porque o ssh trata as opções após o destino como suas próprias. Ele ignora a flag, e o cliente responde com sua própria saída de uso. Como essa saída não menciona nem Oberik nem a flag, pode fazer o host parecer quebrado.

O que estamos tentando dizer aqui é: treinamos esses modelos para usar o computador, deixe-os usar o computador.

Por que não uma API?

Resumindo, o problema da credencial.

Não nos entenda mal, temos uma API no Oberik e ela é boa. É o que seu produto chama em produção, e é o que o próprio gateway SSH chama internamente.

Mas se você olhar para o que ela exige de quem a chama:

1. obter um token
2. armazená-lo
3. atualizá-lo
4. mantê-lo fora dos logs e fora do contexto do modelo.

Cada um desses passos se torna responsabilidade do agente, e o contexto de um agente não é um lugar seguro para um segredo. Qualquer um que já viu um modelo ecoar suas próprias variáveis de ambiente sabe disso. Quer dizer, se você prestar atenção, perceberia que seu agente de codificação favorito age como se fizesse vista grossa por padrão quando detecta uma chave sensível no seu prompt. No entanto, uma chave colada em um agente não fica apenas no histórico do shell; ela também vai para um provedor de modelo, para logs, para qualquer transcrição que o harness mantenha.

A API existe, mas não é o caminho principal que projetamos para os agentes se configurarem sozinhos. Pelo SSH, o agente detém o único tipo de credencial que seu sistema operacional já foi construído para proteger, uma chave SSH, e a metade privada nunca é transmitida. Autenticar no Oberik não coloca nada secreto no contexto do modelo, porque não há nada para colocar lá.

Por que não uma CLI?

Resumindo, o problema da desatualização.

Instalar uma CLI é um compromisso que exige de cada harness de integrador, e não queríamos ser tão ousados, pois estamos apenas dando nossos primeiros passos. Para ser honesto, não queríamos uma CLI, pois ela é basicamente uma cópia congelada do produto. O plano de controle do Oberik ganhará um recurso à medida que recebermos mais feedback, o que significa que, se tivéssemos optado por uma CLI, estaríamos constantemente lançando uma nova versão e pedindo ao usuário para atualizar.

Basicamente, resolvemos isso porque nossa superfície SSH é gerada, não escrita. Cada rota em nosso plano de controle se registra junto com sua descrição, e essa descrição é o comando SSH. Uma rota adicionada ao painel aparece imediatamente pelo SSH, então não precisamos nos preocupar com uma alteração no gateway.

Nada para atualizar, porque nada está instalado.

Por que não uma skill?

Resumindo, o problema das instruções.

A abordagem da moda para qualquer produto voltado para agentes são as skills. Um procedimento escrito que seu agente instala, dizendo a ele como chamar o produto. Skills são genuinamente úteis, mas é essencialmente um arquivo README sofisticado. Uma skill é documentação, não uma capacidade. Ela não dá ao seu agente uma maneira de agir; ele ainda precisa de MCP ou uma API por baixo para fazer qualquer coisa, e você herda esse problema também.

Além disso, uma skill é uma cópia congelada de como usar um produto em movimento. A mesma desatualização de uma CLI. Ela fica no contexto do agente antes que ele tenha feito qualquer coisa, gastando atenção e tokens em instruções que a superfície poderia simplesmente imprimir quando solicitada.

Nossa resposta para "como o agente sabe o que Oberik pode fazer" não é um arquivo que ele instala. É uma chamada para descobrir para o agente:

1$ ssh ssh.oberik.com 'discover'                  # todo comando, seus parâmetros e seus tipos
2$ ssh ssh.oberik.com 'docs'                      # toda página, com o que ela cobre
3$ ssh ssh.oberik.com 'docs search capability'    # as linhas mencionando algo

A superfície se descreve, no momento da conexão, a partir do produto ao vivo. E docs é o mesmo texto que o site de documentação, então nada é um resumo de outra coisa. As instruções nunca podem ficar desatualizadas, porque elas são o produto.

Por que SSH?

Resumindo, resolve todos os cinco problemas de uma vez.

1. Chaves são a credencial que os agentes podem realmente gerenciar. A autenticação por chave SSH tem décadas, é testada em batalha bilhões de vezes e o protocolo verifica a assinatura antes mesmo de olharmos para uma impressão digital. Não sentimos necessidade de reinventar a roda aqui. Apenas paramos de pedir ao modelo para cuidar de um segredo e deixamos a máquina fazer o único trabalho para o qual foi construída.
2. Você permanece no loop sem compartilhar uma senha. Quando o agente ainda não tem uma chave, como durante sua primeira conexão com Oberik, ele inicia um fluxo de login de dispositivo. O agente executa login link, que retorna imediatamente com uma URL e um código e mostra ambos para você. Você abre a URL no seu próprio navegador. A página identifica a impressão digital exata da chave que será anexada, oferece opções para aprovar ou recusar e mostra um código que você pode comparar com o impresso pelo agente. Enquanto isso, o agente executa login wait e aguarda sua decisão. Esses são comandos separados por design. Se um comando gerasse o link e esperasse, o agente mostraria o link apenas após a solicitação ter expirado. Depois que você aprova, a chave é registrada e todas as conexões futuras são autenticadas automaticamente. Você não precisará de outro link. Nenhum segredo é jamais escrito no histórico de chat do agente porque o processo não usa um.
3. A saída é projetada para pipes. Solicite JSON com --json em um comando, ou use format json; uma vez no início de uma linha, e toda resposta retorna como um envelope de linha única. Isso faz do jq '.data[0].name' a maneira pretendida de ler a saída, não uma gambiarra. O filtro é executado na máquina, então o modelo só vê o que resta após a filtragem. Erros usam o mesmo envelope e incluem o status HTTP subjacente. Isso permite que uma nova tentativa distinga um 429 de um 400. Pipes funcionam em ambas as direções também. O gateway não pode ler seu disco, então comandos que aceitam arquivos recebem o nome do arquivo como argumento e leem o conteúdo do arquivo da conexão. Por exemplo, ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf faz o upload do arquivo.
4. Instalação zero. Nada para registrar, nada para armazenar, nada para manter no contexto. Sem servidor MCP na configuração do seu agente, sem token em variável de ambiente, sem CLI no PATH, sem arquivo de skill. Construímos um produto de desenvolvimento, então usamos a ferramenta que já estava lá e que todo agente sabe usar: SSH.
5. Autodescritivo e cuidadoso por design. discover imprime o catálogo completo de comandos. Ele inclui todo comando, seus parâmetros e tipos, e quaisquer requisitos de confirmação. O catálogo é gerado ao vivo a partir do produto. Ele também informa ao cliente quais campos esperam bytes de arquivo em vez de uma string, para que uploads não possam ser adivinhados incorretamente. O que ele não permite é mirar em uma linha pelo seu número. Comandos destrutivos exigem um nome, e o servidor verifica esse nome em relação ao projeto selecionado pela conexão. Se Staging for solicitado enquanto Support Bot estiver selecionado, o servidor retorna um 400 e deixa o workspace intocado.

Nada para ensinar, porque a superfície se ensina.

Veja como é o fluxo de login do Oberik:

Fluxo de Login do Oberik

Uma porta SSH para o seu produto não é um risco?

Essa é uma pergunta justa, mas a realidade é quase o oposto.

O gateway não tem estado ou privilégios próprios. Cada comando é executado através de uma sessão HTTP do plano de controle, exatamente como no aplicativo React. Um cliente SSH, portanto, não pode fazer mais do que a mesma conta pode fazer em um navegador. Se você sair, revogar a chave ou excluir a conta, a alteração entra em vigor imediatamente porque não há mais nada para revogar.

Este terminal está exposto à internet pública, então qualquer um pode se conectar anonimamente. Cada comando é registrado, incluindo a identidade da conexão, endereço IP, chave e resultado. Credenciais nunca são armazenadas. Uma senha inserida com login, ou uma chave de provedor passada através de --values, é substituída por <redacted> antes que o registro seja escrito. O sistema também armazena um hash do comando original para que comandos repetidos possam ser correlacionados sem tornar a credencial recuperável. Os registros são retidos por 30 dias ou 100.000 comandos, o que ocorrer primeiro.

Logins falhos repetidos se tornam mais lentos em vez de acionar um bloqueio. Alguém que esqueceu qual senha usou pode continuar tentando sem muita dificuldade, enquanto um loop de nova tentativa automatizado usando a senha errada se torna progressivamente menos útil. Essa é a troca pretendida.

Resumo

Todo mundo dá ao seu agente uma API, um servidor MCP ou um arquivo de skill. Nós demos a ele um terminal. Acontece que era isso que ele queria.