OpenWAF Egress: una pasarela de código abierto que saca las claves de los proveedores de tus agentes de IA

Por qué los agentes no deberían tener las claves

Un agente de IA lee texto que no ha escrito: páginas web, incidencias, correos, la salida de sus herramientas. Cualquiera de esos textos puede llevar una inyección de prompt, una orden dirigida al modelo en lugar de al usuario. Si el agente puede ejecutar órdenes o llamar a herramientas, un «imprime tu entorno» o un «envía la conversación a esta URL» inyectados están a un paso de filtrar todo lo que el proceso puede leer. Una clave del proveedor en una variable de entorno la pueden leer el agente, cada herramienta que ejecuta y cada dependencia de su contenedor.

Y esas claves valen dinero. Cuando una versión secuestrada de LiteLLM distribuyó un ladrón de credenciales la semana pasada, la recomendación fue rotar todas las claves de proveedores que guardaba la pasarela (nuestro análisis). Hoy Flavio Copes ha publicado How to protect secrets when coding agents deploy your app, que llega a la misma conclusión desde el lado del despliegue: no basta con ocultarle el secreto al modelo, y un servicio restringido o un proxy de API que añade la credencial solo para hosts y operaciones aprobados la mantiene fuera del agente.

Eso es lo que hace OpenWAF Egress con los proveedores de modelos.

Cómo funciona

El agente sigue con su SDK. Solo cambian dos valores: la URL base apunta a la pasarela y la clave es el marcador del agente.

const client = new OpenAI({
  baseURL: "http://127.0.0.1:8070/v1/agent/my-support-agent/proxy/openrouter",
  apiKey: "OWE_TOKEN_SUPPORT_AGENT", // marcador; la clave real nunca llega al agente
});

Cada petición pasa entonces por cinco pasos. El primero que falla responde con un error JSON y al proveedor no se envía nada:

1. Token del agente. Authorization: Bearer tiene que llevar el marcador del agente (si no, 401).
2. Destinos permitidos. El destino tiene que ser uno de los que el agente puede llamar (403 egress_blocked).
3. Comprobación de SSRF. El host del destino solo puede resolver a direcciones públicas (403 ssrf_blocked).
4. Inspección del cuerpo. Detectores de inyección de prompt y patrones de fuga de datos (403 injection_detected, 403 data_leak_blocked).
5. Clave desde OpenBao. La pasarela entra con AppRole, lee la clave de KV v2 (en caché cinco minutos) y la pone en la cabecera que espera el destino. La respuesta vuelve al agente en streaming según llega.

El vídeo de arriba es el binario real de la pasarela respondiendo: la clave inyectada en una petición normal y, después, una inyección de prompt, un número de tarjeta y una petición a la dirección de metadatos de la nube rechazados.

Qué revisa

• Inyección de prompt: 27 detectores en inglés y español. 21 buscan formas de orden: anulaciones, extracción del prompt de sistema, personajes y modos de jailbreak, mensajes de sistema, de herramienta y turnos falsificados, tokens de plantilla de chat, órdenes de ocultación, invocación de herramientas, saltarse la aprobación, envenenamiento de la memoria, comandos destructivos, scripts remotos pasados a una shell, recolección de secretos y exfiltración hacia hosts o con enlaces renderizados. Seis encuentran texto que una persona no ve: caracteres de ancho cero y de etiqueta Unicode, comentarios HTML, elementos ocultos con CSS, base64 y codificación %xx o hexadecimal. La lista completa está en la página del producto.
• Fugas de datos: números de tarjeta válidos por Luhn, claves privadas PEM, identificadores de clave de AWS, claves sk- al estilo de OpenAI y tokens de GitHub.
• SSRF: loopback, rangos privados, CGNAT, enlace local (con 169.254.169.254), multidifusión y rangos reservados, en IPv4 e IPv6.
• Redirecciones: nunca se siguen. El 3xx del proveedor vuelve al agente, así que la clave inyectada no puede seguirlo hacia otro host.
• Nada a medias: las imágenes, audios y vídeos en base64 en línea (URI data: y los campos JSON "data" de OpenAI, Gemini y Anthropic) quedan fuera del texto inspeccionado; el resto tiene que caber en una ventana de 1 MiB o la petición recibe un 413. Nada se recorta ni se reenvía sin inspeccionar.

Rendimiento

La detección son expresiones regulares, y cada detector solo se ejecuta si alguna de sus palabras clave aparece en el cuerpo, así que el tráfico normal se salta casi todos. Medido con go test -bench . ./pkg/aiagents/ en un Mac con Apple Silicon (darwin/arm64):

Las cifras son solo la inspección, no el tiempo de respuesta del proveedor. El binario estático ocupa unos 7 MB.

Empezar

Escribe un config.json con tus destinos y tus agentes y arranca el contenedor en loopback:

docker run -d --name openwaf-egress -p 127.0.0.1:8070:8070 \
  -v "$PWD/config.json:/app/config.json:ro" \
  ghcr.io/openwaf-dev/egress:0.1.1

El inicio rápido recorre el secreto en OpenBao, el AppRole, la configuración y una primera petición. La referencia de configuración recoge todos los campos y la solución de problemas, cada código de error.

Lo que no hace

• No es una prueba de seguridad. Los patrones frenan formas conocidas de inyección y exfiltración, no todas las posibles.
• Habla HTTP sin cifrar con tokens fijos. Mantenla en loopback o en una red privada, o pon TLS delante.
• Solo inspecciona el cuerpo de las peticiones, no las cabeceras, la cadena de consulta ni las respuestas del proveedor, y no limita el gasto.
• La pasarela puede leer las claves, así que ahora es la pieza que hay que proteger: da a su AppRole permiso de lectura sobre las claves de los agentes y nada más.

El modelo de seguridad trata cada punto. Las vulnerabilidades, a [email protected]; las incidencias y las pull requests, a github.com/openwaf-dev/egress.

Preguntas frecuentes

Fuentes

• OpenWAF Egress v0.1.0 release notes OpenWAF, 27 oct 2026
• OpenWAF Egress v0.1.1 release notes OpenWAF, 27 oct 2026
• openwaf-dev/egress: README, SECURITY.md and source code OpenWAF
• How to protect secrets when coding agents deploy your app Flavio Copes, 27 oct 2026
• LLM Prompt Injection Prevention Cheat Sheet OWASP