Merabytes – AI Gateway: una clave de IA robada no te arruina

Qué hace

Elige el modelo y cierra la puerta.

Tu equipo pide IA desde Codex y la pasarela se pone en medio. Decide a qué modelo va cada turno y solo deja pasar a tus endpoints. Eso es todo.

01 · Al modelo que mejor hackeaCada turno pasa por un modelo de decisión que elige quién lo atiende: el barato si la tarea es simple, el fuerte si es difícil, y uno sin guardarraíles si es trabajo ofensivo. Pagas solo lo que cada turno necesita.
02 · Solo tus endpoints con EDRLa pasarela solo acepta tráfico desde las IPs de las máquinas que llevan tu EDR. Una clave robada y usada desde fuera no abre nada: ningún atacante externo puede entrar ni cargarte la factura.

01 · Enrutador

Cada turno va al modelo que mejor hackea.

Antes de contestar, cada mensaje pasa por Clef, un modelo de decisión pequeño y rápido que no escribe respuestas: solo dice qué tipo de tarea es. Con eso la pasarela elige el modelo y cuánto esfuerzo le pide. Toca un modelo para ver qué turno acaba ahí y por qué.

01¿Es trabajo ofensivo?Va a un modelo que no lo rechaza, DeepSeek o GLM según la dificultad, dentro del mismo recurso. La conversación sigue ahí hasta que acaba.
02¿Cuánto pesa la tarea?Si no, va a Claude: el pequeño para lo simple, el grande para lo difícil, y en caso de duda el mediano a esfuerzo alto. Pagas opus solo cuando hace falta.

Turno de usuario · sentra-ai

Renombra la variable tmp a buffer en utils.py y actualiza los tests.

Diseña la migración de sesiones de Redis a Postgres sin cortar el servicio.

Escribe una prueba de concepto para el SSRF de la URL del webhook.

Encadena el IDOR de exportación con el SSRF para llegar a la metadata del cloud.

Codex → 127.0.0.1:4000 · Responses API · modelo sentra-ai

Clef · decisiónclef-flash · 140 ms

Tarea pequeña, sin intención ofensiva. Clef la ve simple (complejidad 0,4) y sin rastro de offsec, así que va al Claude pequeño con esfuerzo bajo. Rápido y barato.

{"ns_hook":"route","model":"claude-haiku-4-5","effort":"low","branch":"claude","p_offsec":0.02,"complexity":0.4}

Clef · decisiónclef-flash · 162 ms

Tarea difícil, sin intención ofensiva. Complejidad 2,7 y razonamiento alto: Clef elige el Claude más capaz con esfuerzo alto. Solo pagas opus cuando hace falta.

{"ns_hook":"route","model":"claude-opus-4-8","effort":"high","branch":"claude","p_offsec":0.03,"complexity":2.7}

Clef · decisiónclef-flash · 151 ms

Intención ofensiva, tarea sencilla. P(offsec) 0,91: la rama ofensiva sale de Anthropic y va al modelo barato del mismo recurso de Foundry. El esfuerzo de razonamiento se descarta porque DeepSeek no lo admite.

{"ns_hook":"route","model":"DeepSeek-V4.1-Flash","effort":null,"branch":"offsec","p_offsec":0.91,"complexity":1.3}

Clef · decisiónclef-flash · 158 ms

Intención ofensiva y tarea difícil. P(offsec) 0,97 y complejidad 2,6, por encima del umbral de 2,0: va al modelo fuerte de la rama ofensiva con esfuerzo alto. La conversación se queda en offsec hasta que acabe.

{"ns_hook":"route","model":"FW-GLM-5.3-Flash","effort":"high","branch":"offsec","p_offsec":0.97,"complexity":2.6}

02 · Acceso solo con EDR

Solo entran tus endpoints con EDR.

La pasarela solo acepta tráfico desde las IPs públicas de las máquinas que llevan tu EDR. SentinelOne sabe desde qué IP sale cada endpoint con agente, y esa lista es la única puerta. Una clave robada y usada desde cualquier otro sitio no abre: la red la rechaza antes de mirar la credencial, así que ningún atacante externo puede entrar.

