HTTP o SSH para agentes de IA: reduce el alcance de una brecha

Un agente de IA debería usar HTTP cuando un servicio pueda expresar la acción prevista como una operación limitada y autenticada. Solo debería usar SSH cuando el trabajo necesite una capacidad del sistema que una API no pueda ofrecer, y siempre mediante una cuenta y una superficie de comandos diseñadas para ese único trabajo.

El error habitual consiste en comparar ambos transportes como si uno fuera moderno y el otro antiguo. Esa no es la decisión importante. HTTP y SSH son mecanismos de entrega. La autoridad que les asignes, las entradas que aceptes y las evidencias que conserves determinan si un agente puede hacer un cambio acotado o recorrer un host de producción con privilegios de administrador.

He visto equipos emitir una clave SSH supuestamente temporal porque un agente necesitaba un único dato operativo. Un mes después, la clave podía leer secretos de despliegue, acceder a servicios internos y abrir un shell interactivo. Nadie había tomado una decisión de seguridad dramática. Simplemente habían aceptado una opción cómoda por defecto. Así es exactamente como una tarea pequeña adquiere un gran alcance de daño.

La interfaz determina la autoridad que recibe un agente

HTTP o SSH para agentes de IA es una cuestión de forma de las capacidades, no de preferencia por un protocolo. Una llamada HTTP puede ser amplia y peligrosa, mientras que una conexión SSH puede estar muy limitada. En la práctica, las API suelen ofrecer un lugar más útil para restringir la autoridad, porque un endpoint, un método, un esquema de solicitud y los permisos de un token pueden describir una única operación.

Considera la instrucción «reinicia el worker que ha fallado». Un endpoint HTTP como POST /workers/worker-17/restart indica el objetivo y el verbo permitido. El servicio puede rechazar un worker desconocido, exigir un rol que permita reinicios y escribir un registro asociado al token. Una instrucción de shell como ssh host sudo systemctl restart worker implica una autoridad más amplia. Depende de que sean correctos la cuenta, la configuración de sudo, las reglas de nombres de unidades, el análisis del shell y el estado del host.

Eso no hace que la API sea segura automáticamente. Un token que pueda llamar a todos los endpoints, crear otros tokens o exportar todos los registros tiene un gran alcance de daño detrás de una URL ordenada. Del mismo modo, un comando SSH forzado que acepte un identificador fijo de worker de una lista permitida puede ser más limitado que una API administrativa mal diseñada.

Antes de conectar cualquiera de las dos herramientas, aplica esta prueba: escribe en una frase la acción mínima que debe tener éxito y después enumera qué más puede hacer la misma credencial si el agente genera una entrada inesperada. Si no puedes explicar la segunda parte, todavía no has medido la autoridad.

Una interfaz limitada tiene cuatro propiedades:

• Nombra un conjunto pequeño de objetivos, no todo un entorno.
• Acepta entradas estructuradas con una gramática que se pueda validar.
• Rechaza las acciones adyacentes que la tarea actual no necesita.
• Crea un registro que permita a otra persona explicar el resultado más adelante.

La tarea también debe determinar cuánto tiempo vive la credencial. Una credencial usada en una sola ejecución no debería convertirse silenciosamente en acceso permanente porque nadie recordó eliminarla. La duración del proceso es un límite mejor que un recordatorio en el calendario.

HTTP ofrece límites útiles solo cuando la API los aplica

HTTP reduce el alcance de daño de un agente cuando el servicio comprueba la autorización a nivel de recurso y operación. Un bearer token es solo un medio de transporte. Su seguridad depende de lo que el servidor verifica después de recibirlo.

RFC 9110 describe los métodos HTTP según su semántica, incluida la diferencia entre métodos seguros e idempotentes. Este lenguaje ayuda con los reintentos y la intención, pero no concede permisos. Un GET puede revelar material sensible. Un PUT puede ser idempotente y aun así sobrescribir una configuración de producción. Trata los nombres de los métodos como indicios para el comportamiento del cliente, no como un modelo de permisos.

