Nos pillamos a nosotros mismos filtrando un secreto, y la pasarela dijo no
Por qué redactar secretos en tu app es necesario pero nunca suficiente

Tenemos un agente de IA interno que diagnostica nuestra propia infraestructura. Cuando un contenedor se descontrola, reúne las pruebas (la definición del servicio, las últimas líneas de logs), se las pasa a un LLM y propone un análisis de causa raíz. Útil, aburrido, exactamente el tipo de trabajo de fontanería en el que los agentes destacan.

Como cualquier equipo responsable, redactamos los secretos antes de que algo salga de nuestro perímetro. El agente pasa el paquete por un paso de limpieza que elimina contraseñas, claves de API, tokens y cadenas de conexión. Cinturón y tirantes.

Entonces, una mañana, nuestro canal de alertas se encendió:

🚨 security_shield: BLOCKED  threat=secrets  score=0.95

Nuestra propia pasarela LLM acababa de rechazar una petición de nuestro propio agente. Había encontrado un secreto en un payload que nuestro paso de redacción ya había "limpiado".

Esa es, a la vez, la peor y la mejor noticia que puedes recibir.

La peor noticia: nuestra redacción tenía un agujero

El paso de limpieza era lo que casi todos los equipos lanzan primero: una lista de denegación hecha a mano. Un conjunto de regex que busca nombres de variables como password, secret, token, api_key, más un puñado de formatos de token conocidos (sk-…, JWT, contraseñas en cadenas de conexión). Funciona, hasta que deja de funcionar.

Aquí hay una versión anonimizada de lo que se coló, reproducida contra el código de redacción real:

# lo que el agente recopiló (anonimizado)
POSTGRES_PASSWORD: ********              <- atrapado (el nombre contiene "password")
GOOGLE_API_KEY:    ********              <- atrapado (el nombre contiene "api_key")
conn=postgres://app:********@db:5432     <- atrapado (regla de cadena de conexión)

DB_PASS:  pg_h0tfix_9921xQ              <- FILTRADO ("pass" != "password")
pwd=hunter2hunter2                       <- FILTRADO (la lista tenía "password|passwd", no "pwd")
Authorization: Bearer abk_live_9Hk29Lm…  <- FILTRADO (solo se cubrían ciertos formatos de clave)

Tres secretos distintos pasaron directos a través de la redacción:

• una contraseña bajo una variable llamada DB_PASS, porque la lista de denegación coincidía con password, no con pass;
• una línea pwd=, porque la lista tenía password y passwd, pero nadie pensó en pwd;
• un token Bearer con un prefijo no estándar, porque el redactor solo conocía unos pocos formatos de clave concretos.

Ninguno es exótico. Son el vocabulario cotidiano de archivos de configuración y logs reales. Una lista de denegación es la lista de los secretos que recordaste. La producción está llena de los que olvidaste.

La mejor noticia: la pasarela los atrapó todos de todos modos

Cada petición que hace nuestro agente pasa por nuestra pasarela LLM, y la pasarela ejecuta un Security Shield a la entrada. Al Shield no le importa qué app, qué SDK, qué agente o qué modelo está implicado. Escanea el contenido de cada petición en busca de secretos, datos personales e inyección de prompts, antes de que la petición se transmita jamás a un proveedor.

Su detector de secretos atrapó exactamente lo que nuestra redacción dejó pasar:

HIT  bearer\s+[A-Za-z0-9\-._~+/]{20,}      -> "Bearer abk_live_9Hk29Lm…"
HIT  (password|passwd|pwd)\s*[:=]\s*\S{8,} -> "pwd=hunter2hunter2"
-> threat=secrets, score=0.95 -> petición rechazada (HTTP 400)

La contraseña nunca llegó al modelo. Nunca llegó al proveedor. Nunca salió de nuestra red. El Shield convirtió una fuga de datos silenciosa en un 400 ruidoso e inofensivo, más un ping de Slack.

La lección: la redacción es un control, la pasarela es la red de seguridad

Es tentador leer esto como "nuestra redacción era mala, arreglemos la regex". Arreglamos la regex. Pero eso pierde el punto.

Nunca terminarás la lista de denegación. Mañana es un webhook de Slack, una clave AWS AKIA…, un token de GitHub ghp_…, un formato Bearer específico de un proveedor que nunca has visto. Cada nuevo servicio añade una nueva forma de secreto. Un paso de redacción dentro de una sola app solo conoce los patrones que un solo equipo recordó, el día en que lo escribió.

Un escáner de secretos a nivel de pasarela es estructuralmente distinto:

• Ve cada petición. Un único punto de aplicación cubre cada app, cada agente, cada equipo, cada modelo, incluido el script experimental que alguien improvisó a las 2 de la madrugada sin ninguna redacción.
• Está centralizado. Añade un patrón una vez, y todos los que llaman quedan protegidos. Sin redesplegar diez servicios.
• Es la capa por la que los secretos realmente pasan. La redacción de tu app es opcional y fácil de olvidar. La pasarela es la carretera; nada llega a un proveedor sin recorrerla.
• Es rápido y por niveles. Una pasada determinista por regex se ejecuta en menos de dos milisegundos en cada petición; una pasada opcional por LLM solo escala en las sospechosas, así obtienes cobertura sin pagar latencia en el 99 % que están limpias.

Y aquí está la parte honesta, porque la honestidad es lo único que hace que valga la pena leer una historia de seguridad: ninguna capa es perfecta. En nuestro incidente, un secreto se coló entre tanto la redacción como el nivel rápido de regex del Shield. Eso no es un argumento contra el Shield; es todo el argumento a favor de apilar capas. Redacción en la app, escaneo de secretos en la pasarela, mínimo privilegio sobre los propios secretos, credenciales de vida corta. Cada capa es un filtro con agujeros; las apilas para que los agujeros no se alineen.

Eso es defensa en profundidad. La redacción es un control. La pasarela es la red de seguridad. Quieres ambas, y quieres especialmente que la red sea lo único que cada petición está obligada a cruzar.

Confiamos en él lo suficiente como para custodiar nuestra propia infraestructura

La razón por la que podemos contar esta historia sin inmutarnos es que el agente que fue bloqueado es nuestro, la pasarela que lo bloqueó es nuestra, y nos enteramos por nuestras propias alertas, no por un cliente, no por un informe de filtración.

Eso es lo que hace el Security Shield de HiWay2LLM en cada petición que fluye por la pasarela: escanea secretos filtrados, datos personales e intentos de inyección antes de que la llamada se realice, con una ruta rápida determinista y un escaneo profundo opcional por LLM, y envía los eventos de amenaza directamente a tu SIEM. Apuntamos nuestros propios agentes de infraestructura a él por exactamente la razón de este artículo, porque el lugar para detener un secreto es el único cuello de botella que cada petición tiene que atravesar.

Si tus agentes y apps hablan con LLM a través de rutas de código que no controlas al 100 % (y hoy en día, ¿quién las controla?), pon una red de seguridad en la carretera que todos están obligados a tomar.