Libera a tus agentes y dales acceso SSH

Cada plataforma moderna le ofrece a tu agente las mismas tres opciones de integración: un servidor MCP para registrar, una clave API para almacenar y renovar, o un archivo de skill para instalar que le enseñe al agente cómo hacer las dos primeras. Algo que configurar. Algo que se filtre. Algo que se vuelva obsoleto.

Oberik le da a tu agente acceso SSH en su lugar.

No a ti, tú actúas como un proxy en este contexto, en realidad le da acceso SSH a tu agente.

1 ssh ssh.oberik.com

SSH es la superficie que usa un agente de codificación cada vez que necesita interactuar con Oberik (por ejemplo, crear un workspace, establecer su límite de capacidad, generar tokens, chatear con el agente que alojamos, etc.). Sin archivo de configuración, sin token en una variable de entorno, sin instalar nada. Tu máquina ya tiene el cliente, y ya sabe cómo manejar la única credencial involucrada.

¿Por qué no MCP?

En resumen, el problema del output.

MCP se ha convertido en el estándar de la industria porque resolvió un problema real. Escribes una herramienta una vez, y cada agente puede llamarla de la misma manera. No estamos en contra. Oberik carga tus propios servidores MCP directamente en el agente que alojamos, por inquilino, y esa es una buena forma para que un agente se conecte a herramientas. Pero aquí estamos hablando de otra dirección: cómo algo configura la cuenta en primer lugar.

Por más fácil que sea de usar, MCP tiene una falla en su núcleo: cuando una herramienta se ejecuta, todo el output se introduce en el contexto del modelo. El modelo tiene que leerlo todo. No puede decidir "solo quería el tercer campo" porque para cuando el texto llega, el filtrado ya ha fallado.

MCP admite filtrado y paginación en teoría. En la práctica, alguien tiene que construir eso en cada herramienta y cuando falta, lo que puede suceder bastante seguido gracias al vibe coding, el modelo simplemente se traga el payload crudo y lo paga en tokens y atención.

Con SSH, el agente compone su propia vista en lugar de aceptar la que le entrega una herramienta.

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

El filtro se ejecuta en un pipe en la máquina. Instantáneo, gratuito, exactamente tan específico como el agente quería. El modelo lee una línea en lugar de diez páginas.

Hay dos cosas que hacen que esto funcione. Primero, cada respuesta usa un formato de una sola línea como {"ok":…, "command":…, "message":…, "data":…}. Eso hace que jq sea la forma prevista de leer el output, no una solución alternativa.

El modo JSON también evita que la interacción interrumpa tu flujo. Si a un comando le falta un campo obligatorio, te dice qué falta en lugar de abrir un formulario. Si un comando podría ser destructivo, te dice que lo vuelvas a ejecutar con --yes en lugar de detenerse a pedir confirmación.

Para una línea con varios comandos, pon format json; al principio. Eso establece el formato una vez, para que no necesites repetir la bandera.

Hay un detalle que vale la pena conocer. La bandera debe ir dentro de las comillas. ssh ssh.oberik.com --json 'documents' no funciona porque ssh trata las opciones después del destino como propias. Ignora la bandera, y el cliente responde con su propio output de uso. Como ese output no menciona ni a Oberik ni a la bandera, puede hacer que el host parezca roto.

Lo que intentamos decir aquí es, hemos entrenado a estos modelos para usar la computadora, dejemos que usen la computadora.

¿Por qué no una API?

En resumen, el problema de la credencial.

No malinterpretes, tenemos una API en Oberik y es buena. Es lo que tu producto llama en producción, y es lo que la propia puerta de enlace SSH llama internamente.

Pero si observas lo que le pide al que la llama:

1. obtener un token
2. almacenarlo
3. renovarlo
4. mantenerlo fuera de los registros y del contexto del modelo.

Cada uno de esos pasos se convierte en responsabilidad del agente, y el contexto de un agente no es un lugar seguro para un secreto. Cualquiera que haya visto a un modelo repetir sus propias variables de entorno lo sabe. Quiero decir, si prestas atención, te darías cuenta de que tu agente de codificación favorito actúa como si hiciera la vista gorda por defecto cuando detecta una clave sensible en tu prompt. Sin embargo, una clave pegada en un agente no solo queda en el historial del shell; también va a un proveedor de modelos, a los registros, a cualquier transcripción que mantenga el arnés.