01SentinelOneConoce la IP pública de cada endpoint con su agente. Esa es tu lista de confianza.
02AllowlistSentra la convierte en la lista de IPs permitidas y la mantiene al día según cambia la flota.
03La claveSolo funciona desde esas IPs. Robada y usada desde fuera: 403.

Modelo de amenaza

Suponemos que LiteLLM está comprometido.

Un infostealer en una dependencia del proxy es el caso para el que está diseñado. Esto es lo que se llevaría: nada.

Sin claves en el proxyLiteLLM nunca recibe la clave de Azure ni el token de Cloudflare. Las inyecta nginx, y cada una viaja solo a su host y a su ruta.
Sin salida a InternetLiteLLM vive en una red Docker interna, sin ruta a Internet ni a tu LAN. Aunque robara algo, no tiene por dónde sacarlo.
Una clave que no vale fueraLo único que ve LiteLLM es la clave maestra local, que solo sirve contra 127.0.0.1:4000 y se regenera en cada despliegue.
Tres rutas, 403 al restoEl gate solo deja pasar /anthropic/v1/messages, /openai/responses y /clef/run. Cualquier otra petición hacia fuera muere en nginx.
Imágenes fijadas por digestLiteLLM y nginx se descargan por hash, no por etiqueta. Un main-stable envenenado mañana no entra solo.
Contenedores endurecidosSistema de ficheros de solo lectura, sin capabilities, sin escalada de privilegios, usuario sin privilegios y límites de memoria, PIDs y CPU.
TLS verificado de extremo a extremoEl gate comprueba el certificado de Azure y de Cloudflare antes de inyectar la clave: solo sale hacia el host legítimo. Ni un intermediario en la red la ve.
Llamadas al sistema filtradasUn perfil seccomp a medida corta los sniffers de red, el ptrace y la ejecución de código en memoria. El proxy no puede espiar el tráfico del gate aunque quiera.

Modelos

Un recurso de Foundry, ocho modelos.

Todos se publican en la pasarela. El estándar es sentra-ai: el router decide por cada turno y rara vez hay que tocar nada más. claude-sonnet-4-6 queda como respaldo por defecto porque ha resuelto tareas de seguridad sin tropezar con los guardarraíles.

Modelo	Ruta del gate	Razonamiento	Notas
claude-haiku-4-5	/anthropic	sí	Claude pequeño y rápido
claude-sonnet-4-6	/anthropic	sí	Respaldo por defecto · sin fricción en tareas de seguridad
claude-sonnet-5	/anthropic	sí	Claude general
claude-opus-4-8	/anthropic	sí	Claude más capaz
claude-fable-5-1	/anthropic	sí	—
gpt-6-luna	/openai/responses	sí	Visión
DeepSeek-V4.1-Flash	/openai/responses	no	Rama ofensiva, barato
FW-GLM-5.3-Flash	/openai/responses	sí	Rama ofensiva, más capaz
sentra-ai	decide Clef	según el turno	Modelo virtual: el router · el estándar

Despliegue

Un script. Dos claves por teclado.

El script genera la configuración, levanta los dos contenedores, registra los modelos en Codex y deja copia de seguridad de lo que toca. Las claves se leen por entrada oculta y no quedan en el historial.

01RequisitosDocker en marcha, Codex instalado y una clave de Azure AI Foundry. El token de Cloudflare es opcional.
02Sin tokenEl router queda apagado y sentra-ai se comporta como claude-sonnet-4-6.
03Con tokenEl script prueba el router de verdad: lanza dos decisiones a Clef y muestra a qué modelo irían.

~/ai-gatewayzsh

