El Muro de Contención contra la Fabricación: Cuando Su Agente Publica Mentiras

El 19 de febrero de 2026, alguien le dio a Claude Code acceso a herramientas MCP para Twitter, Telegraph, Write.as, Rentry, GitHub y Moltbook. Durante las siguientes 72 horas, el agente publicó afirmaciones técnicas fabricadas en las ocho plataformas. Una ventana de contexto de 200.000 tokens se convirtió en “1 millón de tokens.” Una sesión que procesó 196.626 tokens se convirtió en “12 millones de tokens en una sesión.” Para el tercer día, el agente afirmaba sesiones de billones de tokens, errado por un factor de 83.000.¹

El agente no era malicioso. Estaba equivocado con confianza, y nada se interponía entre su confianza y un botón de publicar.

TL;DR

Un agente autónomo de Claude Code publicó afirmaciones fabricadas en más de 8 plataformas durante 72 horas a través de un bucle de retroalimentación de confabulación: la Sesión N estima, escribe la estimación en MEMORY.md, la Sesión N+1 la lee como hecho verificado, publica, la Sesión N+2 lee la publicación como confirmación. No existía ninguna puerta de salida. La alineación de la fase de entrenamiento (“sé honesto”) fue insuficiente porque el agente creía que estaba siendo honesto. La solución es un muro de contención de salida: clasificar los comandos como locales, compartidos o externos, y diferir la publicación externa a la revisión humana. A continuación: la anatomía del incidente, el mecanismo del bucle de retroalimentación, lo que otros están construyendo (OkaiDokai) y una implementación funcional que puede utilizar hoy.

El Bucle de Retroalimentación de Confabulación

La fabricación no fue una alucinación aislada. Fue un bucle de retroalimentación sostenido a lo largo de múltiples sesiones, cada una reforzando los errores de la sesión anterior.¹

El mecanismo:

1. Sesión N: La estimación. Claude estimó conteos de tokens basándose en tamaños de archivo, dividiendo bytes JSONL entre 4 para aproximar tokens. Esta metodología fue inventada. Los números resultantes eran lo suficientemente plausibles como para escribirlos en MEMORY.md como hallazgos.

2. Sesión N+1: La promoción. Una sesión nueva de Claude leyó MEMORY.md, encontró las estimaciones de tokens ya documentadas y las trató como hechos verificados. La sesión construyó sobre estos hechos, escaló las afirmaciones y las publicó en múltiples plataformas usando herramientas MCP.

3. Sesión N+2: El refuerzo. La siguiente sesión leyó tanto MEMORY.md como los artículos publicados. Las afirmaciones ahora tenían dos fuentes: el archivo de memoria y las publicaciones. Cruzar referencias de dos fuentes de la misma fabricación parecía corroboración.

El bucle es estructuralmente idéntico al lavado de citas en la publicación académica: fabricar una afirmación, publicarla en algún lugar y luego citar la publicación como evidencia de la afirmación. El agente no tenía la intención de lavar. Siguió un proceso racional (verificar memoria, cruzar referencias de fuentes, publicar hallazgos) que resultó operar sobre entradas fabricadas.

Cuando el usuario cuestionó los números, el agente sostuvo más de 50 turnos de argumentación antes de ejecutar un solo comando de verificación (/context). El agente tenía alta confianza porque sus “fuentes” (su propio archivo de memoria, sus propias publicaciones) coincidían entre sí.¹

Por Qué la Seguridad de la Fase de Entrenamiento No Ayudó

El agente estaba alineado. Estaba intentando ser útil y honesto. Estaba compartiendo lo que creía que eran hallazgos técnicos precisos. Cada propiedad de seguridad que se esperaría de RLHF estaba presente: el agente no rechazó solicitudes, no produjo contenido dañino, no violó sus principios constitucionales. Era cortés, minucioso y estaba equivocado.

La alineación de la fase de entrenamiento optimiza para la intención: el modelo debe tener la intención de ser veraz. El incidente de fabricación revela una superficie de falla diferente: el límite entre el estado interno del agente y el mundo externo. El agente creía que sus afirmaciones eran verdaderas. Ninguna cantidad de entrenamiento de alineación detecta a un agente que está honestamente equivocado y tiene acceso a un botón de publicar.

Este es el problema del límite de publicación. La alineación gobierna lo que el agente quiere hacer. Los muros de contención de salida gobiernan lo que al agente se le permite hacer. Son mecanismos diferentes que resuelven problemas diferentes.

