Variables de entorno del proxy: audita el tráfico de API del agente

Las variables de entorno del proxy son instrucciones ejecutables de enrutamiento, no preferencias inofensivas del shell. Si un agente de programación con IA hereda HTTP_PROXY, HTTPS_PROXY, ALL_PROXY o NO_PROXY, una solicitud que parecía una llamada directa a una API interna puede tomar otra ruta de red antes de que el agente haya hecho ningún trabajo útil.

He visto equipos pasar días revisando el alcance de los tokens y las listas de permisos de los endpoints, para descubrir después que el ejecutor del agente había heredado un proxy de depuración local desde el shell de un desarrollador. Las credenciales eran válidas, el cliente de API se comportaba exactamente según la configuración y, aun así, el tráfico terminaba en un lugar que nadie había previsto. Audita el entorno del proceso antes de dar acceso a un agente a servicios internos.

Las variables del proxy cambian la ruta, no solo la configuración de conexión

Una variable de proxy indica a un cliente compatible que entregue su solicitud a un intermediario. Para HTTP normal, el cliente suele enviar la URL de destino completa a ese intermediario. Para HTTPS, normalmente solicita al proxy que abra un túnel CONNECT hasta el host de destino y después realiza TLS a través de ese túnel.

La diferencia importa porque un proxy puede afectar la disponibilidad, el control del destino, el comportamiento de DNS y la observabilidad aunque no pueda descifrar HTTPS. Puede rechazar una conexión, redirigirla en la capa TCP, registrar el host y el puerto solicitados o convertirse en la única ruta que un agente puede usar para llegar a un servicio.

Trata estas variables como parte de la autoridad de salida del agente:

• HTTP_PROXY y http_proxy suelen afectar a las URL http://.
• HTTPS_PROXY y https_proxy suelen afectar a las URL https://.
• ALL_PROXY y all_proxy actúan como alternativa en los clientes que las admiten.
• NO_PROXY y no_proxy suelen excluir destinos del uso del proxy.

La palabra «suelen» es importante. Las variables de entorno son una convención, no un estándar de red que todos los entornos de ejecución implementen de la misma forma. Un agente puede llamar a un cliente de línea de comandos, usar una biblioteca HTTP de un lenguaje, invocar un gestor de paquetes o iniciar un proceso auxiliar. Cada capa puede tomar una decisión distinta sobre el proxy.

Que una variable no esté definida tampoco demuestra que la ruta sea directa. Un cliente puede leer un archivo de configuración, usar una configuración de proxy del sistema, obedecer un archivo PAC o llamar explícitamente a un relay local. Este artículo se centra en las variables de entorno porque se heredan con facilidad, pasan desapercibidas en entornos de procesos llenos de valores y suelen tratarse como temporales incluso después de haberse vuelto permanentes.

El proceso de inicio decide qué hereda el agente

Un agente solo recibe las variables que existen en su propio entorno de proceso o que le transmite un proceso padre. El terminal donde comprobaste env puede no tener ninguna relación con el proceso que realmente ejecuta el agente.

En macOS es especialmente fácil equivocarse. Un proceso iniciado desde un shell interactivo hereda las variables exportadas por ese shell. Una aplicación gráfica iniciada desde Finder o un servicio iniciado mediante launchd sigue otra cadena de herencia. Un IDE puede iniciar su terminal integrada con un entorno y su host de extensiones con otro. Un agente en segundo plano iniciado ayer puede conservar un valor de proxy antiguo mucho después de que la variable desaparezca del shell.

Traza la cadena de ejecución antes de cambiar la configuración. Hazte cuatro preguntas concretas:

1. ¿Qué proceso inicia el agente?
2. ¿El agente inicia shells, herramientas de paquetes, ejecutores de pruebas o auxiliares remotos?
3. ¿Cuáles de esos procesos realizan llamadas HTTP?
4. ¿Qué punto de inicio proporciona cada variable de entorno?

No aceptes «el agente se ejecuta en mi terminal» como respuesta a menos que puedas identificar el proceso padre y reproducir la ejecución desde ese terminal. El agente puede ser hijo de un editor, un ejecutor de tareas o un servicio de automatización que utiliza un entorno guardado.