La API está ahí, pero no es el camino principal que diseñamos para que los agentes se configuren solos. A través de SSH, el agente tiene el único tipo de credencial que tu sistema operativo ya estaba diseñado para proteger, una clave SSH, y la mitad privada nunca se transmite. Autenticarse en Oberik no pone ningún secreto en el contexto del modelo, porque no hay nada que poner allí.

¿Por qué no una CLI?

En resumen, el problema de la obsolescencia.

Instalar una CLI es un compromiso que pedirle a cada arnés integrador y no queríamos ser tan audaces ya que apenas estamos dando nuestros primeros pasos. Para ser honestos, no queríamos una CLI en absoluto, ya que es básicamente una copia congelada del producto. El plano de control de Oberik crecerá con una función a medida que recibamos más comentarios, lo que significa que si hubiéramos optado por una CLI, estaríamos constantemente lanzando una nueva versión y pidiendo al usuario que actualice.

Básicamente resolvimos eso porque nuestra superficie SSH se genera, no se escribe. Cada ruta en nuestro plano de control se registra junto con su descripción, y esa descripción es el comando SSH. Una ruta agregada al panel de control aparece a través de SSH inmediatamente, por lo que no necesitamos preocuparnos por un cambio en la puerta de enlace.

Nada que actualizar, porque no hay nada instalado.

¿Por qué no un skill?

En resumen, el problema de las instrucciones.

El enfoque de moda para implementar cualquier producto orientado a agentes son los skills. Un procedimiento escrito que tu agente instala, diciéndole cómo llamar al producto. Los skills son genuinamente útiles, pero es esencialmente un archivo README elegante. Un skill es documentación, no una capacidad. No le da a tu agente una forma de actuar; todavía necesita MCP o una API debajo para hacer cualquier cosa, y también heredas ese problema.

Además, un skill es una copia congelada de cómo usar un producto en movimiento. La misma obsolescencia que una CLI. Ocupa espacio en el contexto del agente antes de que el agente haya hecho algo, gastando atención y tokens en instrucciones que la superficie podría simplemente imprimir cuando se le pregunte.

Nuestra respuesta a "¿cómo sabe el agente lo que Oberik puede hacer?" no es un archivo que instala. Es una llamada para que el agente descubra:

1$ ssh ssh.oberik.com 'discover'                  # cada comando, sus parámetros y sus tipos
2$ ssh ssh.oberik.com 'docs'                      # cada página, con lo que cubre
3$ ssh ssh.oberik.com 'docs search capability'    # las líneas que mencionan algo

La superficie se describe a sí misma, al momento de la conexión, desde el producto en vivo. Y docs es el mismo texto que el sitio de documentación, por lo que nada es un resumen de otra cosa. Las instrucciones nunca pueden volverse obsoletas, porque son el producto.

¿Por qué SSH?

En resumen, resuelve los cinco problemas a la vez.

