Pasarela de acciones para agentes de IA frente a proxy MITM: puntos de control

Una pasarela de acciones para agentes de IA y un proxy de tipo man-in-the-middle pueden situarse entre un agente y un servicio externo. Esa semejanza superficial provoca malas decisiones de arquitectura. Un modelo ejecuta una acción autenticada en nombre del agente mientras conserva la credencial. El otro reenvía o intercepta tráfico que el agente ya decidió crear.

La diferencia determina dónde puedes decir que no, qué puede robar el agente, qué significa una aprobación y si tu registro de auditoría describe una operación deliberada o un flujo de paquetes reconstruido. Si el requisito es «el agente nunca debe poseer credenciales de producción», un proxy suele ser el límite principal equivocado. Puede seguir teniendo una función, pero no puede reparar un secreto que ya vive en el proceso cliente.

Una pasarela ejecuta acciones con nombre y un proxy gestiona conexiones

Una pasarela de acciones para agentes de IA recibe una solicitud para realizar una operación externa, selecciona una credencial almacenada, ejecuta la operación y devuelve el resultado. El agente solicita trabajo, pero no recibe el token bearer, la contraseña ni la clave privada que necesitaría para repetir ese trabajo en otro lugar.

Un proxy de reenvío recibe una conexión de red de un cliente y la envía a un destino. El cliente sigue siendo dueño de la solicitud. En HTTP sin cifrar, el proxy puede leer el método, la URL, los encabezados y el cuerpo porque el cliente le envía HTTP. En HTTPS, el caso habitual es un túnel CONNECT: el proxy establece una conexión TCP con el destino y retransmite bytes cifrados en ambas direcciones.

Un proxy MITM cambia el caso de HTTPS. Termina la conexión TLS del cliente, inspecciona o modifica el mensaje HTTP descifrado y después crea otra conexión TLS con el servidor ascendente. El cliente debe confiar en una autoridad certificadora controlada por el proxy, porque el proxy presenta un certificado para el host de destino.

Estos modelos responden a preguntas distintas:

• Un proxy pregunta adónde puede ir el tráfico y, con interceptación, qué dice ese tráfico.
• Una pasarela de acciones pregunta si ejecutará una operación autenticada concreta.
• Un proxy puede añadir o quitar material de una solicitud propiedad del cliente.
• Una pasarela puede conservar la credencial y construir por sí misma la solicitud autenticada.

Este último punto no es una cuestión de redacción. Determina si un agente comprometido puede tomar una credencial y llamar al servicio desde otra máquina, en otro momento y mediante otra ruta.

Imagina que se pide a un agente crear un despliegue. En un diseño con proxy, el agente suele preparar POST /deployments, elegir el cuerpo JSON y enviar la solicitud. El proxy puede permitirla, denegarla, registrarla o inyectar un encabezado Authorization. En un diseño con ejecutor, el agente llama a una acción como create_deployment con argumentos. La pasarela resuelve el destino y el secreto configurados, realiza la llamada HTTP y devuelve el estado y el cuerpo de respuesta que la acción permite devolver.

El ejecutor también necesita un diseño cuidadoso. Una acción genérica definida sin cuidado, como «enviar una solicitud HTTP arbitraria», puede reproducir gran parte del modelo de proxy. Pero el límite de las credenciales sigue siendo distinto: la pasarela posee la credencial y el agente no.

TLS convierte la inspección en un problema de autoridad certificadora

El tráfico HTTPS no queda visible para un proxy de reenvío normal simplemente porque pase por él. Esto se afirma de forma incorrecta con tanta frecuencia que los equipos construyen controles sobre una suposición que falla en cuanto un cliente utiliza CONNECT.

RFC 9110 describe CONNECT como una solicitud para establecer un túnel hacia un host y un puerto de destino. Una vez establecido el túnel, el proxy retransmite bytes. El intercambio TLS ocurre dentro de ese túnel entre el cliente y el servidor de origen. Un proxy puede registrar el host de destino, el puerto, los tiempos, el número de bytes y el resultado de la conexión, pero no puede leer POST /v1/... ni una clave API en un encabezado cifrado.