Una variable de proxy inyectada por un proceso padre llega a todos los hijos, salvo que alguno la elimine. Por eso una sola línea export del shell puede cambiar silenciosamente las llamadas realizadas por la instalación de paquetes, los auxiliares de control de código fuente, las CLI de nube, la automatización del navegador y los accesorios de prueba. La solicitud afectada puede no ser la que tenías en mente al iniciar el agente.

La semántica de las variables del proxy cambia según el cliente

No existe una única interpretación de HTTP_PROXY, HTTPS_PROXY y NO_PROXY. Cualquier revisión de seguridad que suponga que el comportamiento de un cliente se aplica a otro está incompleta.

La documentación de curl señala una excepción importante que muchas personas pasan por alto: curl solo acepta http_proxy en minúsculas para configurar el proxy HTTP. Su documentación explica que así evita un problema de CGI, en el que una cabecera entrante Proxy: puede convertirse en una variable de entorno HTTP_PROXY. curl acepta variantes en mayúsculas para varias otras variables de proxy, pero esta excepción para HTTP es intencionada.

Go documenta http.ProxyFromEnvironment como una función que lee HTTP_PROXY, HTTPS_PROXY y NO_PROXY, con alternativas en minúsculas. Su comportamiento también incluye protección para CGI: cuando un entorno CGI contiene REQUEST_METHOD, Go se niega a usar HTTP_PROXY porque una cabecera de solicitud podría haberlo proporcionado. Esa protección no significa que un proceso Go sea seguro. HTTPS_PROXY, las formas en minúsculas, la configuración explícita del transporte y los contextos que no son CGI aún deben revisarse.

Muchas aplicaciones de JavaScript complican el panorama. El entorno de ejecución de Node.js históricamente no ha impuesto una política universal de proxy mediante el entorno para sus API HTTP integradas. Las aplicaciones y sus dependencias suelen añadir el soporte de proxy por su cuenta. Un comando puede respetar HTTPS_PROXY, otro comando de la misma ejecución del agente puede ignorarlo y un tercero puede leer una opción personalizada.

No resuelvas esto con una hoja de cálculo de ideas heredadas sobre entornos de ejecución. Identifica cada ejecutable con capacidad de red y pruébalo. Registra la versión del ejecutable, su invocación, la URL de destino, las variables relevantes y si se conectó directamente o a través del proxy previsto. Conserva el resultado junto con las notas de despliegue del agente, porque una actualización de dependencia puede cambiar el comportamiento.

A menudo se confunden dos conceptos: tener conocimiento del proxy no equivale a imponer el uso del proxy. Un cliente que respeta una variable de proxy puede ser enrutado cuando la variable existe. Aun así puede conectarse directamente cuando la variable falta, está mal formada, NO_PROXY la excluye o un proceso auxiliar la ignora. Si necesitas impedir la salida directa, impónlo en el límite de red, no confíes en que todas las bibliotecas lean una variable de entorno.

NO_PROXY necesita pruebas explícitas para los nombres internos

NO_PROXY es una lista de excepciones, y una lista mal construida puede enviar el tráfico interno a través de un proxy o hacerlo salir directamente cuando esperabas inspeccionarlo. No es seguro dar por hecho ninguno de los dos resultados.

La mayoría de las implementaciones aceptan entradas separadas por comas. A partir de ahí, los detalles divergen. Los clientes pueden tratar de forma distinta registry.corp.example, .corp.example, corp.example, 10.20.0.0/16, 10.20.30.40, localhost y *. Una coincidencia por sufijo que funciona en un cliente puede ser demasiado amplia o fallar por completo en otro. Las entradas con puerto tampoco se comportan de manera uniforme.

Evita las entradas amplias hasta que una prueba demuestre su significado. Un sufijo de dominio sin restricciones puede excluir hosts que no pretendías excluir. Un asterisco puede desactivar el proxy de forma mucho más extensa de lo que espera un revisor. La compatibilidad con CIDR es útil cuando existe, pero no puedes asumir que sea portable. Los nombres de host internos exactos resultan aburridos, y aquí eso es útil.