1. Las claves son la credencial que los agentes realmente pueden manejar. La autenticación con clave SSH tiene décadas de antigüedad, probada en batalla miles de millones de veces y el protocolo verifica la firma antes de que siquiera miremos una huella digital. No sentimos la necesidad de reinventar la rueda aquí. Simplemente dejamos de pedirle al modelo que cuide un secreto y dejamos que la máquina haga el único trabajo para el que siempre fue construida.
2. Tú te mantienes en el circuito sin compartir una contraseña. Cuando el agente aún no tiene una clave, como durante su primera conexión a Oberik, inicia un flujo de inicio de sesión de dispositivo. El agente ejecuta el enlace de inicio de sesión, que regresa inmediatamente con una URL y un código y te muestra ambos. Abres la URL en tu propio navegador. La página identifica la huella digital exacta de la clave que se adjuntará, te da opciones para aprobar o rechazar, y muestra un código que puedes comparar con el impreso por el agente. Mientras tanto, el agente ejecuta la espera de inicio de sesión y espera tu decisión. Estos son comandos separados por diseño. Si un comando generara el enlace y esperara, el agente te mostraría el enlace solo después de que la solicitud hubiera expirado. Una vez que apruebas, la clave se registra y todas las conexiones futuras se inician sesión automáticamente. No necesitarás otro enlace. Ningún secreto se escribe en el historial de chat del agente porque el proceso no usa uno.
3. El output está diseñado para pipes. Solicita JSON con --json en un comando, o usa format json; una vez al principio de una línea, y cada respuesta vuelve como un sobre de una sola línea. Eso hace que jq '.data[0].name' sea la forma prevista de leer el output, no una solución alternativa. El filtro se ejecuta en la máquina, por lo que el modelo solo ve lo que queda después del filtrado. Los errores usan el mismo sobre e incluyen el estado HTTP subyacente. Eso permite que un reintento distinga un 429 de un 400. Los pipes también funcionan en ambas direcciones. La puerta de enlace no puede leer tu disco, por lo que los comandos que aceptan archivos toman el nombre del archivo como argumento y leen el contenido del archivo desde la conexión. Por ejemplo, ssh ssh.oberik.com 'document upload handbook.pdf' < handbook.pdf sube el archivo.
4. Instalación cero. Nada que registrar, nada que almacenar, nada que mantener en el contexto. Sin servidor MCP en la configuración de tu agente, sin token en una variable de entorno, sin CLI en el PATH, sin archivo de skill. Construimos un producto para desarrolladores, así que usamos la herramienta que ya estaba allí y que todo agente sabe usar: SSH.
5. Autodescriptivo y cuidadoso por diseño. discover imprime el catálogo completo de comandos. Incluye cada comando, sus parámetros y tipos, y cualquier requisito de confirmación. El catálogo se genera en vivo desde el producto. También le dice al cliente qué campos esperan bytes de archivo en lugar de una cadena, por lo que las subidas no se pueden adivinar incorrectamente. Lo que no permite es apuntar a una fila por su número. Los comandos destructivos requieren un nombre, y el servidor verifica ese nombre contra el proyecto seleccionado por la conexión. Si se solicita Staging mientras Support Bot está seleccionado, el servidor devuelve un 400 y deja el workspace intacto.

Nada que enseñar, porque la superficie se enseña a sí misma.

Así es como se ve el flujo de inicio de sesión de Oberik:

Flujo de inicio de sesión de Oberik

¿No es una puerta SSH hacia tu producto un riesgo?

Esa es una pregunta justa, pero la realidad es casi lo opuesto.

La puerta de enlace no tiene estado ni privilegios propios. Cada comando se ejecuta a través de una sesión HTTP del plano de control, igual que en la aplicación React. Por lo tanto, un cliente SSH no puede hacer más de lo que la misma cuenta puede hacer en un navegador. Si cierras sesión, revocas la clave o eliminas la cuenta, el cambio surte efecto de inmediato porque no hay nada más que revocar.

Esta terminal está expuesta a internet público, por lo que cualquiera puede conectarse de forma anónima. Cada comando se registra, incluyendo la identidad de la conexión, la dirección IP, la clave y el resultado. Las credenciales nunca se almacenan. Una contraseña ingresada con login, o una clave de proveedor pasada a través de --values, se reemplaza con <redacted> antes de que se escriba el registro. El sistema también almacena un hash del comando original para que los comandos repetidos se puedan correlacionar sin que la credencial sea recuperable. Los registros se conservan durante 30 días o 100,000 comandos, lo que ocurra primero.

Los intentos de inicio de sesión fallidos repetidos se vuelven más lentos en lugar de activar un bloqueo. Alguien que haya olvidado qué contraseña usó puede seguir intentando sin mucha fricción, mientras que un bucle de reintento automatizado que usa la contraseña incorrecta se vuelve progresivamente menos útil. Ese es el equilibrio previsto.

TLDR

Todos los demás le dan a tu agente una API, un servidor MCP o un archivo de skill. Nosotros le dimos una terminal. Resulta que eso es lo que quería.