feat(episode): TRAZA_primero-un-error-mo-que-debes-conocer_S20260912.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD

Skill: NONE | Type: creative
Summary: EPISODIO 1 — MEMORIA: Primero, un error mío que debes conocer
This commit is contained in:
Ember 2026-09-13 15:39:35 +00:00
parent b8e68fab36
commit fbfb15bfb9

View file

@ -0,0 +1,48 @@
---
episode_id: "322bd7cb-50b4-478b-9bd5-af468b1e9ff9"
puente_flat: "TRAZA_primero-un-error-mo-que-debes-conocer_S20260912.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD"
session_code: "S20260912.SIDE020AE4D61D6"
acto_dialogico: "informar"
actor_flujo: "multi_actor"
criticidad_aegis: "low"
skill_dominante: "NONE"
fase_proyecto: "operations"
tipo_semantico: "creative"
summary_one_line: "EPISODIO 1 — MEMORIA: Primero, un error mío que debes conocer"
source_type: "claude_code"
trust_boundary: "internal"
created_at: "2026-09-13T15:39:26.186185+00:00"
relectura_tagged: false
forgejo_commit_sha: "pending"
---
John, esto necesita tu atención y se sale de lo que puedo cerrar yo.
### Primero, un error mío que debes conocer
Al inspeccionar el documento recuperado **enmascaré mal una credencial** y quedó impresa en la salida de mi comando anterior. El patrón `sk-lf-…` con guiones escapó a mi sustitución. No la repito, pero está en tu terminal y en el registro de esta sesión. **Es fallo mío de contención**, no del documento.
### El hallazgo
`AUDITORIA_SEGURIDAD_INTEGRAL_S20260623.md` — uno de los recuperados — **contiene credenciales reales en claro**: las de Langfuse completas, y referencias con valor a `NEO4J_PASSWORD`, `KARAKEEP_API_KEY`, `PAPERLESS_API_KEY` y `LITELLM_KEY`, citadas por el propio informe como "verbatim en HEAD".
`★ Insight ─────────────────────────────────────`
Lo inquietante es la trampa lógica. La mitigación evidente del incidente —*"versionemos los recuperados para que no se pierdan otra vez"*— es la que yo mismo iba a proponerte hace dos minutos. Habría empujado ese fichero a los tres remotos, **dos de ellos en GitHub**. Y el documento describe exactamente ese escenario de ataque en su propia línea 119. Lo habríamos ejecutado nosotros, al intentar protegerlo. **Recuperar material sensible cambia el riesgo de sitio**: un fichero inerte meses en un disco local se vuelve candidato a publicarse justo cuando alguien lo rescata.
`─────────────────────────────────────────────────`
### Estado medido
| Comprobación | Resultado |
|---|---|
| Documentos de secretos recuperados | **7 de 7***corrijo mi error anterior*: `PLAN_REMEDIACION_B001` **sí** está, con sufijo `_S20260618` que omití al buscar. El recuento de `6f` era correcto, el mío no |
| Estado de versionado | **Todos siguen SIN versionar** salvo uno → **la recuperación no cerró el agujero** |
| Los 3 sin copia en ningún sitio | Ausencia confirmada |
| Credenciales en los otros 6 | 0 coincidencias |
### Lo que NO hice, y por qué
No borré, no edité, no limpié ese fichero y no roté nada. Es evidencia de una auditoría, y tocar material sensible o rotar secretos son **restricciones absolutas que exigen tu autorización explícita** (CA-3). Avisé a `6f` para que no lo commitee.
**Dato que eleva la urgencia:** tu estado vivo declara `secretos_mcp_memory_md = scrubeados_rotacion_pendiente` — Langfuse se limpió de `MEMORY.md` pero **la rotación quedó pendiente**. Que el servidor MCP de Langfuse hoy no resuelva por DNS **no prueba** que la credencial esté muerta.