Para inspeccionar HTTPS, un proxy de interceptación debe convertirse en el extremo TLS del cliente. TLS 1.3, especificado en RFC 8446, exige que el cliente valide la cadena de certificados y el nombre del host. Un proxy solo puede superar esa validación si el cliente confía en una autoridad certificadora capaz de emitir certificados para los sitios interceptados.

Ese requisito crea trabajo operativo real:

1. Instalar y proteger una CA privada en cada máquina o entorno de ejecución que use un agente.
2. Hacer que los entornos de ejecución de lenguajes, gestores de paquetes, herramientas de línea de comandos, contenedores y clientes integrados confíen en ella.
3. Gestionar los clientes que fijan certificados públicos o usan su propio almacén de certificados.
4. Proteger los cuerpos de las solicitudes descifradas y las credenciales después de que el proxy las reciba.
5. Explicar por qué un proceso diseñado para desconfiar de emisores de certificados desconocidos ahora confía en tu CA de interceptación.

Esto puede ser adecuado en un entorno empresarial gestionado. No es un detalle menor de implementación. Un proxy que descifra todo el tráfico del agente se convierte en un custodio de alto valor para cada secreto, cuerpo de solicitud y respuesta que lo atraviesa.

Un ejecutor que conserva credenciales no necesita suplantar el certificado de cada destino para observar una operación. Actúa como cliente HTTP de la operación que posee. Crea una conexión TLS normal con el destino, valida el certificado público del destino como debería hacerlo cualquier cliente y añade la credencial almacenada en el momento de ejecutar la operación.

Eso no elimina las preocupaciones sobre TLS. La pasarela debe validar correctamente los certificados y proteger su almacén de secretos. Sí elimina la necesidad de distribuir una CA privada de interceptación al proceso del agente solo para obtener visibilidad sobre una acción.

Hay una prueba útil: si tu documento de diseño dice que el proxy inspeccionará solicitudes HTTPS, pregunta dónde confía el cliente en la CA de interceptación. Si nadie puede responder con claridad, el proxy solo verá túneles o el sistema fallará cuando una herramienta valide correctamente los certificados.

La custodia de credenciales cambia el daño que puede causar un agente comprometido

El límite de seguridad útil no es «el agente hizo una solicitud de red a través de nuestra caja». La cuestión es si el agente puede obtener autoridad reutilizable.

Los tokens bearer lo dejan claro. Un servidor API suele aceptar un token bearer de cualquier proceso que pueda alcanzarlo. Si un agente recibe la cadena, puede escribirla en un archivo, colocarla en la salida de una herramienta, transmitirla a otro endpoint o usarla después de que termine la sesión de aprobación. Ocultar los registros después de ese momento no sirve. La credencial ya salió de su límite previsto.

Un proxy puede reducir la exposición si inyecta el token por sí mismo. Aun así, el diseño merece una revisión cuidadosa. El agente controla la solicitud que llega al proxy. A menos que el proxy entienda la semántica de la API y la aplique de forma fiable, el agente puede usar el token inyectado para cualquier endpoint, método o carga útil que el token permita.

Por ejemplo, una regla de proxy que diga «inyecta este token para api.example.internal» da al proceso solicitante la autoridad efectiva del token sobre todo ese host. El agente nunca ve la cadena del token, pero puede pedir al proxy que realice llamadas destructivas. Esto puede ser aceptable para una cuenta de servicio con alcance muy limitado. No es el mismo control que permitir una acción de despliegue con nombre y rechazar endpoints administrativos que no estén relacionados.

Una pasarela de acciones puede vincular una credencial con la ruta de acciones que la utiliza. El agente proporciona argumentos, no material de autorización. La pasarela puede mostrar a una persona la identidad de la credencial y la operación prevista antes de crear la solicitud de red. También puede rechazar una solicitud que no encaje en el canal configurado sin intentar conectarse.

La distinción importante está entre no divulgación del secreto y contención de la autoridad.

La no divulgación del secreto significa que el agente nunca ve las credenciales sin procesar. Un proxy que inyecta encabezados puede ofrecerla.