Antes de entregar un token a un agente, haz estas preguntas al responsable del servicio:

• ¿Qué rutas y métodos exactos puede llamar este token?
• ¿El servicio comprueba el acceso en cada recurso o solo en la colección general?
• ¿El token puede crear credenciales, cambiar permisos o activar exportaciones?
• ¿Una solicitud puede pasar a otro tenant, proyecto o entorno mediante un identificador?
• ¿El servicio registra la identidad de la credencial y el resultado de la solicitud?

La pregunta incómoda es si un permiso de lectura filtra más información de la que necesita la tarea. Una API de repositorios puede permitir que un token de lectura obtenga código fuente, comentarios de pull requests, logs de compilación y configuración. Un único valor de configuración almacenado de forma incorrecta puede hacer que el acceso de lectura equivalga al acceso a secretos. Si el agente solo necesita el estado de un despliegue, dale un endpoint que devuelva ese estado. No le entregues un token general del repositorio y llames a eso mínimo privilegio.

El esquema de la solicitud importa tanto como su alcance. Compara estas dos solicitudes:

POST /v1/releases/release-42/promote HTTP/1.1
Authorization: Bearer token-value
Content-Type: application/json

{"environment":"staging"}

POST /v1/admin/execute HTTP/1.1
Authorization: Bearer token-value
Content-Type: application/json

{"operation":"promote","arguments":{"environment":"staging"}}

Ambas pueden promover una versión. La primera deja al servidor poco margen para interpretar la operación. La segunda crea un despachador administrativo. Los despachadores atraen excepciones, después nombres de operaciones arbitrarios y finalmente un token cuya autoridad real resulta difícil de describir. Los evito para el uso con agentes, salvo que el servidor aplique una lista estricta de operaciones permitidas y valide por separado el esquema de argumentos de cada operación.

Usa credenciales distintas para verbos distintos cuando el servicio lo permita. Separa la observación de la mutación, y las mutaciones rutinarias de los cambios de identidad o facturación. Esto requiere más preparación, pero hace que los fallos de autorización tengan sentido. Una denegación te dice que la definición de la tarea y la credencial no coinciden. Un token amplio convierte cada error en una solicitud aceptada que tendrás que investigar después.

No pongas un secreto de API de larga duración en el prompt de un agente, un archivo de entorno, la configuración de un repositorio o la configuración de una herramienta. El problema no es solo que se revele accidentalmente en la salida. Los agentes inspeccionan su entorno, las herramientas recopilan diagnósticos y un proceso con acceso al texto sin cifrar puede enviar el secreto a otro destino. Mantén el secreto fuera del proceso del agente y autoriza en su lugar la acción resultante.

SSH expone el host si no eliminas deliberadamente el shell

SSH tiene un gran alcance de daño predeterminado porque una cuenta interactiva puede inspeccionar archivos, ejecutar programas, cambiar configuraciones, abrir túneles y usar todas las rutas de red disponibles para esa cuenta. El hecho de que pretendas ejecutar un único comando no restringe una cuenta que recibe un shell normal.

RFC 4251 describe SSH como un protocolo para el inicio de sesión remoto seguro y otros servicios de red seguros. Admite deliberadamente sesiones, canales, reenvío de puertos y varios métodos de autenticación. Esas capacidades son útiles para los administradores. Son un punto de partida deficiente para un actor autónomo que necesita una única operación de mantenimiento limitada.

El comando también importa. systemctl restart service-name parece acotado hasta que rastreas la autoridad que lo rodea: qué unidades puede reiniciar la cuenta, si los archivos de unidad pueden ejecutar hooks privilegiados, si la cuenta puede editar esos archivos y si los nombres de los servicios proceden de entradas validadas. Un comando que parece operativo puede llegar a credenciales de despliegue, volúmenes montados o un plano de control interno a través del servicio que reinicia.