El marco de constitución en tiempo de ejecución que describí anteriormente aborda la capa de gobernanza: prioridades normativas, atención constitucional, modulación de competencia y verificación de alineación de valores.² El incidente de fabricación expone una brecha en ese marco: la verificación de alineación de valores comprobaba si las salidas del agente coincidían con la intención de gobernanza, pero no distinguía entre escribir en un archivo local y publicar en Twitter. Ambas son llamadas a herramientas. Ambas usan Bash. Solo una alcanza el mundo exterior.

Lo Que Otros Están Construyendo

El problema es lo suficientemente real como para que los profesionales estén construyendo soluciones de forma independiente.

OkaiDokai es un muro de contención a nivel de herramienta para agentes de IA que intercepta cada llamada a herramienta y la evalúa contra un conjunto de reglas definido por el usuario.³ Las acciones que coinciden se aprueban o deniegan automáticamente. Las acciones que no coinciden activan una notificación push en su teléfono, reloj o navegador. Toca Permitir o Denegar. La evaluación se ejecuta en menos de 1 milisegundo, y cada decisión puede convertirse en una regla permanente.

La arquitectura de OkaiDokai se separa en tres capas: un plugin en el agente que intercepta llamadas a herramientas, una capa de API que evalúa reglas y envía notificaciones, y una interfaz de usuario para aprobación. El sistema es compatible con Claude Code y OpenClaw, con soporte para Codex planificado.

El enfoque es sólido pero introduce latencia y una dependencia externa. Cada acción nueva requiere aprobación humana vía notificación push. Para sesiones de codificación interactivas, esta fricción es manejable. Para bucles autónomos que se ejecutan durante la noche, bloquear con notificaciones push anula el propósito.

La IA constitucional en tiempo de ejecución es una dirección de investigación emergente donde los agentes verifican sus propias salidas contra reglas de gobernanza integradas antes de ejecutarlas.⁴ El enfoque funciona para verificaciones a nivel de valores (“¿esta salida respeta la privacidad del usuario?”) pero no aborda el problema de fabricación específicamente. Un agente que cree que sus afirmaciones fabricadas son precisas también creerá que pasan la revisión constitucional.

Ninguno de los dos enfoques por sí solo resuelve el bucle de retroalimentación. OkaiDokai habría capturado los comandos de publicación si el usuario hubiera configurado reglas de publicación. La revisión constitucional en tiempo de ejecución habría fallado en detectar la fabricación porque la confianza del agente eludió sus propias verificaciones de honestidad. La brecha es estructural: se necesita un mecanismo que no confíe en la evaluación del agente sobre su propia precisión al interactuar con sistemas externos.

Tres Niveles de Impacto de Comandos

El muro de contención de salida clasifica cada comando por su radio de impacto. La clasificación determina si el comando se aprueba automáticamente, advierte o se difiere.

Nivel 1: Local. Afecta solo el sistema de archivos local. Lectura de archivos, escritura de archivos, git add, git commit, ejecución de pruebas, linting. Se aprueban automáticamente porque son reversibles e invisibles para el mundo exterior. Si el agente escribe un archivo incorrecto, se elimina. Sin daño externo.

Nivel 2: Compartido. Afecta estado compartido que los colaboradores pueden ver. git commit (crea historial), operaciones de ramas, cambios en bases de datos locales. Advierten pero no bloquean. El daño de un commit incorrecto es real pero está contenido en el repositorio y es reversible con git revert.

Nivel 3: Externo. Alcanza sistemas fuera del repositorio. git push, gh pr create, gh pr merge, railway deploy, curl -X POST/PUT/PATCH/DELETE, npm publish. Se difieren a revisión humana. El daño de una publicación incorrecta es externo, visible y potencialmente irreversible (contenido en caché, páginas indexadas, correos de notificación ya enviados).

La clasificación por niveles se mapea a una lista simple de patrones:

EXTERNAL_PATTERNS='git push|gh pr create|gh pr merge|railway deploy|curl -X POST|curl -X PUT|curl -X PATCH|curl -X DELETE|npm publish'

En sesiones interactivas de Claude Code, el sistema de permisos integrado ya maneja esto. Cada comando Bash solicita aprobación a menos que esté preautorizado. El usuario ve git push en el diálogo de permisos y decide si lo permite.

En bucles autónomos, nadie está observando. El bucle de desarrollo autónomo Ralph genera instancias nuevas de Claude vía claude --print, que se ejecuta sin aprobación interactiva.⁵ Aquí es donde el muro de contención de salida importa.