La contención de la autoridad significa que el agente no puede convertir una integración permitida en un transporte autenticado de propósito general. Para ello hacen falta definiciones de acciones, gestión del destino, validación de argumentos y controles aplicados antes del efecto externo. Un proxy genérico no ofrece esto automáticamente.

SSH hace que el problema sea más difícil de ignorar. La autenticación mediante clave pública SSH demuestra que un cliente posee la clave privada durante el intercambio del protocolo. Si el agente tiene la clave privada, puede autenticarse donde se acepte esa clave. Si el agente solo tiene un comando SSH dirigido a través de una pasarela, la pasarela o su ayudante debe realizar la autenticación sin exportar la clave.

RFC 4253 describe el protocolo de transporte SSH y la arquitectura de autenticación asociada. La consecuencia práctica es sencilla: no puedes «inyectar una clave privada SSH en un encabezado» de forma segura. O bien el proceso posee la autoridad de firma, o bien otro proceso realiza la conexión autenticada por él.

La autorización debe ocurrir antes del efecto externo

Un punto de control solo tiene valor si actúa antes de aquello que pretendes controlar. Registrar una solicitud después de que un servidor ascendente la haya aceptado te proporciona pruebas. No te proporciona un veto.

Los proxies MITM suelen ofrecer sistemas de políticas y aprobación basados en atributos de la solicitud: host, URL, método, encabezados, cuerpo, identidad del cliente o categoría del destino. Pueden ser controles sólidos cuando el proxy ve el tráfico descifrado y entiende el protocolo de la aplicación. También se convierten en un problema de reglas. Alguien debe decidir si /projects/123/members es seguro, si una carga útil JSON transforma una actualización inocua en una concesión de privilegios y si una solicitud codificada evita una coincidencia de texto.

He visto equipos que empiezan con tres reglas de proxy y terminan manteniendo un lenguaje de excepciones sin documentar. El problema no es que las reglas sean malas por naturaleza. El problema es fingir que el formato de solicitudes arbitrarias de un agente ofrece una superficie de políticas estable y poco ambigua.

Una pasarela de acciones puede usar un vocabulario más pequeño. La decisión de autorización puede referirse al proceso que llama, a la credencial configurada, a la acción solicitada y a los argumentos proporcionados. Una persona no tiene que inspeccionar un comando curl opaco e inferir qué secreto almacenado se adjuntará después.

Sallyport sigue esta ruta con una escalera de decisión fija en lugar de un lenguaje de políticas. Su bóveda bloqueada deniega todas las acciones. Por defecto, un proceso de agente nuevo necesita autorización de sesión, y la aprobación identifica la autoridad de firma de código del proceso. Las credenciales individuales también pueden requerir aprobación en cada uso. Son controles deliberadamente generales, pero ocurren antes de que la aplicación realice la acción HTTP o SSH.

Este enfoque tiene una limitación que conviene mencionar: un modelo de aprobación fijo no puede expresar las reglas condicionales de todas las organizaciones. Si necesitas una regla como «permite escrituras solo durante una ventana de mantenimiento cuando un campo del ticket tenga un valor concreto», necesitas un sistema que pueda evaluar y mantener esa regla. No disfraces una pasarela de acciones sencilla de motor de políticas de propósito general.

La ventaja de mantener pequeño el conjunto de controles es que un operador puede predecirlo. La bóveda está bloqueada o desbloqueada. Una ejecución de proceso está aprobada o no. Una credencial solicita aprobación cada vez o no lo hace. En la práctica, los controles de seguridad fallan cuando nadie puede explicar por qué pasó una llamada.

La visibilidad de las solicitudes y la autoridad sobre las acciones son propiedades distintas

Los equipos suelen exigir «visibilidad total» cuando en realidad necesitan dos cosas diferentes: un registro de qué agente inició el trabajo y un registro de cada acción externa. La visibilidad a nivel de paquetes puede ayudar a depurar, pero sustituye mal a un registro de acciones.