Si SSH es necesario, crea un programa remoto pequeño con una gramática de entrada cerrada. El programa debe asignar campos de solicitud conocidos a operaciones conocidas. No debe concatenar una solicitud en un comando de shell. Evita aceptar rutas de archivos, nombres de host, expresiones regulares, fragmentos de shell o asignaciones de entorno, salvo que el programa valide cada uno con una lista de permitidos estricta.

Una entrada restringida de authorized_keys puede hacer visible ese límite. El siguiente patrón fuerza un único programa receptor y elimina varias funciones de SSH que los agentes rara vez necesitan:

command="/usr/local/libexec/agent-maintenance",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIexample agent-runner

Esta línea no resuelve por sí sola la autorización. El programa agent-maintenance debe rechazar subcomandos desconocidos y validar sus argumentos. La cuenta del sistema operativo solo debe tener los permisos de archivo, servicio y red que el programa necesite. Si el programa invoca sudo, su regla de sudo debe nombrar un ejecutable fijo y no permitir rutas de escape mediante editores, intérpretes, comodines o shells.

El manual de authorized_keys de OpenSSH documenta command=, no-pty y las restricciones de reenvío. Trata estas opciones como un cinturón de seguridad, no como el vehículo. Eliminan varias vías de escape sencillas, pero un comando forzado que se ejecute con una cuenta sobredimensionada seguirá teniendo acceso sobredimensionado.

Un protocolo remoto útil puede consistir en JSON sencillo por la entrada estándar:

{"action":"restart_worker","worker":"worker-17","request_id":"8b4f3c2a"}

El receptor solo debe aceptar restart_worker y nombres de worker de su propio inventario. Debe escribir un evento antes de ejecutar, invocar un programa fijo sin shell, capturar el código de salida y escribir un evento de finalización. Si el agente envía worker-17; cat /etc/shadow, la validación debe rechazar el valor completo antes de que se ejecute cualquier comando del sistema operativo.

No des acceso SSH a un agente solo porque una persona ya use SSH para el mismo trabajo. Las personas pueden reconocer un prompt extraño, detectar que el nombre del host no coincide y detenerse después de un resultado inesperado. Los agentes necesitan que la restricción esté integrada en la interfaz.

Los logs deben explicar la acción intentada y el estado resultante

Una línea de log que diga «la solicitud falló» no es un registro de auditoría. Puede bastar para depurar una biblioteca cliente, pero no permite determinar si un agente cambió algo, si una persona lo aprobó o qué se debe inspeccionar después de un incidente.

Para HTTP, registra la identidad de la ejecución del agente, la identidad o etiqueta de la credencial, el host de destino, el método, la ruta normalizada, una representación segura del cuerpo de la solicitud, el estado de la respuesta, el valor de correlación, la hora de inicio y el resultado final. Redacta los secretos y campos sensibles antes de que el evento salga del límite de acción. Registrar el encabezado Authorization para conservar pruebas es provocar una brecha por cuenta propia.

Para SSH, registra la identidad del host, la cuenta remota, el nombre del comando forzado, los argumentos validados, la identidad del proceso de origen, el código de salida, la clasificación del error estándar y el identificador de la operación remota. Una cadena de comando sin procesar es una prueba débil porque puede ocultar el comportamiento de las comillas y no indica qué argumentos aceptó el receptor.

La secuencia de eventos debe distinguir la intención del efecto. Esta estructura funciona con ambos transportes:

{"event":"authorization_granted","run":"r-204","action":"restart_worker","target":"worker-17"}
{"event":"action_started","run":"r-204","transport":"ssh","operation":"restart_worker","request_id":"8b4f3c2a"}
{"event":"action_finished","run":"r-204","outcome":"success","remote_status":0,"request_id":"8b4f3c2a"}

Si una conexión se interrumpe después de action_started, escribe outcome:"unknown" en lugar de inventar un fallo. Esa palabra obliga a tomar la siguiente medida correcta: consultar el estado remoto antes de reintentar. También hace que una investigación posterior sea honesta.

