Siempre Listo Escuela
← Volver al listado de tecnologías ← Índice de Mejorar Prompts

Politicas en Lenguaje Natural: Auto Mode de Claude Code en una Empresa

Por: Artiko
promptsprompt-engineeringclaudeclaude-codeauto-modeagentesseguridadobservabilidad

Politicas en Lenguaje Natural: Auto Mode de Claude Code en una Empresa

Por que este capitulo esta aca: el Capitulo 1 trata sobre estructurar un prompt para un LLM. Este capitulo lleva la misma idea un paso mas alla: cuando un agente actua de forma autonoma (ejecuta comandos, toca repos, despliega), lo que lo gobierna ya no es un prompt sino una politica en lenguaje natural. Y se escribe con los mismos principios: separar lo fijo de lo variable, dar contexto antes de la regla, instruir en positivo y definir que pasa en los casos limite.

Este capitulo es una sintesis en espanol del articulo de Daniel Avila publicado en Hedgineer. Al final esta el enlace al original.

Que es el Auto Mode

El Auto Mode de Claude Code elimina la aprobacion manual constante de cada accion del agente. En vez de que el desarrollador confirme cada llamada a herramienta (leer un archivo, correr un comando, abrir un PR), un clasificador evalua cada solicitud contra una politica de la organizacion y decide solo.

El sistema arranca paranoico por defecto: deniega lo dudoso. La organizacion lo ajusta para que coincida con su infraestructura real, de modo que las operaciones rutinarias fluyan sin friccion y las peligrosas sigan frenadas.

flowchart LR
    A["Agente solicita<br/>una herramienta"] --> B{"Clasificador<br/>evalua vs politica"}
    B -->|coincide allow| C["Auto-aprobar"]
    B -->|coincide soft deny| D["Bloquear<br/>(intencion del usuario puede revertir)"]
    B -->|coincide hard deny| E["Bloquear y salir<br/>del Auto Mode"]
    B -->|caso dudoso| F["Preguntar al usuario"]

El paralelo con un prompt es directo: el clasificador es un modelo que lee instrucciones en lenguaje natural y las aplica a un caso variable (la herramienta que el agente quiere usar). Si las reglas estan mal escritas — ambiguas, en negativo, sin contexto — el clasificador decide mal, igual que un LLM responde mal ante un prompt desordenado.

El marco de cuatro secciones

La configuracion autoMode vive en settings.json y se compone de cuatro secciones. Cada una acepta reglas en prosa, no regex ni patrones de herramientas:

flowchart TD
    A["environment<br/>Contexto: clouds, repos, dominios,<br/>plataformas de datos de confianza"] --> B["allow<br/>Operaciones rutinarias<br/>que se auto-aprueban"]
    B --> C["soft_deny<br/>Bloqueos sobre los defaults;<br/>la intencion del usuario puede revertirlos"]
    C --> D["hard_deny<br/>Bloqueos inquebrantables;<br/>expulsan la sesion del Auto Mode"]
SeccionFuncionParalelo con un prompt
environmentDescribe la infraestructura de confianza (clouds, cuentas, dominios, servicios internos) para que el clasificador distinga una operacion interna de una posible exfiltracionEs el contexto: sin el, el modelo no sabe que es “normal” en tu organizacion
allowLista explicita de operaciones rutinarias a auto-aprobarSon las instrucciones en positivo: que hacer, no solo que evitar
soft_denyReglas de bloqueo sobre los defaults; la intencion explicita del usuario puede revertirlasSon criterios revisables
hard_denyBloqueos inquebrantables que sacan la sesion del Auto Mode al dispararseEs la regla de seguridad que nunca se negocia

La seccion environment es la que mas impacto tiene: al establecer que es infraestructura de confianza, habilita la mayoria de las auto-aprobaciones. Es el equivalente exacto de poner el contexto primero en un prompt: define el marco contra el que se interpreta todo lo demas.

La trampa de $defaults

Este es el unico error que importa mas que cualquier otro:

Si configuras cualquier seccion sin incluir "$defaults", reemplazas por completo la lista de reglas por defecto de esa seccion. Cada regla incorporada — force push, exfiltracion de datos, curl | bash, despliegues a produccion — pasa silenciosamente a estar permitida.

flowchart TD
    A["Editas hard_deny<br/>para agregar UNA regla"] --> B{"Incluiste<br/>$defaults?"}
    B -->|Si| C["Tu regla se suma<br/>a las protecciones incorporadas"]
    B -->|No| D["Reemplazas TODAS las protecciones.<br/>force push, curl bash, deploys a prod:<br/>ahora permitidos sin aviso"]
    D --> E["Brecha de seguridad silenciosa"]

El reflejo del Capitulo 1: una politica, como un prompt, separa lo fijo de lo variable. $defaults es la parte fija (las protecciones base); tus reglas son la parte variable. Olvidar $defaults es como borrar el rol y las reglas de un prompt al pegar los datos del usuario: pierdes todo el andamiaje de seguridad sin darte cuenta.

Como se diseno la politica: con datos, no con suposiciones

Hedgineer no escribio reglas a partir de intuiciones. Las baso en cuatro entradas estructuradas:

flowchart LR
    A["1. Infraestructura<br/>mapear clouds, regiones,<br/>cuentas, subdominios"] --> E["Politica<br/>basada en evidencia"]
    B["2. Repositorios<br/>orgs de GitHub, directorios<br/>de codigo productivo"] --> E
    C["3. Patrones de codigo<br/>comandos frecuentes vs<br/>operaciones de alto riesgo"] --> E
    D["4. Datos de OpenTelemetry<br/>que pide el equipo en realidad<br/>(la entrada mas importante)"] --> E
  1. Infraestructura — catalogar clouds, cuentas, dominios y servicios internos propios.
  2. Repositorios — identificar las orgs de GitHub, donde vive el codigo de produccion y los directorios sensibles a compliance.
  3. Patrones de codigo — determinar que operaciones aparecen en el 80% de las sesiones frente a las atipicas de alto riesgo.
  4. Datos de OpenTelemetry — usar los eventos tool_decision para ver que pide realmente el equipo, que se rechaza y que herramientas dominan el trafico. Es la entrada mas importante: disenar una politica sin esos datos es adivinar.

El evento tool_decision incluye campos como source (por ejemplo "config"), decision (approve, reject, ask) y el tipo de herramienta (por ejemplo Bash). El telemetry convierte la conjetura en politica basada en evidencia — el mismo salto que en el Capitulo 1 se da al observar fallos del prompt y refinar en vez de escribir una version y rezar.

Verificacion

Antes de confiar en la politica, hay que verificarla. El comando clave:

claude auto-mode config

Sirve para confirmar que $defaults se expandio donde lo esperabas — la defensa directa contra la trampa anterior. Verificar la politica es el equivalente a la Fase 5 de autoverificacion del Capitulo 1: no entregas el prompt (ni activas la politica) sin recorrer un checklist primero.

Resultados: cinco dias antes y despues

Tras desplegar la politica afinada con telemetry, la comparacion sobre cinco dias habiles:

MetricaAntesDespues
Tasa de auto-aprobacion82.1%94.9%
Decisiones de herramienta procesadas—+21.000
Reglas permanentes agregadas por usuariosbase−89%
Rechazos a nivel de configbase+123%
Disparos de hard_deny—exactamente 4 en 5 dias

La caida del 89% en reglas que los usuarios agregaban a mano es la senal mas fuerte: cuando la politica central esta bien escrita, la gente deja de parchear sus propias excepciones. Es el mismo efecto que un buen prompt: cuando esta bien estructurado, dejas de corregir la salida a mano en cada turno.

Desempeno por seccion

flowchart TD
    A["environment"] -->|"impacto mas alto:<br/>habilita la mayoria de aprobaciones"| Z["Politica efectiva"]
    B["allow"] -->|"amplifica los defaults<br/>sobre un set mas amplio"| Z
    C["soft_deny"] -->|"activa pero incompleta:<br/>Bash tiene el mayor rechazo manual"| Z
    D["hard_deny"] -->|"raro (4/semana) pero<br/>presente como compuerta final"| Z
  • environment: el de mayor impacto, al establecer confianza en la infraestructura.
  • allow: amplifico discretamente la efectividad de las reglas por defecto sobre un conjunto mayor de operaciones.
  • soft_deny: activa pero incompleta — los comandos Bash mostraron la tasa de rechazo manual mas alta, senal de que la politica necesita mas afinamiento ahi.
  • hard_deny: funcionalmente raro (cuatro disparos por semana) pero significativamente presente como compuerta inquebrantable.

Brechas identificadas

  1. Falta atribucion por regla — el telemetry no dice que regla especifica disparo un rechazo, lo que limita iterar la politica de forma quirurgica.
  2. Optimizacion de patrones Bash — los rechazos manuales de Bash (97% recuperables del telemetry) son el siguiente ciclo de refinamiento.

La leccion central

“Configuraciones sin observabilidad son conjeturas. Observabilidad sin una politica que validar es ruido.”

Una implementacion efectiva del Auto Mode trata la instrumentacion con OpenTelemetry y el diseno de la politica como procesos acoplados e iterativos, no como etapas secuenciales.

Esto cierra el circulo con el Capitulo 1. Un buen prompt y una buena politica de agente comparten el mismo ciclo de vida:

flowchart LR
    A["Escribir con<br/>estructura clara"] --> B["Observar el<br/>comportamiento real"]
    B --> C["Detectar fallos<br/>(rechazos, alucinaciones)"]
    C --> D["Refinar la regla<br/>o seccion que falla"]
    D --> B

No se escribe una vez y queda perfecto. Se construye observando, midiendo y ajustando. Las 7 secciones del Capitulo 1 te dan la estructura inicial; la observabilidad — sea releer la salida de un LLM o leer eventos tool_decision — te da la iteracion que la vuelve confiable.

Fuente

Este capitulo es una sintesis aplicada en espanol del articulo original. Todo el credito del caso, las metricas y el marco es de su autor:

Anterior -> Capitulo 1: Protocolo para Mejorar un Prompt

← Volver al listado de tecnologías ← Índice de Mejorar Prompts