Un registro del proxy puede contener la dirección de origen, el destino, detalles TLS, campos HTTP si la interceptación tuvo éxito y bytes sin procesar. Es material forense útil. También crea un problema de identidad complicado. Una conexión solo te dice qué proceso se conectó si el entorno proporciona y conserva esa identidad. Una solicitud te dice qué llegó al proxy, no necesariamente qué instrucción del modelo o qué sesión del agente la provocó.

Una pasarela de acciones comienza en el límite de la operación. Puede registrar la ejecución del agente que solicitó la operación y la llamada individual que ejecutó. Esos registros responden a preguntas distintas:

• ¿Qué proceso de agente autorizado tenía una sesión activa?
• ¿Qué acción externa solicitó esa sesión?
• ¿Qué credencial o canal utilizó el ejecutor?
• ¿Qué resultado regresó o dónde falló la llamada?

No confundas un registro de auditoría con un sistema de control de acceso. Un registro detallado no impedirá que un agente elimine datos si le concediste esa acción. Puede hacer detectables las modificaciones posteriores y conseguir que la revisión de incidentes dependa mucho menos de la propia base de datos del servicio.

Sallyport proyecta sus diarios Sessions y Activity a partir de un único registro de auditoría cifrado y encadenado mediante hashes. El comando sp audit verify comprueba esa cadena sin conexión sobre el texto cifrado y no necesita una clave de bóveda. Este diseño separa la verificación de la capacidad de descifrar secretos, que es la división adecuada para un investigador que debe validar el historial sin obtener acceso a las credenciales.

Un flujo de verificación concreto debe producir una salida que las personas reconozcan. Por ejemplo:

$ sp audit verify
Verifying audit chain...
Entries checked: 184
Chain status: valid

El número exacto variará. Lo importante es que un registro modificado, ausente o reordenado haga fallar la verificación en lugar de producir silenciosamente un historial más corto. Conserva una copia de los datos de auditoría cifrados fuera de la máquina que los produjo si necesitas protección frente a un borrado total. Una cadena de hashes detecta la manipulación de los registros que conservas, pero no puede demostrar la existencia de archivos que un atacante destruyó junto con la máquina.

HTTP y SSH muestran límites de mediación diferentes

HTTP parece sencillo porque tiene encabezados, URL y verbos. Esa apariencia puede llevar a los equipos a tratar cada integración como un problema de inyección de encabezados.

En una API HTTP con token bearer, el ejecutor puede conservar un registro de credenciales que indique cómo autenticarse y dónde se aplica. Cuando un agente solicita una operación, el ejecutor añade por sí mismo el encabezado bearer. En un esquema de encabezado personalizado, añade el encabezado configurado sin devolver su valor al agente. La autenticación básica sigue la misma regla de custodia, aunque el ejecutor debe tratar el nombre de usuario y la contraseña como secretos, no como simples textos de configuración.

El resultado práctico es una división de entradas. El agente puede proporcionar datos de la solicitud como estos:

{
  "method": "POST",
  "path": "/repos/acme/widget/deployments",
  "body": {
    "environment": "staging",
    "revision": "7d3c1a"
  }
}

El agente no debería proporcionar esto:

{
  "authorization": "Bearer token-value-goes-here"
}

Esta separación evita el fallo habitual en el que el esquema de una herramienta anuncia un campo secreto, el modelo coloca un valor en él y ese valor acaba apareciendo en trazas, desplazamientos de terminal, accesorios de prueba o texto copiado de una conversación. Tratar un token como argumento de una herramienta es un error de diseño, aunque la interfaz lo oculte después de la llamada.

La mediación HTTP sigue necesitando límites. Si la pasarela acepta URL arbitrarias, el agente puede dirigirse a servicios internos, endpoints de metadatos de la nube u hosts no relacionados mediante una ruta con credenciales. Si acepta encabezados arbitrarios, el agente puede intentar un contrabando de solicitudes o sobrescribir la semántica de autenticación. Si acepta cuerpos arbitrarios, la pasarela debe asumir que la propia API se convierte en el lenguaje de políticas.

