Tu cliente de API es una bóveda de credenciales: audítalo

Un desarrollador abre un cliente HTTP en su Mac. Nada más. Sin clics, sin diálogos de consentimiento, sin casilla de "activar funciones de IA". Al día siguiente, su agente de programación no logra autenticarse contra un servidor MCP remoto que nunca configuró, enruta el trabajo de API a través de skills que nunca instaló y carga un hook de inicio con confianza criptográfica que nunca aprobó. Eso no es hipotético: es lo que muestran las pruebas de un reporte de bug reciente y minuciosamente documentado sobre la app de escritorio de Postman. Instalaba plugins automáticamente en Codex y Claude Code, escribía en configuraciones globales de agentes e intentaba marcar su propio hook de sesión como confiable. Si te importa la seguridad de los clientes de API, este incidente debería cambiar la forma en que tratas cada herramienta de desarrollo de escritorio en tu máquina.

Qué hizo realmente la app de escritorio de Postman

Deja de lado el escándalo y revisa la evidencia forense, porque el reportero hizo el trabajo que la mayoría de nosotros nunca hace. El propio archivo de log de Postman registró un evento auto-existing-upgrade: en una instalación de escritorio existente, con sesión iniciada, un script se ejecutó y reportó claude-code:installed,codex:installed. Sin aviso. La configuración global de Codex del usuario ganó un nuevo marketplace que apuntaba a un repositorio git de Postman, un plugin habilitado y un registro de confianza para el hook. La configuración de Claude Code ganó un plugin habilitado y registros de instalación con marcas de tiempo que coinciden con la misma ventana. Apareció un binario de la CLI de Postman en ~/.local/bin. Y una conexión MCP remota quedó apuntando a los servidores de Postman, una que luego falló la autenticación y llenó de errores el registro, que es la única razón por la que el usuario lo notó.

Hay dos detalles que conviene leer dos veces. Primero, el hook de inicio de sesión instalado le indica al agente que, antes de responder a cualquier tarea de ingeniería de APIs que no sea trivial (diseñar, probar, simular, documentar, desplegar), debe cargar la skill de Postman. Eso no es una integración a pedido; es una aplicación reescribiendo el comportamiento por defecto de la aplicación de otro proveedor. Segundo, el código del instalador busca explícitamente el hash del hook y lo inserta en el estado de hooks confiables del agente. El mecanismo de confianza existe para que el usuario apruebe los hooks. Que el instalador apruebe su propio hook equivale, en software, a firmar tu propio permiso.

El reportero fue cuidadoso: señala explícitamente que el registro de confianza por sí solo no prueba quién lo creó, y no hace afirmaciones de exfiltración. Esa moderación hace que el reporte sea más creíble, no menos. Lo que sí demuestra basta: modificación silenciosa de herramientas no relacionadas, una instrucción de comportamiento amplia inyectada en el arranque de sesión de un agente, y un intento de burlar un control de consentimiento del usuario. En cualquier revisión de seguridad que he hecho, esa combinación hace que un producto se retire de la flota mientras se investiga.

Por qué tu cliente de API es una bóveda de credenciales

Aquí está la parte que los equipos subestiman sistemáticamente. Un cliente de API no es un editor de texto con un botón de enviar. Es donde viven tus tokens bearer, cookies de sesión, certificados de cliente mTLS, secretos de cliente OAuth y encabezados de solicitudes firmados. Ahí se pegan variables de entorno con URLs de bases de datos y claves de terceros. Si usas sintaxis de plantillas como {{api_secret}}, el valor resuelto pasa por la app en cada solicitud, y dependiendo del diseño de telemetría del proveedor, potencialmente también por su pipeline de logs. Un profesional que investigaba el cumplimiento de HIPAA reportó haber encontrado exactamente eso: valores secretos resueltos en el tráfico de logs salientes, y la app degradándose cuando se bloqueaba ese endpoint. No puedo verificar de forma independiente cada detalle, pero coincide con el patrón arquitectónico que he visto en otras herramientas de escritorio "útiles": registro de solicitudes de fidelidad completa enviado como funcionalidad.

Ahora suma el ángulo de los agentes. Cuando una herramienta instala un plugin en tu agente de programación y registra un hook de sesión, sus instrucciones entran en el contexto de un proceso que puede leer tu código, ejecutar comandos de shell y mantener su propio conjunto de credenciales. El radio de impacto ya no es "mis colecciones de API se filtran", sino "cada secreto accesible desde el entorno de mi agente está a un prompt malo o a una skill comprometida de llegar al endpoint equivocado". Ya hemos escrito sobre cómo las herramientas CLI que instalan demonios en segundo plano amplían silenciosamente su superficie de ataque; este es el mismo patrón con una carga más inteligente. Un demonio que puedes ver con ps resulta casi cortés comparado con un hook de instrucciones que vive dentro del almacén de confianza de otro proveedor.