Los logs normales tienen además un problema de custodia. Un administrador del host o un proceso que obtenga suficiente acceso puede truncarlos, reescribirlos o eliminarlos. La recopilación centralizada ayuda, pero aun así puede haber huecos cuando falla el recolector o la ruta de red. Si el log debe resolver disputas sobre las acciones de un agente, conserva registros orientados a anexar, con comprobaciones de integridad, y verifícalos fuera de la ruta de acción.

Una cadena de hashes permite detectar modificaciones cuando cada evento incorpora el resumen del evento anterior. No demuestra que el registrador haya visto todos los eventos ni hace confiable un reloj que no lo es. Esos límites importan. La cadena responde a una pregunta más concreta y útil: ¿alguien alteró posteriormente esta secuencia conservada?

Sallyport mantiene un diario Sessions para las ejecuciones de los agentes y un diario Activity para las llamadas individuales, ambos proyectados desde un log de auditoría cifrado y encadenado mediante hashes. Su comando sp audit verify comprueba esa cadena sin conexión sobre el texto cifrado, una propiedad adecuada cuando necesitas inspeccionar pruebas sin exponer primero los secretos.

Los tiempos de espera crean resultados desconocidos, no acciones fallidas

Los fallos de red son el punto en el que equipos cuidadosos provocan cambios duplicados. El cliente envía una solicitud, el lado remoto realiza el trabajo y la respuesta desaparece. El agente ve un tiempo de espera y ejecuta la acción otra vez. Con SSH, la misma secuencia puede ocurrir después de que el comando remoto empiece, pero antes de que el cliente reciba su código de salida.

No permitas que un agente interprete un error de transporte como permiso para reintentar una mutación. Primero clasifica la operación.

Una operación es idempotente solo cuando repetir la misma solicitud produce el mismo estado previsto sin un efecto adicional. Establecer en running el estado deseado de un worker concreto puede cumplir esa definición. Crear un pago, añadir un registro, rotar un secreto o reiniciar un proceso normalmente no. Un reinicio puede interrumpir una secuencia de recuperación que el primer intento ya haya iniciado.

Usa un identificador de idempotencia cuando la API lo admita. El servicio debe conservar el identificador junto con el efecto completado y devolver el resultado anterior ante un duplicado. Un identificador de solicitud proporcionado por el cliente que el servidor solo registra no evita la duplicación.

Para los comandos remotos, añade una operación de estado que pueda responder a una pregunta precisa. Después de una respuesta fallida a restart_worker, consulta la generación actual del worker, el último identificador de solicitud de reinicio y su estado de salud. Si el receptor guarda el identificador de solicitud antes de ejecutar y lo devuelve con el estado, puede decirle a un agente que reintenta si la solicitud ya se ejecutó.

Esta secuencia de fallo muestra por qué importa:

1. El agente envía un reinicio para worker-17 con el identificador de solicitud 8b4f3c2a.
2. El receptor registra el identificador y reinicia el worker.
3. La conexión SSH se interrumpe mientras el worker se detiene.
4. El agente solicita el estado en lugar de reiniciar otra vez.
5. La respuesta de estado indica que el mismo identificador sigue en curso, así que el agente espera y comprueba la salud.

Un límite de reintentos no resuelve los resultados ambiguos. Limita el daño después de tomar la decisión de reintento equivocada. Observar el estado corrige la decisión en sí.

HTTP tiene otro riesgo: a veces los servicios devuelven un estado de éxito antes de que termine el trabajo asíncrono. Un 202 Accepted significa que el servidor aceptó el trabajo para procesarlo más tarde, no que el estado solicitado ya exista. Exige un recurso de operación o un endpoint de estado y haz que el agente espere el resultado terminal relevante para la tarea.

SSH tiene una trampa equivalente cuando un comando envía el trabajo al segundo plano y termina con código cero. No trates un código de salida cero del lanzador como prueba de que la acción de mantenimiento ha terminado. Haz que el receptor espere a que finalice o devuelva un identificador de operación duradero que el agente pueda consultar.

