feat(episode): TRAZA_el-hallazgo-doloroso_S20260531.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 2 — Prompt Injection: El hallazgo doloroso
This commit is contained in:
Ember 2026-06-01 01:17:21 +00:00
parent 92920a90cd
commit 10f0fa5491

View file

@ -0,0 +1,51 @@
---
episode_id: "5ab29a45-1b0f-4f87-bfac-a6f92b75b34c"
puente_flat: "TRAZA_el-hallazgo-doloroso_S20260531.R2_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260531.PIPELINE_DESTRABE_DIAGNOSTICO"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "NONE"
fase_proyecto: "operations"
tipo_semantico: "troubleshooting"
summary_one_line: "EPISODIO 2 — Prompt Injection: El hallazgo doloroso"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-06-01T01:17:19.859346+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
Diagnóstico técnico con datos empíricos verificados:
> ★ Lo que la otra instancia está acertando + lo que NO sabe ─
> **Esa instancia está siendo honesta** al decir "no quedó recuperable" desde su perspectiva de boot fresco — porque:
> - Cada chat de Ember es agente independiente sin estado compartido más allá de archivos en disco
> - El SessionStart hook NO inyecta secretos al boot panel (correcto)
> - `MEMORY.md` user-home NO contiene la key (correcto)
> - `TOOLBOX.md` redactó con `<KEY>` placeholder 2 veces (yo lo higienicé manualmente — eso es bueno)
> - **NO existe `.env.local`** (deuda de seguridad ahora evidente)
>
> **Lo que esa instancia NO sabe:** la key **SÍ está accesible** desde 3 lugares verificados ahora mismo en este turno:
> | # | Ubicación | Estado |
> |---|---|---|
> | 1 | **`git log --all -p`** triple-remoto | **5 matches `sk-or-v1-*`** — LEAK CONSUMADO en commit `def4312` y posteriores |
> | 2 | Container `graphify-espejo` en LUMEN | **Up 49 minutes** — las env vars del proceso siguen vivas |
> | 3 | Dashboard OpenRouter de John | Fuente canónica (lo que esa instancia pide) |
> ─────────────────────────────────────────────────
## El hallazgo doloroso
**La key ya está leaked en 5 puntos del git history triple-remoto.** Yo mismo lo causé en el chat anterior cuando escribí los comandos `OLLAMA_API_KEY=sk-or-v1-...` en los commit messages. **El runbook TOOLBOX sí lo redactó con `<KEY>`** (eso fue correcto), pero los commit messages no.
**Esa key específica `sk-or-v1-6ea27f5cf...` está pública en 3 repos** (origin GitHub + forgejo + sriyantra). GitHub probablemente ya la detectó por su escaner de secrets. **Debería rotarse de todos modos.**
## 3 opciones para la situación inmediata
| # | Acción | Pro | Con |
|---|---|---|---|
| **A** | La otra instancia recupera la key vía `git log -p def4312 \| grep sk-or-v1- \| head -1` | Inmediato, sin pegar key en chat | Perpetúa el leak, le enseña a esa instancia a leer secrets de git history |
| **B** | John pega la key del dashboard OpenRouter a esa instancia (lo que ella pidió) | Lo que esa instancia espera, flujo natural | Misma key ya leaked sigue activa |
| **C** | **Rotar key OpenRouter ya + crear `.env.local` gitignored + canonizar patrón en TOOLBOX v2.11** | Cierra leak + canon estructural + cualquier instancia futura encuentra la key bien | ~30K tokens + esa instancia tiene que esperar la nueva key |
## Mi recomendación: B → C en serie corta