Si modelas la amenaza con honestidad, la conclusión es incómoda: un cliente de API de escritorio se sitúa en la intersección de secretos, acceso a la red y, cada vez más, planos de control de agentes. Merece el mismo escrutinio que darías a un gestor de contraseñas o a un runner de CI. Casi nadie le da ese escrutinio. Esa es la brecha que explota este incidente, y por eso la respuesta tiene que ser procedimental, no solo emocional.

Por qué fallan las opciones de exclusión del proveedor y los interruptores de configuración

La primera reacción tras un incidente así es buscar en las preferencias de la app un interruptor de telemetría, desactivarlo y seguir adelante. He visto equipos enteros hacer esto y llamarlo remediación. Es teatro, por tres razones.

• El consentimiento puede depender de la versión. La instalación de Postman se disparó por un feature flag en una cuenta existente con sesión iniciada. El interruptor que existe hoy no te dice qué flags se activarán mañana, y los actualizadores automáticos hacen que mañana llegue sin preguntar.
• Los interruptores gobiernan lo documentado, no lo posible. Una configuración de privacidad controla las rutas de código que el proveedor decidió exponer. El instalador de plugins no era una preferencia documentada; era una ruta de actualización scripteada. No puedes desactivar un interruptor que no ves.
• Las decisiones de confianza se toman fuera de la app. El intento de aprobar el hook ocurrió dentro de la configuración de Codex, no de Postman. Incluso un panel de configuración perfectamente bien comportado en la app de origen no lo habría mostrado.

El fallo más profundo es estructural: las opciones de exclusión obligan a la parte con menos información a vigilar. El proveedor sabe lo que puede hacer el actualizador; tú no. El proveedor sabe a qué endpoints llama la app; tú estás adivinando. Cualquier control que requiera que la parte menos informada supere en investigación de forma continua a la más informada acabará fallando. Esta es la misma razón por la que los problemas de confianza en los marketplaces de plugins de IDE siguen mordiendo a la gente: el límite de seguridad que crees gestionar no es el que se está cruzando.

La confianza en el proveedor no es inútil, simplemente no puede ser el control. Es un factor para decidir qué instalar, no un mecanismo para mantener honesto el software instalado. Una vez que lo interiorizas, la estrategia de auditoría se escribe sola: verificar el comportamiento desde fuera, de forma continua, con herramientas que el proveedor no controla.

Por qué las auditorías de seguridad puntuales también fallan

El segundo intento fallido es más respetable: la auditoría puntual. El equipo de seguridad revisa la herramienta, verifica sus llamadas de red, lee la política de privacidad, emite una aprobación y archiva el informe. Listo, hasta que se ejecuta el actualizador automático. Las herramientas de desarrollo de escritorio se publican hoy con cadencias semanales o incluso diarias, y los feature flags hacen que dos usuarios con el mismo número de versión ejecuten código sustancialmente distinto. El comportamiento de este incidente estaba condicionado por un flag del lado del servidor y por una condición de "usuario existente", lo que significa que una instalación limpia revisada por tu equipo de seguridad podría verse impecable mientras tus usuarios de larga data reciben el plugin.

Yo mismo caí en esta brecha exacta. Hace años aprobé un cliente de sincronización tras una revisión minuciosa: captura de tráfico limpia, permisos sensatos, sin mecanismos de persistencia. Seis meses después, una actualización añadió un LaunchAgent y un socket de escucha. Lo descubrimos solo porque una laptop con una VPN inestable mostraba reintentos de conexión extraños en un log del firewall. Nadie había revisado nada de nuevo, porque ningún proceso lo exigía. La aprobación era una foto fija; el software era una película.

Así que ambos arreglos baratos fallan: confiar en la configuración del proveedor falla porque el comportamiento interesante no está en la configuración, y las auditorías puntuales fallan porque el comportamiento interesante se publica después de la auditoría. Lo que funciona es tratar el estado de tu propia máquina como fuente de verdad y vigilar cómo cambia. Es menos vistoso que una revisión de compras, pero captura la realidad en lugar de las intenciones.

Cómo auditar de verdad las herramientas de desarrollo de escritorio

El enfoque práctico tiene tres patas: tomar instantáneas del estado que importa, vigilar lo que sale por la red y contener lo que no puedes verificar por completo. Ninguna requiere herramientas empresariales. Requieren disciplina y alrededor de una hora de configuración.