Un comando de shell oculta más autoridad de la que revela su texto

El comando remoto más corto suele tener la autoridad oculta más amplia. La expansión del shell, la herencia del entorno, los directorios actuales, los archivos de configuración y las rutas de búsqueda de ejecutables influyen en lo que se ejecuta. Un agente puede producir un texto aparentemente inofensivo que desencadene un resultado inesperado porque el host lo interpreta en su contexto.

Evita este patrón:

ssh ops@host "deploy $branch $environment"

Aunque hoy el llamador cite correctamente las variables, el shell remoto analiza un lenguaje de comandos. El script de despliegue puede hacer sus propias expansiones. El nombre de una rama puede elegir una ubicación de origen. El nombre de un entorno puede seleccionar credenciales o un clúster de destino. Debes inspeccionar cada capa antes de afirmar que la entrada está limitada.

Usa un receptor que lea entradas estructuradas e invoque directamente un ejecutable fijo. En la mayoría de los lenguajes eso significa un array de argumentos, no una cadena pasada a sh -c. El receptor debe controlar la correspondencia entre un nombre de destino visible para el usuario y un identificador específico del host. No hagas que el agente descubra rutas del sistema de archivos o nombres de unidades de servicio.

La misma preocupación se aplica a los parámetros HTTP. Una ruta como /files?path=... puede parecer estructurada mientras el servidor pasa el valor a una operación del sistema de archivos. Una API solo reduce el riesgo cuando el servidor valida el significado, no cuando traslada el análisis de comandos detrás de una URL.

La ubicación de las credenciales cambia las consecuencias de que un proceso de agente quede comprometido. Si un agente almacena localmente una clave privada SSH o un token de API, cualquier proceso que pueda leer ese material podrá actuar más tarde sin el agente. Un límite de acción separado puede guardar el secreto y pasar al servicio remoto solo una solicitud junto con una decisión de autorización. La diferencia es clara: ocultar un secreto de la salida del modelo no equivale a mantenerlo fuera del proceso del agente.

Sallyport adopta este último enfoque para las credenciales HTTP y las claves SSH: la aplicación las guarda en una bóveda cifrada y ejecuta la acción solicitada en lugar de entregar el material de las credenciales al agente. Esto no hace segura una solicitud peligrosa, por lo que aún debes restringir los objetivos y revisar las aprobaciones.

Elige el transporte con una comparación escrita de capacidades

Puedes tomar una decisión defendible sin organizar un largo taller de riesgos. Escribe una fila para la llamada HTTP propuesta y otra para el comando SSH propuesto, y completa ambas con los mismos datos. Las etiquetas vagas como «acceso de lectura» o «acceso de mantenimiento» no cuentan.

Usa esta comparación de cinco partes:

1. Expresa el resultado exacto: por ejemplo, «obtener el estado del despliegue del servicio A» o «reiniciar worker-17 después de un fallo en la comprobación de salud».
2. Nombra todos los objetivos accesibles: colecciones de API, proyectos, hosts, servicios, archivos y destinos de red.
3. Enumera las mutaciones que la misma credencial o cuenta puede realizar más allá del resultado previsto.
4. Describe las pruebas disponibles después de un tiempo de espera, un rechazo o un éxito aparente.
5. Define el límite de aprobación: una ejecución, una llamada o una rutina preaprobada con una identidad fija.

Elige HTTP si la fila de la API nombra un conjunto de objetivos más pequeño, expone una operación más limitada y deja un registro más claro. Elige SSH si la fila del receptor remoto puede hacer esas cosas mejor que la API o si no existe una API para la operación necesaria del host. Si ninguna de las dos filas es suficientemente limitada, todavía no conectes el agente. Crea primero el endpoint o el receptor que falta.