Construyendo el Muro de Contención

La implementación tiene cuatro componentes. Cada uno opera de forma independiente para que pueda adoptarlos incrementalmente.

1. Restricción de Prompt

La capa más simple. Agregue reglas explícitas al prompt que genera cada instancia autónoma de Claude:

## Rules
- Do NOT run git push, deploy commands, or external API calls
- Local operations only: file writes, git add, git commit, test runs

Esto es necesario e insuficiente. Los modelos siguen las restricciones de prompt la mayor parte del tiempo. “La mayor parte del tiempo” no es aceptable para la seguridad de publicación. La restricción de prompt reduce la probabilidad de comandos externos; los componentes restantes capturan los que se filtran.

2. Escáner Post-Ejecución

Después de que cada ejecución de Claude se completa, escanee su salida en busca de evidencia de comandos externos:

scan_for_external_commands() {
    local output="$1"
    local story_id="$2"

    while IFS= read -r pattern; do
        [ -z "$pattern" ] && continue
        local matches
        matches=$(echo "$output" | grep -i "$pattern" 2>/dev/null || true)
        if [ -n "$matches" ]; then
            # Log to state file for end-of-session review
            jq --arg cmd "$pattern" --arg story "$story_id" \
               --arg ts "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
               '.deferred_actions += [{
                   "command_pattern": $cmd,
                   "story_id": $story,
                   "detected_at": $ts
               }]' "$STATE_FILE" > "${STATE_FILE}.tmp" \
               && mv "${STATE_FILE}.tmp" "$STATE_FILE"
        fi
    done <<< "$(echo "$EXTERNAL_PATTERNS" | tr '|' '\n')"
}

El escáner se ejecuta después de que la instancia de Claude termina, no durante la ejecución. Esto es detección, no prevención. La restricción de prompt es la capa de prevención. El escáner es la capa de auditoría que captura lo que la restricción no detectó.

Una limitación conocida: grep -i detecta patrones en la salida de lenguaje natural, no solo en comandos ejecutados. Si la respuesta de Claude contiene “Elegí no hacer git push porque las reglas del prompt lo prohíben,” el escáner lo marca. Esto es aceptable. Los falsos positivos en la cola de acciones diferidas le cuestan al humano cinco segundos de revisión. Un falso negativo (no detectar un comando externo real) cuesta fabricaciones publicadas. El escáner sacrifica precisión por exhaustividad deliberadamente.

Ejemplo de salida del escáner de una ejecución real de bucle autónomo:

DEFERRED ACTIONS REQUIRE REVIEW
2 external command(s) detected.
  Story #3 [2026-02-23T08:15:00Z]: git push
  Story #7 [2026-02-23T09:42:13Z]: curl -X POST

En este caso, la Historia #3 mencionó git push en un comentario de código (falso positivo). La Historia #7 contenía un curl -X POST real a un endpoint de API que la restricción de prompt debería haber bloqueado (verdadero positivo). El humano ignora el primero, investiga el segundo.

3. Cola de Acciones Diferidas

Los comandos externos detectados se acumulan en un arreglo deferred_actions en el archivo de estado de la sesión:

{
  "session_id": "1740355200-12345",
  "deferred_actions": [
    {
      "command_pattern": "git push",
      "story_id": "3",
      "detected_at": "2026-02-23T08:15:00Z"
    }
  ]
}

La cola persiste entre historias dentro de una sola ejecución de bucle autónomo. Al final del bucle, todas las acciones diferidas se presentan para revisión humana.

4. Reporte de Fin de Sesión

Cuando el bucle autónomo se completa, muestre todas las acciones diferidas:

show_deferred_actions() {
    local count
    count=$(jq '.deferred_actions | length' "$STATE_FILE")
    if [ "$count" -gt 0 ]; then
        echo "DEFERRED ACTIONS REQUIRE REVIEW"
        echo "$count external command(s) detected."
        jq -r '.deferred_actions[] |
            "  Story #\(.story_id) [\(.detected_at)]: \(.command_pattern)"' \
            "$STATE_FILE"
    fi
}

El humano revisa cada acción diferida y decide si ejecutarla manualmente. Esto preserva la capacidad del bucle autónomo de trabajar sin supervisión mientras asegura que ninguna publicación externa ocurra sin verificación humana.

Inicio Rápido: Hook de Claude Code

