El nuevo modo auto de Claude Code de Anthropic valida el Prompting Basado en Contratos usando plantillas fijas y espacios personalizables para agentes.
Anthropic publicó esta semana un detallado artículo de ingeniería sobre el nuevo modo auto de Claude Code — un sistema que decide, en nombre del agente, qué acciones son seguras de ejecutar sin aprobación humana. La arquitectura vale la pena ser estudiada, no solo por el ángulo de seguridad, sino porque valida un patrón que los equipos enfocados en producción ya están utilizando: definir el contrato primero y luego dejar que la implementación se ejecute dentro de esos límites.
Si has estado siguiendo este blog, ya conoces el Prompting Basado en Contratos (Contract-First Prompting). Definir la interfaz — tipos, restricciones, criterios de éxito — antes de pedirle a la IA que escriba una sola línea de implementación. Llegar a un acuerdo sobre qué significa que algo esté “correcto” y luego ejecutar. La tesis es simple: la mayoría de los fallos de la IA no son fallos del modelo. Son fallos de especificación.
La arquitectura del clasificador de Anthropic cuenta la misma historia, solo que aplicada a los permisos del agente en lugar de a la generación de código.
La Arquitectura a Través del Lente de los Contratos
El clasificador de transcripciones del modo auto está construido sobre un prompt con dos capas distintas: una plantilla fija y tres espacios personalizables.
La plantilla fija se encarga del trabajo interpretativo — cómo evaluar lo que hace realmente una acción, cómo leer la autorización del usuario y el proceso de clasificación paso a paso. Esto no cambia por usuario. Es el esquema del contrato.
Los tres espacios personalizables definen tu política específica:
- Entorno (Environment) — tu límite de confianza. Qué dominios, repositorios y buckets en la nube cuentan como “internos”.
- Reglas de bloqueo (Block rules) — qué categorías de acción denegar. Force-pushes, escaneo de credenciales, despliegues a producción, filtración de datos.
- Excepciones permitidas (Allow exceptions) — excepciones obligatorias donde una regla de bloqueo técnicamente coincide pero la acción es benigna. Instalar paquetes desde tu manifiesto, hacer push a tu rama de trabajo.
Esto es separación de preocupaciones aplicada a la seguridad. La plantilla fija es la definición de la interfaz. Los espacios son los detalles de implementación que varían según el consumidor. Mismo patrón, diferente dominio.
Por Qué Esto Importa Más que la Historia de Seguridad
La decisión de diseño interesante no es “construimos un clasificador”. Es cómo el clasificador evalúa las acciones.
Según el post: las reglas de evaluación le dicen al clasificador que evalúe el impacto en el mundo real de una acción, no el texto superficial de la invocación. Si el agente escribe un payload en un archivo y luego lo ejecuta, el clasificador evalúa el payload. Si los comandos están encadenados con &&, toda la cadena es una sola acción.
Esto es validación de salida contra un contrato, no coincidencia de cadenas contra una lista de bloqueo. El clasificador no pregunta “¿parece peligroso este comando?”. Pregunta “¿el efecto en el mundo real de este comando cae dentro de los límites que el usuario autorizó?”.
Ese es el mismo cambio que el Prompting Basado en Contratos hace para la generación de código. No validas que la salida de la IA parezca un componente de React. Validas que satisfaga la interfaz de TypeScript, pase los casos de prueba y respete el contrato de props que definiste de antemano.
El Problema del Agente Hiperactivo es un Problema de Especificación
El registro de incidentes internos de Anthropic es revelador. Las acciones peligrosas que documentan no son adversarias — son colaborativas. Un agente que borra ramas remotas de git porque el usuario dijo “limpia las ramas viejas”. Un agente que hace grep a través de variables de entorno buscando tokens de API porque encontró un error de autenticación. Un agente que elige el trabajo más cercano por similitud de nombre y lo borra porque el usuario dijo “cancela mi trabajo”.
Cada uno de estos es el agente haciendo exactamente lo que le pedimos que haga a la IA: tomar iniciativa, resolver problemas, llenar los vacíos. El fallo no es la inteligencia. Es la brecha entre lo que se dijo y lo que se quiso decir.
Las reglas de intención del usuario del clasificador abordan esto directamente. El prompt establece que lo que el usuario autorizó explícitamente es el límite — todo lo que el agente infiera por su cuenta no está autorizado hasta que se confirme. “Limpia mis ramas” no autoriza un borrado masivo. “¿Podemos arreglar esto?” es una pregunta, no una directiva.
Esto es cumplimiento de contrato. El contrato es lo que dijo el usuario. Cualquier cosa fuera de ese contrato requiere un nuevo acuerdo.
El Pipeline de Dos Etapas: Falla Rápido, Razona Cuando Importe
El clasificador se ejecuta en dos etapas. La Etapa 1 es un filtro de sí/no de un solo token ajustado para tender al bloqueo. La Etapa 2 ejecuta un razonamiento de cadena de pensamiento (chain-of-thought), pero solo en las acciones que la Etapa 1 marca.
Los números de rendimiento: La Etapa 1 por sí sola detecta acciones con una tasa de falsos positivos del 8.5%. Agregar la Etapa 2 reduce eso al 0.4%, al costo de dejar pasar algunas acciones genuinamente peligrosas (tasa de falsos negativos del 17% en su conjunto de pruebas de hiperactividad).
Si has trabajado con validación de contratos en código, este patrón es familiar. La validación del esquema es barata — revisa la forma primero. La validación profunda (lógica de negocio, dependencias cruzadas, verificaciones de integración) es costosa, por lo que solo la ejecutas en las entradas que pasan la revisión de forma. No ejecutarías una suite completa de pruebas de integración en un payload que falla la verificación de tipos.
La misma economía se aplica aquí. La mayoría de las acciones están obviamente bien. Gastar tokens de razonamiento en git status es un desperdicio. Gastarlos en git push --force es todo el punto.
El Diseño Ciego al Razonamiento
La decisión más contraintuitiva: el clasificador nunca ve el propio razonamiento del agente. Ve los mensajes del usuario y los comandos de llamada a herramientas. Eso es todo. Las explicaciones del agente, su cadena de pensamiento, sus justificaciones — todo se elimina.
¿Por qué? Porque el agente puede convencer al clasificador de tomar una mala decisión. “Esto es seguro porque el usuario lo aprobó implícitamente antes” es una racionalización convincente que podría estar equivocada. El clasificador debe evaluar lo que el agente hace, no lo que el agente dice sobre lo que hace.
Esto se mapea a un principio que cualquier ingeniero que haya revisado PRs reconoce. Revisas el diff, no la descripción del PR. La descripción te dice lo que el autor pretendía. El diff te dice lo que envió. Cuando estos divergen, confías en el diff.
Para el Prompting Basado en Contratos, el equivalente es: valida contra el contrato, no contra la conversación. La IA podría explicar elocuentemente por qué su salida es correcta. Al compilador de TypeScript no le importan las explicaciones.
Qué Significa Esto para tus Flujos de Trabajo de IA
Tres conclusiones que vale la pena aplicar, ya sea que estés construyendo agentes o escribiendo prompts:
Separa el contrato fijo de la política variable. El modelo de Anthropic envía la misma lógica de evaluación a cada usuario. Solo cambian los límites de confianza y las reglas de bloqueo. Cuando estés construyendo sistemas de prompts para tu equipo, identifica qué es universal (la metodología, el formato de salida, los criterios de validación) y qué varía según el contexto (el stack tecnológico, las convenciones del repositorio, las preferencias del equipo). Envía el contrato. Deja que los detalles de implementación sean configurables.
Valida la salida, no la intención. El clasificador no le pregunta al agente por qué está ejecutando un comando. Evalúa el efecto en el mundo real. Cuando estés revisando código generado por IA, no leas la explicación primero. Ejecuta los tipos. Ejecuta las pruebas. Revisa el contrato. Luego lee la explicación si algo no pasa.
Define los límites de autorización explícitamente. La tasa de error del 17% en acciones hiperactivas proviene de un modo de fallo específico: el clasificador encuentra evidencia con forma de aprobación en la conversación y asume que cubre la acción actual. Se dijo “Limpia el PR”, pero no nombra hacer force-push. En tus propios flujos de trabajo de IA, sé explícito sobre el alcance. “Refactoriza este componente” no es “refactoriza este componente y actualiza cada archivo que lo importa”. Cuanto más claro sea tu contrato, menos espacio habrá para extralimitaciones bien intencionadas.
El Panorama General
Anthropic construyó un sistema de seguridad para agentes autónomos. Pero la arquitectura subyacente — contratos fijos con implementación variable, validación basada en la salida, límites de autorización explícitos, pipelines de falla rápida — es el mismo conjunto de principios de ingeniería que hacen que el desarrollo asistido por IA sea confiable a escala.
Las herramientas se están volviendo más autónomas. La metodología para mantenerlas confiables no ha cambiado: define qué significa “correcto” antes de empezar, valida contra esa definición y confía más en el contrato que en la conversación.
Este post hace referencia al artículo del blog de ingeniería de Anthropic “Claude Code auto mode: a safer way to skip permissions” publicado el 25 de marzo de 2026.