Esta comparación también detecta una recomendación equivocada habitual: «usa SSH para las lecturas y las API para las escrituras». Suena prudente porque el acceso al shell parece operativo y las llamadas de API parecen transaccionales. Falla porque leer un host puede revelar credenciales, código fuente, datos de clientes y topología, mientras que una mutación de API cuidadosamente limitada puede cambiar exactamente un estado deseado. Lectura y escritura no son categorías de riesgo suficientes. Lo importante son los datos accesibles y los efectos secundarios posibles.

Un equipo que ejecute un agente para diagnosticar fallos de compilación puede necesitar un endpoint HTTP para el estado del trabajo, una llamada de API para obtener una ventana limitada del log y un receptor remoto para un único host cuando una reparación concreta lo requiera. Dividir el trabajo añade interfaces, pero también evita que una tarea rutinaria de diagnóstico lleve una credencial de shell permanente solo porque una reparación poco frecuente la necesita.

La aprobación debe seguir el coste de una acción equivocada

La aprobación resulta más útil cuando aparece en un límite que una persona pueda entender. Pedir aprobación para cada lectura de estado inofensiva acostumbra a la gente a hacer clic sin leer. Conceder una aprobación amplia que cubra todos los ejecutables futuros elimina por completo la revisión significativa.

Usa la aprobación por ejecución cuando un nuevo proceso de agente pida actuar por primera vez y su identidad se pueda mostrar claramente. La persona puede comparar el ejecutable solicitante con el trabajo que esperaba iniciar. Revoca la ejecución si se comporta de forma inesperada y después investiga sus llamadas anteriores mediante el registro de acciones.

Usa la aprobación por llamada para acciones con efectos irreversibles o costosos: rotación de credenciales, eliminación, promoción a producción, cambios de cuenta y cualquier acción cuyo objetivo pueda elegir dinámicamente el agente. El aviso de aprobación debe nombrar el destino y la operación en términos habituales. «Ejecutar solicitud de herramienta» no dice casi nada al revisor.

No intentes sustituir este criterio por un lenguaje de reglas enorme para cada excepción. Los equipos terminan manteniendo un segundo entorno de programación cuyos casos límite autorizan aquello que pretendían bloquear. Un conjunto pequeño de controles fijos es más fácil de inspeccionar: el estado de bloqueo de la bóveda, una autorización de ejecución y el requisito opcional de aprobar cada uso de una credencial sensible.

La aprobación no compensa una credencial con autoridad ilimitada. Da a una persona la oportunidad de detener una acción antes de que salga de la máquina. El servicio subyacente debe seguir aplicando su propia autorización y el registro de auditoría debe conservar lo ocurrido después de la aprobación.

Crea un límite de acciones remotas antes del primer incidente

El mejor primer cambio normalmente no es un prompt de agente más complicado. Sustituye una credencial amplia por un límite de acción que tenga una gramática de entrada definida, un conjunto limitado de objetivos, un plan para los tiempos de espera y pruebas que otro operador pueda verificar.

Para una tarea HTTP, pide al responsable del servicio un endpoint y una credencial cuyos permisos coincidan con la única acción. Prueba las rutas y métodos rechazados con la misma intención que las llamadas correctas. Para una tarea SSH, crea una cuenta específica, desactiva las funciones interactivas, fuerza un programa receptor y prueba con entradas malformadas. Ejecuta esas pruebas desde la misma ruta que usará el agente, porque el acceso de red y las comprobaciones de identidad suelen ser diferentes en el portátil de un administrador.

Después prueba el fallo que nadie quiere simular: completa el trabajo remoto y corta la conexión antes de que la respuesta llegue al llamador. Si tu agente no puede determinar si debe esperar, consultar o reintentar a partir del registro conservado y del estado remoto, el diseño duplicará el trabajo bajo presión.

La elección del protocolo se vuelve sencilla cuando exiges esas propiedades. Usa la interfaz que conceda la capacidad mínima que puedas describir, ofrezca una respuesta fiable después de un fallo y deje constancia de la acción sin depender de la memoria de alguien sobre una sesión de terminal.