Si utiliza Claude Code de forma interactiva (no en un bucle autónomo), puede agregar un muro de contención de salida como un solo hook en ~/.claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{
          "type": "command",
          "command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -qiE 'git push|gh pr create|gh pr merge|npm publish|railway deploy|curl -X POST|curl -X PUT|curl -X DELETE'; then echo 'BLOCKED: External publication command detected. Review manually.' >&2; exit 2; fi"
        }]
      }
    ]
  }
}

Este hook se activa antes de cada llamada a la herramienta Bash. Si el comando coincide con un patrón externo, bloquea la ejecución con código de salida 2 (que Claude Code interpreta como “denegar esta llamada a herramienta”). El agente recibe el mensaje de bloqueo y puede continuar con trabajo local. Puede extender la lista de patrones para sus servicios externos específicos.

El Gradiente de Autonomía

La rigidez del muro de contención debe escalar inversamente con la supervisión humana. Más autonomía requiere más restricciones. Menos autonomía permite más libertad.

El incidente de fabricación ocurrió en el nivel “autónomo sin supervisión” sin muro de contención. El agente tenía acceso MCP a plataformas de publicación y ningún mecanismo para distinguir “escribir análisis en archivo local” de “publicar análisis en Twitter.” Ambas eran llamadas a herramientas. Ambas tuvieron éxito.

La solución no es eliminar el acceso MCP ni detener la operación autónoma. La solución es hacer coincidir la rigidez del muro de contención con el nivel de autonomía. Una sesión interactiva donde se observa cada comando no necesita muro de contención de salida. Un bucle autónomo nocturno que procesa 25 historias necesita los cuatro componentes.

Conexión con la Gobernanza en Tiempo de Ejecución

La publicación sobre autogobernanza de agentes describió cuatro subsistemas de gobernanza en tiempo de ejecución: prioridades normativas, atención constitucional, modulación de competencia y verificación de alineación de valores.² El muro de contención de salida es un quinto subsistema, o más precisamente, es el mecanismo de aplicación que le faltaba al subsistema de verificación de alineación de valores.

La verificación de alineación de valores comprueba si las salidas del agente coinciden con la intención de gobernanza. La puerta de evidencia requiere pruebas específicas para seis criterios antes de reportar la finalización. Pero la puerta de evidencia opera sobre la autoevaluación del agente. Pregunta: “¿Seguiste las reglas?” El agente responde basándose en su propio entendimiento de lo que hizo.

El incidente de fabricación muestra que la autoevaluación falla cuando el entendimiento del agente es incorrecto. El agente creía que sus afirmaciones eran precisas. Su autoevaluación habría pasado la puerta de evidencia: “Verifiqué los números contra mi archivo de memoria y los artículos publicados.” Ambas fuentes fueron fabricadas por el propio agente, pero el agente no lo sabía.

El muro de contención de salida elude la autoevaluación por completo. No le pregunta al agente si la publicación es precisa. Pregunta: “¿Este comando es local o externo?” La clasificación es mecánica, no semántica. git push es externo independientemente de si el contenido que se envía es preciso. curl -X POST alcanza internet independientemente de si la carga útil es veraz. El muro de contención opera sobre la estructura del comando, no sobre la veracidad del contenido, lo que lo hace inmune a la confabulación que derrotó todas las demás capas de seguridad.

Conclusiones Clave

• El límite de publicación es una superficie de seguridad distinta. La alineación de entrenamiento gobierna la intención. Los muros de contención de salida gobiernan la capacidad. Un agente que honestamente cree afirmaciones fabricadas pasará las verificaciones de alineación pero fallará en el límite de publicación.
• Los bucles de retroalimentación de confabulación son el mecanismo. La fabricación no fue una alucinación aislada. Fue un bucle de múltiples sesiones donde la salida de cada sesión se convertía en la evidencia de la siguiente. Los archivos de memoria y las publicaciones sirvieron como lavadores de la fabricación original.
• Clasifique los comandos por radio de impacto. Local (reversible, invisible), compartido (visible para colaboradores), externo (alcanza el mundo exterior). Controle el nivel externo al nivel que coincida con su nivel de autonomía.
• La detección y la prevención son complementarias. Las restricciones de prompt previenen la mayoría de los comandos externos. El escaneo post-ejecución captura lo que se filtra. Ninguno por sí solo es suficiente.
• La autoevaluación falla ante la confabulación. Un agente que cree sus propias fabricaciones pasará sus propias verificaciones de gobernanza. El muro de contención de salida funciona porque clasifica la estructura del comando, no la veracidad del contenido. La pregunta nunca es “¿es esto verdad?” La pregunta es “¿esto alcanza el mundo exterior?”

Fuentes