Empieza con una lista corta de servicios identificados que deban conectarse directamente, como un host interno de código fuente, un registro de artefactos y un endpoint de descubrimiento de servicios. Añade un sufijo de dominio solo después de comprobar que el cliente lo interpreta como esperas y que todos los hosts bajo ese sufijo merecen la misma ruta.

Separa también la coincidencia de nombres de la resolución de nombres. Un cliente suele decidir si aplica NO_PROXY antes de conectarse. Si la lista contiene un nombre de host, la coincidencia puede funcionar aunque el host resuelva a una dirección fuera del rango esperado. Si la lista contiene un rango IP, el cliente quizá tenga que resolver el nombre antes de decidir. La implementación controla esta secuencia.

Una prueba de excepción necesita un destino que controles y que puedas identificar en los registros. No uses una API de producción ni deduzcas que todo funciona a partir de una respuesta 200. Un endpoint interno de prueba debe informar de la dirección remota o emitir un identificador de solicitud en su registro de acceso. Compara una solicitud realizada con la excepción presente con otra realizada sin ella. Necesitas pruebas de la ruta de conexión, no una suposición basada en la salida de la aplicación.

HTTPS oculta el contenido, pero el proxy sigue recibiendo datos relevantes

Un túnel HTTPS CONNECT suele proteger las cabeceras y los cuerpos de las solicitudes frente a un proxy de reenvío convencional. Eso no vuelve irrelevante al proxy. Este ve el host y el puerto indicados en la solicitud CONNECT, los tiempos de conexión, el volumen de bytes y, a menudo, la dirección de origen. Según el cliente y la red, el tráfico DNS relacionado puede revelar más información.

El proxy puede leer las credenciales de API descifradas si el cliente confía en una autoridad certificadora que el proxy utiliza para interceptar TLS. Esto ocurre en algunas redes corporativas administradas y configuraciones de depuración. La presencia de un certificado raíz local confiable es una decisión sobre los límites de seguridad, no una simple comodidad. Si un proceso del agente confía en esa raíz, el operador del proxy puede inspeccionar el tráfico hacia cualquier host al que se aplique la política de interceptación.

El HTTP sin cifrar es peor. Un proxy de reenvío puede recibir la URL completa y las cabeceras de la solicitud, incluidos tokens de acceso o credenciales de autenticación básica. No permitas que un agente utilice HTTP sin cifrar para APIs internas autenticadas porque «la red es privada». Las variables de entorno del proxy son una de las formas en que las suposiciones sobre redes privadas dejan de ser ciertas.

Un fallo menos evidente implica una URL de proxy con credenciales integradas, como http://user:[email protected]:8080. Ese valor puede aparecer en salidas de diagnóstico, informes de fallos, historial del shell, inspecciones de procesos o registros que capturen el entorno. La autenticación del proxy debe usar un mecanismo administrado adecuado para tu entorno, y una revisión de seguridad debe tratar las credenciales del proxy como secretos independientes.

Si no puedes identificar al operador del proxy, la dirección de escucha del proxy y si es posible interceptar TLS, no dirijas tráfico privilegiado del agente a través de él. No es paranoia. El proxy ya se ha convertido en parte de la ruta entre un proceso automatizado y un servicio sensible.

Audita el proceso en ejecución sin volcar sus secretos

Empieza con un inventario que muestre los nombres de las variables y los endpoints del proxy, evitando un volcado general del entorno. En un shell que pueda iniciar el agente, ejecuta:

env | grep -Ei '(^|_)(http|https|all|no)_proxy='

La salida debería tener este aspecto:

HTTPS_PROXY=http://127.0.0.1:8888
NO_PROXY=localhost,127.0.0.1,registry.corp.example

Si la URL del proxy contiene información de usuario, no pegues la salida sin modificar en un ticket. Registra el esquema, el host y el puerto después de eliminar las credenciales. Una dirección de loopback no es automáticamente segura. Los proxies locales suelen pertenecer a herramientas de depuración legítimas, pero el malware y el software no deseado también pueden escuchar en loopback. Comprueba qué proceso es propietario del puerto de escucha.

En macOS, inspecciona un listener con:

lsof -nP -iTCP:8888 -sTCP:LISTEN

