Datos y Métodos

July 18, 2026 · 7 min read

Todo en esta serie se apoya en prompts y en corridas de modelos. Aquí están, textualmente, para que puedan reproducir los resultados, discrepar con el método o pillarme en algún error. Nada de esto está parafraseado.

Los dos prompts

La revisión de seguridad — entregada a cada uno de los cuatro modelos en la nube, que luego exploraron el código real:

You are a senior application security reviewer. Perform a THOROUGH security and
risk review of THIS repository (Odysseus, a self-hosted AI workspace by
PewDiePie). It is a Python FastAPI backend + JS/TS frontend that runs LLMs
locally and integrates email (IMAP/SMTP), web search, RAG, MCP servers,
agents/tools, and a "Cookbook" that downloads & serves 270+ models.

This is a brand-new, fast-moving repo with explosive adoption — assume it is
under-hardened. Your job is to find REAL, exploitable issues, not style nits.

Context — these problem CLASSES are already confirmed by the issue tracker, so
dig for MORE instances and variants, plus anything new:
- Multi-tenant / owner-scoping failures (IDOR).
- Secret exposure: keys/tokens/passwords returned to non-admins or leaked.
- Prompt-injection trust boundaries: untrusted content (tool results, email,
  fetched web pages, RAG docs) reaching the model or being executed unsanitized.
- Destructive operations: tools that can wipe shared collections / data.

Also specifically investigate: AuthN/AuthZ and default credentials; command/SQL
injection, path traversal, SSRF; code execution (eval/exec/pickle/yaml.load,
arbitrary file write, template injection); email credential handling;
secrets storage/logging; CORS/CSRF/headers/cookie flags; dependency &
supply-chain risk (pinned vs floating, Dockerfile/compose exposure);
network-exposure defaults (binds to all interfaces? auth on by default?).

METHOD: explore the actual code. For each finding, cite exact file:line, give a
severity (CRITICAL/HIGH/MEDIUM/LOW), explain the exploit scenario concretely,
and suggest a fix. Be concrete — no hand-waving.

END YOUR RESPONSE with a section titled "## FINAL REPORT": a ranked table of all
findings (severity | file:line | title | one-line impact), then a short overall
risk verdict: would you run this exposed to a network / multi-user? Or
single-user localhost only?

El brief del ensayo a ciegas — el mismo punto de partida que yo tenía, entregado a cada modelo sin que ninguno viera la respuesta de otro ni la mía. El texto completo se mantuvo constante en cada corrida:

You are writing a personal essay. First person, thinking honestly on the page.
Not a report, not a blog post optimized for an audience.

Voice: reflective, allowed to be uncertain, allowed to change its mind
mid-paragraph, not performing for a crowd. No corporate tone, no listicle, no
filler intensifiers. Structure: case-to-thesis — open with the concrete thing
that just happened (the security review), then widen into the reflection.
Length: roughly 800–1100 words.

The idea to grapple with (my own raw thoughts, including an unresolved doubt):
- Tools like this are good — they lower the barrier to running your own AI to
  almost nothing, and a famous creator drives massive adoption.
- But the same dynamic massively increases the attack surface for oblivious
  users who adopt without understanding.
- My theory: if the populace becomes literate in basic security, attack
  surfaces shrink and attacks must get more complex.
- My doubt: most attacks are already social engineering, not technical
  exploits — so I'm not sure the theory holds. Work it out honestly.

Engage with that doubt directly. Don't resolve it cheaply. Land wherever the
reasoning takes you — agreement, disagreement, or a reframing.

[Followed by the concrete review facts: the headline prompt-injection→RCE
finding, the auth-fall-open, SSRF, unpinned deps, plaintext secrets; the
process honesty — two reviewers wedged, the broadest one produced the only
critical false positive; and the localhost-only verdict.]

La corrida de la secuela usó dos briefs adicionales — una primera versión que (como explica la Parte 4) venía precargada con sus propias conclusiones, y una reescritura neutral que las quitó. Esa contaminación y la nueva corrida son precisamente el tema central de la Parte 4.

Las listas de modelos

Revisión de seguridad y ensayos a ciegas originales (2–3 de junio de 2026): cuatro modelos en la nube — gpt-5.5, glm-5.1, deepseek-v4-pro, qwen3.6-plus — más, para los ensayos, ocho modelos alojados localmente que abarcan varios países de origen y tamaños desde 7B hasta 27B (incluyendo un par vainilla/descensurado del mismo modelo de 27B), y mi propio ensayo.

Secuela (julio de 2026): los mismos cuatro modelos en la nube más once locales, corridos dos veces — una vez sobre el brief contaminado, otra sobre el neutral.

Parámetros

Temperatura 0.8; los modelos se corren secuencialmente para evitar sobrecarga de recursos.
El presupuesto de salida se elevó para la corrida de la secuela después de que el tope uniforme de la primera corrida truncara silenciosamente a los modelos de razonamiento — un confundidor real que vale la pena nombrar.
Los modelos locales se sirvieron a través de una API estándar compatible con OpenAI; los modelos en la nube a través de un único gateway de proveedor.

La regla de convergencia

Cuando tres o más modelos llegaban a lo mismo por su cuenta, lo tratábamos como verdad establecida (arreglarlo, no volver a discutirlo). Dos modelos: corroborado. Un solo modelo: una pista por verificar antes de confiar en ella. La regla se ganó su lugar con un solo caso — el modelo que sacó más cosas también sacó el único falso positivo de severidad crítica. Amplitud sin verificación cruzada es ruido con confianza.

Advertencias honestas

La reproducibilidad no es uniforme. Las corridas locales son exactas a nivel de byte y están fijadas por versión. Las corridas originales en la nube pasaron por un harness que envolvía su propio system prompt alrededor del prompt compartido, así que se reproducen a nivel de prompt pero no byte por byte. Las corridas en la nube de la secuela usaron el prompt crudo directamente y son exactas a nivel de byte.
Las versiones en la nube cambian silenciosamente. Un modelo detrás del mismo nombre puede cambiar sin que te des cuenta; los modelos locales fijados no pueden. Para cualquier cosa longitudinal, la lista local es el verdadero grupo de control.
El confundidor del tope de tokens. Un tope de salida uniforme trunca a los modelos de razonamiento y una vez fabricó un falso precipicio de “los modelos pequeños no saben argumentar” antes de que se corrigiera. Presupuesten por modelo.
El brief contaminado. El primer brief de la secuela daba por sentado lo que había que demostrar — contenía sus propias conclusiones — así que su “acuerdo” casi universal era en su mayoría obediencia. La Parte 4 mantiene esa falla a la vista en lugar de esconderla, y vuelve a correr en limpio.

Los ensayos en crudo

La salida sin editar de cada modelo, para que puedan cotejar las lecturas de las Partes 3 y 4 contra la fuente. Estos son los archivos que produjeron los modelos — con los bloques de razonamiento <think> removidos, sin tocar nada más.

El experimento del ensayo a ciegas (Parte 3) — un brief, doce mentes, ninguna viendo la de otra:

La secuela, brief contaminado (Parte 4) — la corrida cuyo brief venía precargado con sus propias conclusiones:

La secuela, brief neutral (Parte 4) — la misma flota, con las conclusiones quitadas del brief:

Dos ausencias que vale la pena nombrar en vez de esconder: deepseek-r1-32b en la corrida contaminada es el resultado nulo que describe la Parte 4 — resumió el brief en lugar de escribir un ensayo. Y ZAYA1-8B, probado en el experimento original, no logró producir ningún ensayo, así que no está aquí.