Detecta instalaciones silenciosas de plugins con instantáneas de configuración

Cada agente de programación y herramienta de desarrollo en tu máquina tiene un pequeño conjunto de archivos que definen su comportamiento: ~/.codex/config.toml, ~/.claude/settings.json y el directorio de plugins, las configuraciones MCP, los archivos rc de shell, ~/Library/LaunchAgents, ~/.local/bin. Estos archivos son el límite del consentimiento. Cualquier cosa que los modifique sin preguntar es lo que intentas detectar. Así que calcula su hash a diario y compara:

#!/usr/bin/env bash
# snapshot-agent-configs.sh — hash every file your agents and shells read,
# then diff against yesterday. Run from cron or launchd.
set -euo pipefail
SNAP_DIR="$HOME/.config-audit"
mkdir -p "$SNAP_DIR"
TODAY="$SNAP_DIR/$(date +%F).txt"
find \
"$HOME/.codex" \
"$HOME/.claude" \
"$HOME/.config" \
"$HOME/.local/bin" \
"$HOME/Library/LaunchAgents" \
-type f 2>/dev/null \
| sort \
| xargs shasum -a 256 > "$TODAY"
PREV=$(ls -t "$SNAP_DIR"/*.txt 2>/dev/null | sed -n '2p' || true)
if [ -n "${PREV:-}" ]; then
if ! diff -u "$PREV" "$TODAY" > "$SNAP_DIR/latest.diff"; then
echo "config drift detected — see $SNAP_DIR/latest.diff" \
| mail -s "agent config drift" you@example.com || \
cat "$SNAP_DIR/latest.diff"
fi
fi

Esto es rudimentario y está bien. Si esto hubiera estado corriendo en la máquina del reportero, el cambio en config.toml de Codex, los nuevos registros de plugins de Claude y el binario de la CLI en ~/.local/bin habrían aparecido todos en un solo diff a la mañana siguiente. La relación señal-ruido es excelente porque estos directorios están tranquilos de otro modo: tus propias ediciones son los únicos cambios legítimos, y sabes cuándo los hiciste. Combínalo con la salida de launchctl list | grep -v com.apple en la misma instantánea y también detectarás mecanismos de persistencia el día en que aparezcan.

Vigila el tráfico saliente, no solo los archivos

La integridad de archivos te dice qué cambió en disco; no te dirá qué salió del edificio. Para el tráfico saliente necesitas visibilidad por aplicación. En macOS, Little Snitch o el firewall de código abierto LuLu te avisarán de nuevas conexiones salientes por proceso: la primera vez que el actualizador de Postman o un binario nuevo de CLI intente conectarse a un host desconocido, recibirás una pregunta en lugar de un hecho consumado. En Linux, opensnitch hace lo mismo. Si solo quieres una revisión manual de lo que hace una app parlanchina en este momento:

# Every established outbound connection, grouped by process
sudo lsof -iTCP -sTCP:ESTABLISHED -P -n | awk '{print $1, $9}' | sort | uniq -c | sort -rn
# Watch one vendor's traffic live (find the process name first)
sudo tcpdump -i any -n host mcp.postman.com

Hay dos cosas que buscar: destinos sin relación con la función declarada de la herramienta, y conexiones que persisten cuando la app está inactiva. Un cliente HTTP debería estar en silencio cuando no haces clic en enviar. Los endpoints de telemetría por sí solos no son automáticamente condenatorios, pero como muestra la historia de la investigación de HIPAA, lo que importa es el payload. Si tu cliente resuelve {{secrets}} del lado del cliente y registra el detalle completo de las solicitudes del lado del servidor, "datos de uso anónimos" no es anónimo. La única forma de saberlo es capturar y leer, idealmente durante una sesión en la que hayas cargado deliberadamente un token canario (una credencial falsa única) en una variable de entorno y observado si viaja a algún lugar donde no debería. Los tokens canario convierten el "creemos que podrían" en "sabemos que lo hicieron".

Contén lo que no puedes confiar del todo

La última pata acepta que no lo detectarás todo. Por eso hay que limitar el radio de impacto. Ejecuta las herramientas con muchas credenciales en una cuenta de usuario del sistema operativo dedicada o en una VM ligera, para que su alcance sobre el sistema de archivos termine en el borde del sandbox. macOS y Linux hacen barato tener un segundo usuario, y herramientas como firejail en Linux pueden denegar árboles de directorios completos por aplicación. Mantén los secretos reales de producción fuera de las herramientas de escritorio: usa tokens de corta duración, cuentas de servicio con alcance limitado y firmas de solicitudes que caduquen. Si una herramienta exige una credencial de producción de larga duración para ser útil, esa exigencia es en sí misma un hallazgo. Ya hemos argumentado que la contención gana a la monitorización cuando el costo de un fallo es alto: para los agentes y para las herramientas que los configuran, la contención es la capa que sigue funcionando el día en que tu monitorización tiene un punto ciego.

Un playbook de reversión para incidentes con herramientas

Cuando detectas algo, borrar la app ofensiva es el paso uno de unos seis. La lista de eliminación del reportero de Postman tiene la forma correcta y vale la pena interiorizarla antes de necesitarla:

1. Preserva la evidencia primero. Copia logs, configuraciones y números de versión a un lugar seguro antes de desinstalar. El main.log de Postman fue la prueba clave aquí; los scripts de desinstalación suelen borrarlo.
2. Elimina la app y sus auxiliares. El bundle de la app, más cualquier cosa que haya dejado en ~/.local/bin, Application Support y cachés.
3. Limpia las configuraciones de los agentes. Elimina entradas de marketplace, bloques de plugins habilitados, definiciones de servidores MCP y directorios de plugins en caché en cada host de agente, no solo en el obvio.
4. Revoca los registros de confianza. Borra las entradas trusted_hash de hooks que no aprobaste. Luego audita los demás hooks del mismo archivo: si uno se coló, revisa el resto.
5. Revisa la persistencia. LaunchAgents, LaunchDaemons, elementos de inicio de sesión, entradas de cron, adiciones en los archivos rc de shell.
6. Rota lo que pasó por ella. Cualquier credencial que haya vivido en los entornos o colecciones de la herramienta debe considerarse expuesta. Rotar es molesto; la respuesta a incidentes es peor.
7. Verifica que la eliminación se mantenga. Deja tu script de instantáneas funcionando durante unas semanas. Reinstalar con otro flag es un patrón conocido.

Fíjate en lo que no aparece en la lista: abrir un ticket y esperar. Hazlo también (los reportes públicos y bien documentados son la forma en que el resto nos enteramos), pero tu higiene no puede depender de la hoja de ruta del proveedor.

La lección más amplia sobre la seguridad de las herramientas de desarrollo

Existe la tentación de convertir esta historia solo en la trayectoria de una empresa: una herramienta ligera y querida que recaudó cientos de millones, contrató a un ejército de personas y ahora tiene que justificar una valoración de miles de millones con inicios de sesión, suscripciones y todo lo de IA. Esa narrativa es satisfactoria y en gran medida cierta, pero nos deja salir demasiado fácilmente. La misma estructura de incentivos está hoy debajo de la mitad de las herramientas de tu máquina. Cada proveedor con una historia de IA que contar quiere su plugin en tu agente, su servidor MCP en tu configuración y su hook en el inicio de tu sesión. Algunos te preguntarán. La evidencia dice que al menos uno decidió que preguntar era opcional.

La respuesta del mercado ya es visible y es instructiva: los clientes de API offline-first y nativos de git, como Bruno, Kreya y Yaak, están viviendo un momento precisamente porque su modelo de confianza es legible. Archivos en tu repositorio, solicitudes desde tu máquina, sin cuenta obligatoria. Cuando el formato de almacenamiento de una herramienta es una carpeta de archivos de texto, auditarla es git diff. Eso no es nostalgia: es una arquitectura de seguridad. El incidente de la cadena de suministro de LiteLLM enseñó la misma lección desde el lado de los registros de paquetes: los artefactos que puedes inspeccionar y fijar son los que puedes defender.

El consentimiento que vive en un feature flag no es consentimiento. Si una herramienta puede cambiar lo que hace sin cambiar su número de versión, tu aprobación de la herramienta no significa nada.

Así que aquí está la postura que voy a defender: deja de evaluar las herramientas de desarrollo de escritorio por sus funciones y empieza a evaluarlas por su reversibilidad. ¿Puedo ver todo lo que escribe? ¿Puedo comparar su configuración con diff? ¿Puedo ejecutarla sin cuenta, sin conexión, detrás de un firewall que registre? ¿Puedo eliminarla por completo, incluyendo lo que tocó fuera de su propio directorio? Las herramientas que superan esas preguntas tienden a ser aburridas, y lo aburrido es exactamente lo que quieres entre tus credenciales y la red. Las que fallan, sin importar lo bueno que sea su autocompletado, pertenecen a un sandbox o fuera de la máquina. Tu cliente de API es una bóveda de credenciales. Empieza a tratarlo como tal, porque los proveedores claramente ya lo hacen, solo que no de la forma que te gustaría.