llm-council para ofensiva: consenso entre modelos, no autopilot

Karpathy soltó hace poco un repo chico llamado llm-council. La idea es simple: en vez de preguntarle a un solo modelo, le preguntas a varios al mismo tiempo, los modelos se revisan entre sí, y un modelo “chair” sintetiza todo en una respuesta final con notas de consenso y disenso.

No es nada revolucionario en teoría. En la práctica cambia bastante el output cuando el problema es ambiguo o técnico, que es exactamente donde vivimos los que hacemos ofensiva.

Aviso de entrada: esto es un asistente de hacking, no un ejecutor automático. Si esperabas un agente que solo se conecte y te haga el pentest, este artículo no es para ti. Si querías una segunda opinión calificada antes de gastar 3 horas explotando algo que no era exploitable, sigue leyendo.

Qué es llm-council

Repo original: github.com/karpathy/llm-council.

Es código Python relativamente compacto que coordina varios modelos en tres pasos:

1. Fan-out: la misma prompt se envía a N modelos en paralelo.
2. Peer review: cada modelo recibe las respuestas de los demás y las evalúa.
3. Chair: un modelo elegido como presidente sintetiza todo, marca dónde hay consenso, dónde hay disenso, y devuelve una respuesta final con confianza estimada.

Las “council members” son configurables: claude, gpt-5, gemini, grok, deepseek, lo que tengas a mano y key. El chair también es elegible, conviene que sea un modelo de razonamiento bueno y caro porque hace el trabajo pesado.

Por qué importa en ofensiva

Cuando estás auditando una API o un binario, las preguntas casi nunca tienen una sola respuesta correcta. Hay varias hipótesis vivas, y la mayoría de las veces la diferencia entre encontrar la vuln y perder la tarde está en qué hipótesis elegiste explorar primero.

Un solo modelo te empuja a su sesgo. Cuatro modelos te dan un mapa.

Lo más útil que he encontrado son cuatro casos:

Triage de findings. Cuando el scanner saca 80 alertas, el council te ayuda a separar las que valen la pena de las que son ruido. Si tres modelos coinciden en que algo es false positive, probablemente lo sea. Si dos dicen que es crítico y dos que es ruido, ahí hay que mirar a mano.

Análisis de código fuente. Le tiras una función o un controller y le pides el modelo de amenazas. Donde un solo modelo se inventa cosas, el council es más conservador porque los otros lo corrigen.

CVSS y CWE. Para vectores ambiguos (¿es SSRF o XSPA?, ¿CWE-918 o CWE-611?), el voto cruzado se acerca mucho más a lo que decidiría un revisor humano sénior.

Redacción de PoC. Cada modelo escribe un PoC, el chair pide el más corto y reproducible. Suele salir mejor que el de cualquier modelo individual.

Instalación rápida

Lo que viene asume Python 3.11 o superior, una cuenta en al menos dos proveedores de LLM, y git puesto.

git clone https://github.com/karpathy/llm-council.git
cd llm-council
python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

El archivo requirements.txt trae las SDKs oficiales de Anthropic, OpenAI, Google y xAI. Si no usas alguna, no pasa nada, simplemente no configures la key.

Crea un .env en la raíz del proyecto. Las que no tengas, déjalas vacías:

ANTHROPIC_API_KEY=sk-ant-...
OPENAI_API_KEY=sk-...
GOOGLE_API_KEY=...
XAI_API_KEY=xai-...
DEEPSEEK_API_KEY=...

Para una prueba rápida basta con dos modelos. Yo arranqué con Claude y GPT-5, y agregué Gemini cuando quise tener un voto de desempate barato.

Ejecutar:

python -m llm_council "auditame este endpoint: POST /api/transfer con campo amount string"

La primera vez tarda un par de segundos extra porque cachea los clientes. A partir de ahí cada query toma entre 8 y 20 segundos dependiendo de cuántos modelos pongas y de cuán largos sean los outputs.

Integrar modelos de pago sin quemarte el presupuesto

Esto es lo que no está bien documentado en el README y donde la gente se equivoca.

Cada modelo cobra distinto. Si pones a Claude Opus 4.7, GPT-5 pro y Gemini 2.5 ultra todos en el council, una query te puede costar entre 30 y 80 centavos de USD. Multiplica eso por 50 preguntas al día y la cuenta no es trivial.

La regla que sigo:

• Council members: modelos medianos. Claude Sonnet, GPT-5 mini, Gemini Flash. Son rápidos, baratos y cubren bien el 80% de los casos.
• Chair: el modelo más caro y mejor en razonamiento que tengas a mano. Aquí sí pones a Opus o GPT-5 full. El chair solo corre una vez por query, así que el costo extra es controlable.
• Caché agresivo: para auditorías iterativas sobre el mismo target, activá el prompt caching de Anthropic. Te baja el costo hasta 90% en queries repetidas con contexto largo.

Truco que me ahorró bastante: configurar un MAX_OUTPUT_TOKENS distinto para members y para chair. Los members no necesitan escribir un ensayo, con 600 tokens por respuesta sobra. El chair sí necesita espacio porque está consolidando.

COUNCIL_MEMBERS = [
    {"provider": "anthropic", "model": "claude-sonnet-4-6", "max_tokens": 600},
    {"provider": "openai",    "model": "gpt-5-mini",         "max_tokens": 600},
    {"provider": "google",    "model": "gemini-2.5-flash",   "max_tokens": 600},
]
CHAIR = {"provider": "anthropic", "model": "claude-opus-4-7", "max_tokens": 2000}

Otra cosa que conviene: nunca le mandes secretos al council. Si estás auditando un binario o código que contiene credenciales reales, sanitiza primero. Los proveedores comerciales tienen políticas de retención y aunque digan que no entrenan con tu data, no quieres ser el caso de prueba.

Lo que no hace

Para que no te lleves una decepción:

llm-council no ejecuta nada. No corre nmap, no manda curl, no toca tu target. Solo razona sobre lo que le pasas. Si quieres ejecución hay otros frameworks como langchain con tools, o agentes tipo nuclei-ai, pero ahí ya entras en territorio de auto-pwn y eso tiene sus propios problemas legales y éticos.

Tampoco reemplaza a un revisor humano. Cuatro modelos pueden estar todos equivocados de la misma manera, especialmente cuando el target es un dominio nicho con vocabulario raro. He visto al council quedar atrapado en una rabbit hole donde los cuatro modelos coincidían en algo que era falso, y solo un revisor experto detectó el error.

La forma sana de usarlo es: el council propone, tú validas. Nunca al revés.

Mi setup actual

Por si sirve de referencia, en pentests reales corro con:

• claude sonnet 4.6 (member)
• gpt-5 mini (member)
• gemini 2.5 flash (member)
• grok 4 fast (member, cuando quiero un voto raro)
• claude opus 4.7 como chair

Costo promedio por query: 6 a 12 centavos. Latencia: 12 a 18 segundos. Lo tengo bindeado a una macro de mi editor para mandar selección de texto como prompt directo.

Cierre

Si vienes del paradigma “una IA me resuelve todo”, este patrón se te va a sentir lento y caro. Si vienes del paradigma “ninguna IA me sirve para hackear”, probablemente sea lo que te haga cambiar de opinión.

Asistente, no ejecutor. Esa es la línea.

Si lo pruebas, cuéntame en el canal de Telegram cómo te fue. Especialmente interesado en setups exóticos con DeepSeek o Qwen.