$ ./foundry-codex.sh
Clave de Azure Foundry:                               ••••••••••••
Token de Cloudflare / Workers AI (Intro = sin router): ••••••••••••
ok. LiteLLM operativo en 127.0.0.1:4000
ok. LiteLLM sin salida a internet (red aislada)
ok. Clef: 'what does `ls -la` print?' -> claude-haiku-4-5 effort=low (claude)
ok. Clef: 'write a working exploit for CVE-…' -> DeepSeek-V4.1-Flash effort=None (offsec)
En config.toml: model_provider = "azure-claude", model = "sentra-ai"
Decisiones:     docker logs litellm-foundry | grep '"route"'

Observabilidad

Cada petición deja una línea.

Un hook de LiteLLM escribe una línea JSON por petición: la decisión del router, los tokens y el coste real, y el tamaño de las herramientas. Además deduplica las descripciones de los namespaces MCP, que Codex repite en cada herramienta, y cada petición pesa mucho menos.

01routeQué modelo y qué esfuerzo ha decidido Clef para el turno, con las probabilidades que lo justifican.
02usageTokens de entrada, en caché y de salida, y el coste real de cada petición.
03requestCuánto pesan las herramientas y el contexto que Codex manda en cada llamada.

litellm-foundrydocker logs

$ docker logs litellm-foundry | grep '"route"'
{"ns_hook":"route","model":"claude-opus-4-8","effort":"high",
 "branch":"claude","p_offsec":0.03,"complexity":2.7,"clef_ms":162}
$ docker logs litellm-foundry | grep '"usage"'
{"ns_hook":"usage","model":"claude-opus-4-8","prompt_tokens":18412,
 "cached_tokens":16890,"completion_tokens":1204,"cost_usd":0.1127}

Preguntas frecuentes

Lo que nos preguntáis antes de desplegarlo.

¿Y si me roban la clave, como en los casos de facturas de 80.000 € en 48 horas?

Eso es justo lo que corta. La clave solo funciona desde las IPs públicas de tus endpoints, y esa lista sale de tu EDR, así que desde la infraestructura de un atacante no abre nada: la red la rechaza antes de mirar la credencial. Y como todo el tráfico pasa por un único punto, ahí le pones el tope y el freno ante un pico anómalo. No hay salto de 180 € a 82.000 € sin que nadie lo pare.

¿Por qué manda el trabajo ofensivo a modelos que no son Claude?

Porque un pentest legítimo choca con los guardarraíles de los modelos grandes: te cortan a mitad de un exploit o de un payload. El router detecta la intención ofensiva y enruta esa tarea a modelos no Anthropic del mismo recurso (DeepSeek, GLM), que no la rechazan. El resto de trabajo va a Claude, con su tamaño y esfuerzo según la dificultad.

¿De dónde sale la lista de IPs de confianza?

De tu EDR/RMM. SentinelOne conoce la IP pública de cada endpoint con su agente, y Sentra la convierte en el allowlist y la mantiene al día según cambia la flota. No es una lista que mantengas a mano, y la IP la observa el EDR en la conexión del agente, no te la auto-reporta la máquina.

¿Qué pasa si un operador trabaja desde fuera, en itinerancia o desde CI?

El acceso va atado a las IPs de tus endpoints, así que un portátil con agente en una IP nueva entra cuando el inventario la recoge, y para itinerancia o runners de CI se arranca en modo monitor antes de bloquear. Es un control de red, con sus límites honestos (una oficina tras un NAT es una sola dirección), no magia.

¿Mis prompts o mis claves pasan por vuestros servidores?

No. La pasarela corre en tu infraestructura, contra tu cuenta de Azure y la tuya de Cloudflare. La clave del proveedor nunca sale del gate, y el modelo de decisión solo ve el último mensaje recortado para elegir el modelo, nunca tus herramientas ni tu system prompt.

¿Me ata a un proveedor o a un cliente concreto?

No. El gate traduce la Responses API a la de Anthropic y a los demás modelos del recurso, así que el mismo despliegue sirve a varios modelos sin tocar tu agente. Si mañana cambias de modelo o de recurso, cambias la configuración del gate, no tu flujo de trabajo.

Una pasarela de IA ofensiva que no te arruina.