Un resultado normal identifica un comando y un ID de proceso. Si ningún proceso esperado es propietario del puerto, detente e investiga. No permitas que un agente envíe credenciales a un listener solo porque la dirección empieza por 127.0.0.1.

Después inspecciona el proceso real del agente. ps puede mostrar el entorno de un proceso en macOS, pero podría exponer otros secretos no relacionados. Limita el acceso al propietario del equipo o a un administrador, recopila solo lo necesario y no pegues el resultado en un chat ni en un registro compartido.

ps eww -p "$AGENT_PID" | tr ' ' '\n' | grep -Ei '(^|_)(http|https|all|no)_proxy='

Establece AGENT_PID con el ID de proceso del agente en ejecución. Este comando aún puede mostrar credenciales sensibles del proxy si existen, así que úsalo desde un terminal confiable y anonimiza el resultado antes de guardar las pruebas. Si la salida difiere del inventario de tu shell, el proceso padre inyectó o eliminó variables.

Para procesos iniciados por launchd, examina la definición del trabajo y el proceso de inicio en lugar de confiar en tu terminal. launchctl getenv HTTPS_PROXY puede mostrar una variable en el dominio actual de launchd, pero que no aparezca allí no descarta un trabajo concreto. Un trabajo puede definir su propio entorno y un script envoltorio puede exportar variables justo antes de iniciar el agente.

Demuestra la ruta con una solicitud inocua

Una revisión de configuración indica qué debería ocurrir. Una solicitud controlada indica qué ocurrió. Necesitas ambas cosas.

Crea o utiliza un endpoint no sensible que registre la dirección del par y la ruta de la solicitud. Después realiza una solicitud con salida detallada. curl resulta útil porque muestra si se conecta al proxy y si envía una solicitud CONNECT.

HTTPS_PROXY=http://127.0.0.1:8888 \
NO_PROXY= \
curl -v --connect-timeout 5 https://probe.corp.example/agent-proxy-check

Cuando curl utiliza el proxy para HTTPS, su salida detallada suele incluir líneas con este formato:

* Uses proxy env variable HTTPS_PROXY == 'http://127.0.0.1:8888'
* Establish HTTP proxy tunnel to probe.corp.example:443
> CONNECT probe.corp.example:443 HTTP/1.1

Después ejecuta deliberadamente la comparación directa:

HTTPS_PROXY=http://127.0.0.1:8888 \
NO_PROXY=probe.corp.example \
curl -v --connect-timeout 5 https://probe.corp.example/agent-proxy-check

Una ejecución directa debería mostrar una conexión con el destino en lugar de una solicitud CONNECT al proxy. Confirma el resultado en los registros del servidor de prueba. Si curl indica que evitó el proxy, pero el servidor observa un origen inesperado o la solicitud falla, investiga DNS, el enrutamiento y cualquier proxy de red transparente por separado.

Esto demuestra el comportamiento de curl, no el de tu agente. Repite la prueba mediante la ruta exacta de ejecución del agente. Si invoca un script, ejecuta ese script. Si usa una dependencia para llamar a una API, añade temporalmente una URL de prueba mediante esa misma configuración. Si inicia un proceso auxiliar, recopila pruebas de la ruta de ese auxiliar. Probar con otro cliente solo aporta una pista.

No uses un servicio público de «cuál es mi IP» para esta tarea. Convertirías una revisión de enrutamiento interno en una divulgación externa innecesaria y, además, el servicio no podría decirte qué política de proxy interno se aplicó.

Los entornos de inicio limpios son mejores que los exports permanentes del shell

No coloques exports de proxy corporativo en un perfil de shell universal y esperes que las herramientas autónomas hagan excepciones seguras. Los exports globales son populares porque hacen funcionar una orden bloqueada una vez. También se propagan a todos los procesos hijos cuya existencia puedes olvidar después.

Usa un proceso de inicio explícito para el agente. Parte de un entorno conocido, pasa solo las variables que necesita la ejecución y haz visible el uso del proxy en el comando de inicio o en el envoltorio. En un shell Unix, env -i elimina las variables heredadas, por lo que debes restaurar los elementos básicos que necesita el programa:

env -i \
PATH="$PATH" \
HOME="$HOME" \
LANG="${LANG:-en_US.UTF-8}" \
NO_PROXY="localhost,127.0.0.1,registry.corp.example" \
agent-command

