Libera i tuoi agenti e dai loro accesso SSH

Ogni piattaforma moderna offre al tuo agente le stesse tre opzioni di integrazione: un server MCP da registrare, una chiave API da archiviare e aggiornare, o un file skill da installare che insegna all'agente come fare le prime due cose. Qualcosa da configurare. Qualcosa che perde. Qualcosa che diventa obsoleto.

Oberik offre invece al tuo agente l'accesso ssh.

Non a te, in questo contesto agisci come intermediario, ma dà effettivamente accesso SSH al tuo agente.

1 ssh ssh.oberik.com

SSH è la superficie che un agente di codifica usa ogni volta che deve interagire con Oberik (ad esempio, creare un workspace, impostare il suo limite di capacità, generare token, chattare con l'agente che ospitiamo, ecc.). Nessun file di configurazione, nessun token in una variabile d'ambiente, nulla da installare. La tua macchina ha già il client e sa già come gestire l'unica credenziale coinvolta.

Perché non MCP?

In breve, il problema dell'output.

MCP è diventato lo standard del settore perché ha risolto un problema reale. Scrivi uno strumento una volta e ogni agente può chiamarlo allo stesso modo. Non siamo contrari. Oberik carica i tuoi server MCP direttamente nell'agente che ospitiamo, per tenant, e questo è un buon modo per un agente di raggiungere gli strumenti. Stiamo parlando di un'altra direzione qui: come qualcosa configura l'account in primo luogo.

Per quanto sia facile da usare, MCP ha un difetto al suo interno: quando uno strumento viene eseguito, l'intero output viene inserito nel contesto del modello. Il modello deve leggerlo tutto. Non può decidere "Volevo solo il terzo campo" perché quando il testo arriva, il filtraggio è già fallito.

MCP supporta il filtraggio e la paginazione in linea di principio. In pratica, qualcuno deve implementarlo in ogni strumento e quando manca, cosa che può accadere abbastanza spesso grazie al vibe coding, il modello si ingoia il payload grezzo e paga in token e attenzione.

Con SSH, l'agente compone la propria vista invece di accettare quella che uno strumento gli fornisce.

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

Il filtro viene eseguito in una pipe sulla macchina. Istantaneo, gratuito, esattamente ristretto come voleva l'agente. Il modello legge una riga invece di dieci pagine.

Ci sono due cose che fanno funzionare tutto questo. Primo, ogni risposta usa un formato a riga singola come {"ok":…, "command":…, "message":…, "data":…}. Questo rende jq il modo previsto per leggere l'output, non una soluzione alternativa.

La modalità JSON impedisce anche all'interazione di interrompere il tuo flusso. Se a un comando manca un campo obbligatorio, ti dice cosa manca invece di aprire un modulo. Se un comando potrebbe essere distruttivo, ti dice di rieseguirlo con --yes invece di fermarsi per chiedere conferma.

Per una riga con diversi comandi, metti format json; all'inizio. Questo imposta il formato una volta, così non devi ripetere il flag.

C'è un dettaglio da sapere. Il flag deve andare dentro le virgolette. ssh ssh.oberik.com --json 'documents' non funziona perché ssh tratta le opzioni dopo la destinazione come proprie. Ignora il flag e il client risponde con il proprio output di utilizzo. Poiché quell'output non menziona né Oberik né il flag, può far sembrare l'host rotto.

Quello che stiamo cercando di dire qui è che abbiamo addestrato questi modelli a usare il computer, lasciali usare il computer.

Perché non un'API?

In breve, il problema delle credenziali.

Non fraintenderci, abbiamo un'API in Oberik ed è buona. È ciò che il tuo prodotto chiama in produzione, ed è ciò che il gateway SSH stesso chiama sotto il cofano.

Ma se guardi a cosa chiede a chi la chiama:

1. ottenere un token
2. archiviarlo
3. aggiornarlo
4. tenerlo fuori dai log e dal contesto del modello.

Ognuno di questi passaggi diventa responsabilità dell'agente e il contesto di un agente non è un posto sicuro per un segreto. Chiunque abbia visto un modello fare eco alle proprie variabili d'ambiente lo sa. Voglio dire, se presti attenzione, ti renderesti conto che il tuo agente di codifica preferito si comporta come se facesse finta di niente per impostazione predefinita quando percepisce una chiave sensibile nel tuo prompt. Tuttavia, una chiave incollata in un agente non finisce solo nella cronologia della shell; va anche a un fornitore di modelli, nei log, in qualsiasi trascrizione che l'imbracatura conserva.

L'API c'è, ma non è il percorso principale che abbiamo progettato per gli agenti per configurarsi da soli. Su SSH, l'agente detiene l'unico tipo di credenziale che il tuo sistema operativo era già costruito per proteggere, una chiave SSH, e la metà privata non viene mai trasmessa. Autenticarsi a Oberik non mette nulla di segreto nel contesto del modello, perché non c'è nulla da metterci.

Perché non una CLI?

In breve, il problema dell'obsolescenza.

Installare una CLI è un impegno da chiedere a ogni imbracatura dell'integratore e non volevamo essere così audaci dato che stiamo muovendo i primi passi. Ad essere onesti, non volevamo affatto una CLI perché è fondamentalmente una copia congelata del prodotto. Il piano di controllo di Oberik crescerà con una funzionalità man mano che riceviamo più feedback, il che significa che se fossimo andati con una CLI, saremmo costantemente costretti a pubblicare una nuova versione e chiedere all'utente di aggiornare.

Abbiamo fondamentalmente risolto questo problema perché la nostra superficie SSH è generata, non scritta. Ogni route nel nostro piano di controllo si registra insieme alla sua descrizione e quella descrizione è il comando SSH. Una route aggiunta alla dashboard appare immediatamente su SSH, quindi non dobbiamo preoccuparci di un cambiamento del gateway.

Niente da aggiornare, perché niente è installato.

Perché non una skill?

In breve, il problema delle istruzioni.

L'approccio di tendenza per essere distribuiti con qualsiasi prodotto rivolto agli agenti sono le skill. Una procedura scritta che il tuo agente installa, che gli dice come chiamare il prodotto. Le skill sono genuinamente utili, ma sono essenzialmente un file README elegante. Una skill è documentazione, non una capacità. Non dà al tuo agente un modo per agire; ha ancora bisogno di MCP o di un'API sottostante per fare qualsiasi cosa, e erediti anche quel problema.

Inoltre, una skill è una copia congelata di come usare un prodotto in movimento. La stessa obsolescenza di una CLI. Si trova nel contesto dell'agente prima che l'agente abbia fatto qualsiasi cosa, spendendo attenzione e token su istruzioni che la superficie potrebbe semplicemente stampare quando richiesto.

La nostra risposta a "come fa l'agente a sapere cosa può fare Oberik" non è un file che installa. È una chiamata per scoprire per l'agente:

1$ ssh ssh.oberik.com 'discover'                  # ogni comando, i suoi parametri e i loro tipi
2$ ssh ssh.oberik.com 'docs'                      # ogni pagina, con ciò che copre
3$ ssh ssh.oberik.com 'docs search capability'    # le righe che menzionano qualcosa

La superficie si descrive da sola, al momento della connessione, dal prodotto live. E docs è lo stesso testo del sito di documentazione, quindi nulla è un riassunto di qualcos'altro. Le istruzioni non possono mai diventare obsolete, perché sono il prodotto.

Perché SSH?

In breve, risolve tutti e cinque i problemi contemporaneamente.

1. Le chiavi sono la credenziale che gli agenti possono effettivamente gestire. L'autenticazione con chiave SSH ha decenni, è stata testata miliardi di volte e il protocollo verifica la firma prima ancora che guardiamo un'impronta digitale. Non abbiamo sentito il bisogno di reinventare la ruota qui. Abbiamo semplicemente smesso di chiedere al modello di fare da babysitter a un segreto e abbiamo lasciato che la macchina facesse l'unico lavoro per cui è sempre stata costruita.
2. Rimani nel giro senza condividere una password. Quando l'agente non ha ancora una chiave, ad esempio durante la sua prima connessione a Oberik, avvia un flusso di login del dispositivo. L'agente esegue login link, che restituisce immediatamente un URL e un codice e mostra entrambi a te. Apri l'URL nel tuo browser. La pagina identifica l'esatta impronta digitale della chiave che verrà allegata, ti dà opzioni per approvare o rifiutare e mostra un codice che puoi confrontare con quello stampato dall'agente. Nel frattempo, l'agente esegue login wait e aspetta la tua decisione. Questi sono comandi separati di proposito. Se un comando generasse sia il link che attendesse, l'agente ti mostrerebbe il link solo dopo che la richiesta fosse scaduta. Una volta che approvi, la chiave viene registrata e tutte le connessioni future vengono autenticate automaticamente. Non avrai bisogno di un altro link. Nessun segreto viene mai scritto nella cronologia della chat dell'agente perché il processo non ne usa uno.
3. L'output è progettato per le pipe. Richiedi JSON con --json su un comando, o usa format json; una volta all'inizio di una riga, e ogni risposta torna come un involucro a riga singola. Questo rende jq '.data[0].name' il modo previsto per leggere l'output, non una soluzione alternativa. Il filtro viene eseguito sulla macchina, quindi il modello vede solo ciò che rimane dopo il filtraggio. Gli errori usano lo stesso involucro e includono lo stato HTTP sottostante. Questo permette a un tentativo di distinguere un 429 da un 400. Le pipe funzionano anche in entrambe le direzioni. Il gateway non può leggere il tuo disco, quindi i comandi che accettano file prendono il nome del file come argomento e leggono il contenuto del file dalla connessione. Ad esempio, ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf carica il file.
4. Zero installazione. Niente da registrare, niente da archiviare, niente da tenere nel contesto. Nessun server MCP nella configurazione del tuo agente, nessun token in una variabile d'ambiente, nessuna CLI nel PATH, nessun file skill. Costruiamo un prodotto per sviluppatori, quindi abbiamo usato lo strumento che era già lì e che ogni agente sa usare: SSH.
5. Auto-descrittivo e attento per progettazione. discover stampa il catalogo completo dei comandi. Include ogni comando, i suoi parametri e tipi, e qualsiasi requisito di conferma. Il catalogo è generato live dal prodotto. Dice anche al cliente quali campi si aspettano byte di file invece di una stringa, quindi i caricamenti non possono essere indovinati in modo errato. Ciò che non permette è di puntare a una riga tramite il suo numero. I comandi distruttivi richiedono un nome e il server controlla quel nome rispetto al progetto selezionato dalla connessione. Se viene richiesto Staging mentre è selezionato Support Bot, il server restituisce un 400 e lascia il workspace intatto.

Niente da insegnare, perché la superficie insegna da sola.

Ecco come appare il flusso di login di Oberik:

Flusso di Login di Oberik

Non è un rischio avere una porta SSH nel tuo prodotto?

È una domanda giusta, ma la realtà è quasi l'opposto.

Il gateway non ha stato o privilegi propri. Ogni comando viene eseguito attraverso una sessione HTTP del piano di controllo, proprio come nell'app React. Un client SSH quindi non può fare più di quanto lo stesso account possa fare in un browser. Se esci, revochi la chiave o elimini l'account, la modifica ha effetto immediatamente perché non c'è nient'altro da revocare.

Questo terminale è esposto a internet pubblico, quindi chiunque può connettersi in modo anonimo. Ogni comando viene registrato, inclusi identità di connessione, indirizzo IP, chiave e risultato. Le credenziali non vengono mai archiviate. Una password inserita con login, o una chiave del provider passata tramite --values, viene sostituita con <redacted> prima che il record venga scritto. Il sistema archivia anche un hash del comando originale in modo che i comandi ripetuti possano essere correlati senza rendere recuperabile la credenziale. I record vengono conservati per 30 giorni o 100.000 comandi, a seconda di quale si verifichi prima.

I login falliti ripetuti diventano più lenti invece di attivare un blocco. Qualcuno che ha dimenticato quale password ha usato può continuare a provare senza troppa frizione, mentre un ciclo di tentativi automatici con la password sbagliata diventa progressivamente meno utile. Questo è il compromesso previsto.

TLDR

Tutti gli altri danno al tuo agente un'API, un server MCP o un file skill. Noi gli abbiamo dato un terminale. A quanto pare, era quello che voleva.