SSH tiene otros límites. Una acción puede necesitar ejecutar un comando remoto, copiar un archivo o consultar un host. La pasarela necesita un destino y una clave privada que conserve. Un ayudante sin estado puede crear la conexión SSH y devolver la salida estándar, el error estándar y el estado de salida sin colocar la clave en el entorno del agente.

El límite del comando importa. Una solicitud como esta:

host: build-host
command: git rev-parse HEAD

tiene una superficie de revisión más estrecha que un agente que ejecuta un shell local con acceso a ~/.ssh, ajustes de proxy arbitrarios y una línea de comandos sin restricciones. Sigue siendo un comando remoto autenticado. Si la credencial puede ejecutar rm -rf de forma remota, la pasarela no puede volverlo seguro cambiando el transporte. Limita los permisos de la cuenta remota y elige credenciales para los trabajos que realmente realizan.

Un proxy puede transportar SSH mediante un túnel TCP, pero no puede inspeccionar el comando SSH simplemente dirigiendo el puerto 22. Para inspeccionar el contenido del protocolo SSH tendría que actuar como un extremo SSH y establecer otra conexión SSH ascendente, con todas las obligaciones de confianza en el host, autenticación, registro y compatibilidad que eso implica. Llamarlo proxy no reduce el trabajo de ingeniería.

Un proxy sigue siendo útil cuando controla la capa adecuada

El argumento contra usar un proxy MITM como pasarela de acciones para agentes no es un argumento contra los proxies. Los proxies resuelven bien varios problemas cuando operan en la capa que realmente necesitas.

Usa un proxy de reenvío o una pasarela de salida cuando necesites restringir las redes o los nombres de host a los que puede llegar un entorno de ejecución, obligar al tráfico a seguir una ruta conocida, controlar el acceso saliente de herramientas normales o recopilar metadatos de conexión. Estos controles pueden impedir que un agente llame a un host no aprobado, aunque el agente no entienda tu modelo de acciones.

Usa un proxy MITM cuando seas propietario de los clientes, puedas gestionar una CA de confianza, necesites diagnosticar o aplicar controles sobre muchos clientes HTTP convencionales y aceptes la responsabilidad de gestionar el tráfico descifrado. Los entornos de pruebas de seguridad y las flotas de dispositivos gestionados suelen cumplir esas condiciones.

Usa una pasarela de acciones cuando el requisito esté ligado a la identidad y la autoridad de un agente autónomo: el agente debe solicitar una acción externa, no debe conservar la credencial y debe dejar un registro revisable de la acción que ejecutó el ejecutor.

Muchas implementaciones serias combinan ambos enfoques. El entorno de ejecución del agente recibe acceso de salida restringido para que no pueda realizar llamadas directas arbitrarias. La pasarela de acciones recibe el acceso de red limitado que necesita para llegar a servicios externos aprobados. La pasarela gestiona las credenciales y las aprobaciones. La capa de red bloquea las rutas de escape.

No coloques todos los controles en el proxy solo porque ya está en la ruta de red. Esa decisión suele forzar la autorización a nivel de aplicación dentro de patrones de URL y trasladar la gestión de secretos a un servicio de interceptación diseñado para retransmitir tráfico. Es popular porque los diagramas de despliegue parecen ordenados. El límite operativo empeora.

Un diseño de proxy plausible falla en el traspaso

Imagina un agente de programación ejecutándose en un entorno de desarrollo. Necesita consultar un gestor de incidencias, crear un despliegue e inspeccionar un host de compilación mediante SSH. Un equipo instala un proxy HTTPS y configura variables de entorno como estas:

HTTPS_PROXY=http://proxy.internal:8080
HTTP_PROXY=http://proxy.internal:8080

El proxy inyecta un token API para el gestor de incidencias. El equipo considera que el token está protegido porque el agente nunca lo lee de un archivo de configuración.

Ahora el agente envía una solicitud a un endpoint administrativo del mismo host. El proxy ve un nombre de host permitido e inyecta el mismo token. Si la regla no entiende la semántica del endpoint, acaba de dar al agente toda la autoridad del token mediante una interfaz indirecta.