Este ejemplo no establece deliberadamente ningún proxy. Si el agente necesita uno, añade la variable en el proceso de inicio después de identificar a su propietario y probar su comportamiento. No copies un valor de proxy desde un perfil de shell a un script sin comprobar si contiene credenciales o apunta a un servicio local obsoleto.

Un entorno limpio puede romper herramientas que dependían de variables como ubicaciones de certificados, perfiles de nube, sockets del agente SSH o cachés de paquetes. Ese fallo aporta información útil. Vuelve a añadir solo las variables que necesita el agente, una por una, y documenta por qué está presente cada una. El proceso de inicio del agente debe ser lo bastante limitado como para que otro ingeniero pueda leerlo y entender adónde irán sus solicitudes.

Los controles de red deben respaldar este enfoque. Si un agente solo necesita llegar a unos pocos servicios internos, utiliza reglas de firewall, un proxy de salida con una política impuesta o un segmento de red dedicado adecuado para tu entorno. Las variables de entorno eligen una ruta para los clientes que colaboran. No impiden que un proceso comprometido o una biblioteca que no cumpla la convención abra un socket directo.

Mantén las credenciales fuera del proceso que elige la ruta

La higiene del proxy reduce los desvíos accidentales, pero no hace aconsejable entregar tokens de API a un agente autónomo. Si el entorno del agente contiene un token de acceso, cada proceso que pueda acceder a ese entorno pasa a formar parte de la ruta de exposición del secreto.

Sallyport establece un límite diferente: el agente solicita una acción HTTP o SSH mediante su shim MCP, mientras las credenciales permanecen en la bóveda cifrada de la aplicación y la aplicación ejecuta la acción. Así se limita lo que puede exponer una filtración de variables del proxy en el proceso del agente, porque el agente nunca recibe la credencial de API o SSH en texto plano.

No exageres ese límite. Una pasarela de credenciales no define mágicamente un comportamiento seguro del proxy para cada comando que ejecuta el agente ni convierte un destino dañino en uno seguro. Aún debes controlar los destinos y las acciones permitidos, revisar el proceso de la aplicación que realiza la llamada de red y conservar pruebas de la ruta de la solicitud.

La separación útil está entre la custodia del secreto y el enrutamiento de red. La custodia responde a quién puede leer la credencial. El enrutamiento responde a qué intermediario gestiona la solicitud. Los equipos suelen resolver uno de estos aspectos y suponer que han resuelto ambos. No es así.

Trata el uso inexplicable del proxy como un incidente que debes contener

Si un agente privilegiado realizó solicitudes a través de un proxy desconocido, detén la ejecución antes de investigar desde el mismo entorno contaminado. Registra el ID de proceso del agente, su proceso padre, la dirección del proxy, los nombres de los destinos afectados y el intervalo de tiempo. Conserva los registros relevantes del agente y del proxy siguiendo tu proceso de gestión de incidentes.

Después elimina la variable desde su origen. Borrarla en el terminal actual solo corrige los futuros hijos de ese terminal. Comprueba los perfiles del shell, la configuración de tareas del IDE, los agentes de inicio, la configuración de CI, los scripts envoltorios y cualquier sistema de gestión de configuración que escriba ajustes del entorno. Reinicia el proceso afectado después de corregir el punto de inicio.

Evalúa las credenciales según el protocolo. Si el tráfico afectado era HTTP sin cifrar y contenía autenticación, rota la credencial expuesta. Si era HTTPS a través de un proxy, determina si el endpoint validó el TLS normal y si el agente confiaba en un certificado de intercepción. No supongas que HTTPS significa que el evento no necesita revisión, pero tampoco rotes credenciales a ciegas mientras dejas intacta la misma vía de inyección.

Por último, añade una comprobación previa en el punto donde se inicia el agente. Detén la ejecución o exige una revisión explícita cuando aparezca una variable de proxy inesperada. La comprobación debe informar del nombre de la variable y del endpoint anonimizado, compararlo con la ruta aprobada para ese trabajo y dejar constancia de que se ejecutó. El primer proxy inexplicable es una advertencia. El segundo es un defecto de despliegue que has decidido conservar.