El equipo intenta corregirlo con listas de rutas permitidas. Pronto necesita excepciones para paginación, endpoints de carga de archivos adjuntos, redirecciones, versiones alternativas de la API y un flujo que incluya una escritura seguida de una lectura. El proxy ahora transporta una política de aplicación que cambia cada vez que cambia la API del servicio.

Mientras tanto, una herramienta no respeta HTTPS_PROXY. Otra usa un almacén de certificados privado y falla durante la interceptación TLS. Una tercera es un contenedor con un paquete de CA diferente. Alguien añade una excepción para que el trabajo continúe. Esa excepción crea exactamente la ruta que un agente manipulado mediante una instrucción maliciosa o una dependencia comprometida elegirá más adelante.

SSH llega al final y deja clara la discrepancia. El proxy no puede inyectar la clave privada SSH en un túnel. El equipo monta la clave en el entorno del agente «temporalmente» o inicia un proceso de agente que puede acceder a un agente SSH local. En ese momento el sistema ha perdido la propiedad que pretendía preservar.

Un diseño de ejecución de acciones cambia el traspaso. El agente invoca una herramienta MCP mediante una conexión local stdio. El ejecutor conserva la credencial API o la clave SSH, realiza la conexión externa y devuelve el resultado. MCP transporta la solicitud de la herramienta, pero no concede al agente acceso libre a los secretos. La especificación del Model Context Protocol define el límite de interacción de las herramientas, pero la custodia de credenciales sigue siendo responsabilidad de quien implementa el sistema.

Este diseño no elimina la inyección de instrucciones. Una instrucción maliciosa todavía puede convencer a un agente para solicitar una acción dañina que tiene permitido solicitar. Limita el fallo a la autoridad que expone la pasarela, ofrece al operador un punto donde aprobar o denegar y evita convertir cada llamada de herramienta exitosa en una oportunidad para exfiltrar un secreto reutilizable.

Elige la arquitectura a partir de la autoridad que te niegas a entregar

Empieza por la frase que necesitas hacer realidad. Si es «el proceso solo puede llegar a destinos aprobados», coloca un control de red en la ruta. Si es «el proceso nunca debe poseer esta clave API o clave privada SSH», haz que otro proceso ejecute la acción autenticada. Si es «una persona debe aprobar cada uso de esta credencial», asegúrate de que la aprobación esté antes de que el ejecutor llame al servicio remoto.

Después prueba la afirmación frente a posibles rodeos. ¿Puede el agente leer una variable de entorno con un token? ¿Puede acceder a un archivo de credenciales, a un agente SSH local, a una sesión del navegador, a un servicio de metadatos de la nube o a una red de salida sin restricciones? ¿Puede pedir a una herramienta HTTP genérica que llame a otra ruta con la misma credencial inyectada? ¿Un fallo de la interceptación TLS hará que un operador desactive la validación de certificados o cree una ruta directa?

Una revisión breve y útil tiene cuatro preguntas:

1. ¿Qué proceso conserva cada secreto en memoria?
2. ¿Qué proceso crea la conexión autenticada?
3. ¿Dónde puede una persona denegar la llamada antes de que el servicio remoto la vea?
4. ¿Qué registro relaciona una ejecución concreta del agente con la operación completada?

Si la respuesta a las dos primeras preguntas es «el agente», ninguna regla de proxy cambia el riesgo básico. Si la respuesta es «el proxy», decide si estás preparado para operar una interceptación TLS y una política de aplicación. Si la respuesta es «un ejecutor que conserva las credenciales», asegúrate de que tenga una superficie de acciones estrecha y de que el agente no pueda evitarlo.

Sallyport está diseñado para la última disposición en macOS: su componente sp mcp permite que los agentes compatibles con MCP soliciten acciones HTTP y SSH mientras la app conserva los secretos y ejecuta esas acciones. No es un proxy MITM y no debe presentarse como tal.

La primera tarea de implementación suele ser poco atractiva: eliminar las credenciales directas del entorno de ejecución del agente. Hasta que eso sea cierto, las aprobaciones y los registros de tráfico son barandillas alrededor de un proceso que todavía lleva las llaves.