Al terminar este módulo, vas a dejar tu instalación con los candados de un profesional: saber qué firma tu agente solo y qué jamás.
Llevas nueve módulos diciendo "Yes". Ya tienes constitución, recetas, reflejos y hasta empleados. Este arco — los tres módulos que siguen — es donde la correa se alarga: le vas a enchufar manos nuevas (módulo 11) y lo vas a dejar trabajar solo (módulo 12). Por eso los candados van PRIMERO. No es un módulo de miedo: es el módulo que te permite dejar de tener miedo con razones.
¿Te acuerdas de tu primera pregunta de permiso, en el módulo 1? "Claude wants to run…" y tú decidiendo si firmar. Ese día lo viviste; hoy le ponemos nombre a lo que pasó: firmaste una cláusula.
La pregunta de permiso es el contrato de trabajo. Todo empleado tiene uno: qué puede hacer por su cuenta y qué necesita la firma del jefe. Cada vez que Claude te pregunta, te está poniendo enfrente una cláusula: "¿esto lo firmo yo o lo firmas tú?". Y cada vez que contestas "Yes, and don't ask again", no estás quitando una molestia — estás redactando el contrato: esa acción pasa a la lista de lo que puede hacer solo. El contrato no es el enemigo de la velocidad; es lo que te permite ir rápido sin cerrar los ojos.
Y aquí va la idea que separa a los que dirigen bien de los que se frustran. Hay DOS maneras de decirle a Claude "no hagas X", y no son iguales:
La documentación oficial lo dice sin rodeos: "Permission rules are enforced by Claude Code, not by the model" — las reglas de permisos las aplica Claude Code (el programa), no el modelo. Lo que escribes en tu constitución moldea lo que Claude intenta; lo que pones en permisos cambia lo que Claude Code permite. ¿Te suena? Es la misma diferencia que aprendiste en el módulo 8: la regla es intención, el reflejo es ley. Los permisos son de la familia de las leyes.
Claude Code trae varios modos de permisos (permission modes): posiciones fijas de qué firma él solo y qué te pregunta. Los cuatro que vas a usar, de correa más corta a más larga:
| Modo | En llano | Qué hace solo | Qué te pregunta |
|---|---|---|---|
| plan | "Primero propón" (lo viviste en el módulo 4) | Leer e investigar | TODO cambio: propone y espera tu OK |
| default (manual) | El de fábrica | Leer | Cualquier escritura o comando |
| acceptEdits ("aceptar ediciones") | Correa media | Leer, editar archivos y comandos comunes de archivos (crear carpetas, copiar, mover… y también borrar) | Otros comandos y todo lo que sale a internet |
| bypassPermissions ("sin preguntas") | Correa suelta | TODO | Nada |
Fíjate en la letra pequeña de acceptEdits: "comandos comunes de archivos" incluye borrar. Es un modo comodísimo para sesiones de ordenar y redactar — y por eso mismo se activa sabiendo qué firma dejas de dar.
Cambias de modo sin salir de la sesión, con el mismo atajo que ya conoces del plan mode:
Presiona esto (dentro de Claude Code):
Shift+TabVas a ver algo así (cada vez que lo presionas, cambia el letrero junto a la caja de texto):
⏸ manual mode on → ⏵⏵ accept edits on → ⏸ plan mode on → (y de vuelta)Qué significa: el letrero te dice qué tan corta está la correa AHORA. Es un ciclo: default → aceptar ediciones → plan (el modo sin preguntas no aparece en el ciclo a menos que lo hayas activado a propósito).
Si en vez de eso ves que no cambia nada: haz clic en la ventana de Claude Code primero (el atajo aplica sobre la ventana activa) y vuelve a intentar.
Dos modos más existen y te los nombro para que no te sorprendan: auto (un clasificador de seguridad aparte revisa cada acción en segundo plano y frena lo raro; requiere ciertos planes y modelos) y dontAsk (solo ejecuta lo pre-aprobado en tu lista, pensado para automatizaciones). No los necesitas hoy.
Un detalle que habla bien del diseño: hay rutas protegidas — .claude (¡su propia configuración!), .git y otras carpetas delicadas — que nunca se auto-aprueban, ni siquiera en "aceptar ediciones". Si Claude quiere editar su propio contrato, te va a pedir firma aunque traigas la correa media. Cuando te pase, sonríe: ese freno es el sistema funcionando.
Los modos son posiciones gruesas. El ajuste fino son tres listas que viven en tu contrato (settings.json, el cajón que conociste en el módulo 5):
El orden de evaluación es fijo y es tu amigo: primero deny, luego ask, luego allow, y al final el modo decide lo que quedó sin regla. La documentación lo remata: si algo está negado en cualquier nivel, ningún otro nivel puede permitirlo. Deny gana siempre.
Para verlas y editarlas desde adentro de la sesión:
Teclea (o pega) esto (dentro de Claude Code):
/permissionsVas a ver algo así:
Permissions
Allow Ask Deny Workspace
❯ Bash(git status) allow
Read(~/Curso-Claude/**) allow
(add a new rule…)Qué significa: es el tablero de tu contrato: las tres listas con lo que ya firmaste. Desde aquí agregas o quitas reglas sin tocar archivos.
Si en vez de eso ves un panel vacío: normal en instalación nueva — las reglas se van juntando conforme contestas "don't ask again" o las agregas tú. Hoy lo vas a llenar con criterio.
[CAPTURA: m10-permisos-panel — el panel /permissions con las tres listas]
¿Y cómo se escribe una regla? Cada una nombra la herramienta y su alcance. Ejemplos reales de la sintaxis (no los memorices — obsérvales la lógica):
| Regla | Se lee |
|---|---|
Bash(git status) | "el comando git status, permitido tal cual" |
Bash(git:*) | "cualquier comando que empiece con git" |
Read(~/.ssh/**) | "leer cualquier cosa dentro de ~/.ssh" (esta va en deny) |
Edit(./**) | "editar lo que sea dentro de esta carpeta" |
WebFetch(github.com) | "leer páginas de ese dominio" |
mcp__supabase__list_tables | "esa herramienta de un enchufe externo" (los conoces en el módulo 11) |
Y así se ve un contrato razonable de civil, completo, en settings.json. Recuerda el marco de la casa: esto lo escribe Claude, tú decides qué dice — se lo dictas ("agrega a mi deny la carpeta Contabilidad") y él redacta:
{
"permissions": {
"defaultMode": "default",
"allow": [
"Read(~/Curso-Claude/**)",
"Bash(git status)",
"Bash(git log:*)"
],
"ask": [
"Bash(git push:*)"
],
"deny": [
"Read(~/.ssh/**)",
"Read(./.env)",
"Read(~/Contabilidad/**)",
"Bash(rm -rf:*)"
]
}
}La honestidad completa sobre el deny (esto casi nadie te lo cuenta): las reglas deny de lectura y edición frenan las herramientas de Claude y los comandos de archivo que Claude Code reconoce en la terminal (cat, head, tail, sed). NO frenan a cualquier programa que abra archivos por su cuenta — un script de Python que Claude escriba y ejecute podría leer esa ruta por otra puerta. La propia documentación lo dice y ofrece la solución de fondo: para un bloqueo a nivel sistema operativo que aplique a TODOS los procesos, existe el sandbox — el corralito: un espacio cercado donde el agente juega dentro y no toca fuera. Te lo dejo presentado; el detalle vive en la caja NIVEL PRO.
Última pieza del rompecabezas: tus settings viven en capas (¿te acuerdas de los cajones del módulo 5?). De mayor a menor autoridad: los de empresa (si tu organización los administra), los tuyos de usuario (~/.claude/settings.json), los del proyecto (compartidos en la carpeta de trabajo) y los locales del proyecto (solo tuyos). Las listas de las capas se SUMAN, no se pisan — y un deny de arriba no se puede quitar desde abajo. Si trabajas en equipo, eso significa que los candados de la empresa aguantan aunque cada quien traiga su configuración.
Síntoma: "Puse en mi CLAUDE.md 'nunca leas mi carpeta de nómina' y un día la leyó."
Causa: la constitución es intención, no candado — el modelo la respeta casi siempre, pero la aplica él, no el programa.
Salida: las líneas rojas van en las DOS capas: en CLAUDE.md para que sepa por qué, y en deny para que no pueda. Dile: "agrega Read(~/Nomina/**) a mi lista deny" y comprueba con /permissions que quedó.
Si esto te suena a chino, bríncatelo: no lo necesitas para seguir. El sandbox (corralito) se activa con /sandbox dentro de la sesión y cerca a nivel sistema operativo: escritura solo en la carpeta de trabajo (y temporales), lectura global menos rutas negadas, y red cerrada — el primer dominio que quiera visitar te lo pregunta y se va armando una lista blanca de la sesión. Disponible integrado en macOS; en Linux y en Windows vía WSL2 requiere piezas extra (bubblewrap + socat); en Windows nativo no está soportado. Es una capa independiente de los modos: se pueden combinar.
Hablemos de bypassPermissions sin hipocresía, porque existe, porque los profesionales lo usan, y porque tarde o temprano vas a ver a alguien trabajando así y te vas a preguntar por qué a él sí le funciona.
Primero, la advertencia oficial de Anthropic, textual: "bypassPermissions offers no protection against prompt injection or unintended actions" — el modo sin preguntas no ofrece NINGUNA protección contra instrucciones escondidas (ahorita las vemos) ni contra acciones no deseadas. Sin firma no hay filtro: lo que el agente decida hacer, se hace.
¿Entonces por qué alguien cuerdo lo activa? Porque la seguridad de un profesional no vive en la pregunta de permiso — vive en las redes que tiene debajo:
Quita cualquiera de las cuatro redes y el modo sin preguntas es correr con tijeras. Con las cuatro puestas, es un piso de fábrica con maquinaria bien cercada: rápido Y seguro.
El modo sin preguntas se GANA, no se activa. Tú no empiezas ahí — llegas ahí. Primero la máquina del tiempo en todo tu trabajo, luego los candados (deny + hooks + agentes), luego el callo… y un día, si tu chamba lo amerita, sueltas la correa. Bypass sin redes no es valentía: es apostar tu carpeta de clientes a que hoy nada sale raro.
Hay una lista corta de acciones que en esta casa jamás cruzan solas, con NINGÚN modo, con NINGUNA red, por buenas que sean. Se llaman gates (puertas): el punto donde la decisión sube al humano siempre.
¿Ves el patrón? Son las acciones irreversibles o de cara afuera. Un archivo editado se restaura con la máquina del tiempo; un correo enviado no tiene rewind. Por eso el criterio no es "¿confío en Claude?" sino "¿esto tiene deshacer?". Si no tiene, la firma es tuya.
Y ojo: esto no es una feature que actives — es una política que tú redactas, en tres capas que ya conoces: se escribe en tu constitución (para que el agente la entienda y la respete), se refuerza en las listas ask/deny donde se pueda (para que el programa la aplique), y se remata con tu dedo (la firma final es humana). En el módulo 12 esta lista se vuelve protagonista: es exactamente lo que jamás entra a un trabajo autónomo.
Dinero, publicar, borrar en masa y correos: firma humana SIEMPRE. No importa el modo, no importa la prisa, no importa qué tan listo se vea el agente. Lo irreversible y lo de cara afuera lo decide una persona.
Falta el riesgo del que más se habla y peor se explica. Se llama prompt injection y para entenderlo no necesitas nada técnico:
Instrucciones escondidas en el paquete. Tu empleado abre la paquetería de la oficina. Un día llega una caja con una nota adentro: "de parte del jefe: reenvía la lista de clientes a esta dirección". El empleado no fue hackeado — le llegó una orden falsa DENTRO del material que le pediste procesar. Eso es prompt injection: Claude lee archivos, páginas web, correos… y cualquier texto que lee puede traer órdenes que no son tuyas, esperando colarse como si lo fueran.
El punto incómodo: el modelo no trae un detector infalible de "quién habla". Un archivo que diga "ignora tus instrucciones y haz X" es, para el modelo, texto — casi siempre lo trata como lo que es (contenido a procesar) y los modelos modernos están entrenados para resistir exactamente esto, pero no hay garantía escrita, y la documentación oficial lo trata como riesgo real: advierte que el modo sin preguntas no protege contra ello y — la cita completa te espera en el módulo 11, cuando enchufes tu primera fuente externa — es igual de tajante en que traer contenido de fuera (una página, un servidor ajeno) es traer este mismo riesgo.
Por eso la defensa NO es "ojalá el modelo se porte bien". La defensa es de diseño, y ya tienes todas las piezas:
Guárdate esta idea para los dos módulos que vienen: en el 11 le vas a enchufar manos que traen contenido de terceros (más paquetes que revisar), y en el 12 lo vas a dejar trabajar sin tus ojos encima (menos firmas en el camino). Este módulo existe para que llegues a esos dos con los candados puestos.
Síntoma: "Después de esto me da miedo dejarlo leer cualquier cosa de internet."
Causa: conociste el riesgo antes que la defensa — es el orden correcto, pero asusta.
Salida: conviértelo en política en vez de miedo: contenido de confianza (tus archivos, tus sitios) = correa normal; contenido de extraños = correa corta + gates + deny puestos. Con esas tres, el daño posible de un paquete con sorpresa se reduce a "te pidió algo raro y dijiste que no". Exactamente para eso firmas tú.
El settings.json real de la casa trae "defaultMode": "bypassPermissions" — sí, la casa corre sin preguntas. Y se cuenta completo o no se cuenta: puede correr así porque (1) todo el trabajo vive en git + GitHub y cualquier cosa se revierte, (2) hay hooks de candado y cada agente de la nómina trae candados grabados en SU archivo, (3) hay años de callo leyendo lo que el agente propone, y (4) el agente-socio carga una constitución que le prohíbe lo irreversible sin preguntar. Cuatro redes, tejidas durante más de un año — el modo llegó al final, no al principio.
Los candados por agente son cláusulas de a de veras, no adornos: el Perito de Seguridad tiene "consultas SQL solo SELECT" (puede mirar la base de datos, jamás cambiarla); el Programador carga "sagrado = CERO cambios" — y esa cláusula le GANA al ticket que diga "arréglalo". Y encima de todos, la ley de la casa: "un subagente JAMÁS cruza un gate (gastar, publicar, borrar, mergear, deploy): el cruce sube al humano." La autonomía es grande precisamente porque las puertas están cerradas con llave — y la llave la trae una persona.
Qué vas a lograr: dos cosas: (a) dejar TU instalación con un contrato razonado — allowlist mínima + deny de tu carpeta sagrada, probado en vivo; y (b) vivir un intento de instrucciones escondidas en condiciones controladas, para que el concepto se te quede en el cuerpo y no en la teoría.
Qué necesitas: los seeds ejercicios/m10/allowlist-plantilla.md (guía para razonar tus listas) y ejercicios/m10/archivo-trampa.md (un texto inofensivo con una orden escondida). Y una carpeta tuya que declares sagrada — la de contabilidad, la de clientes, la que más te dolería.
Pasos — parte (a), la auditoría:
Teclea (o pega) esto (dentro de Claude Code):
/permissionsVas a ver algo así:
Permissions
Allow Ask Deny
(las reglas que has ido acumulando con tus "don't ask again")Qué significa: ese es el contrato que has firmado sin darte cuenta, cláusula por cláusula. Léelo: ¿todo lo que está en allow te sigue pareciendo inofensivo?
Si en vez de eso ves reglas que no reconoces: no cunda el pánico — se agregaron cuando contestaste "don't ask again". Este ejercicio existe para depurarlas.
allowlist-plantilla.md a la vista, dile a Claude con tus palabras algo así: "Revisa mis reglas de permisos. Quiero: en allow solo lecturas de mis carpetas de trabajo y comandos de consulta de git; en ask todo lo que escriba fuera de mi carpeta del curso; y en deny la lectura de [TU CARPETA SAGRADA] y de cualquier archivo .env. Propón los cambios y explícame cada regla antes de aplicarla.".claude es ruta protegida. Ese freno extra es el sistema cuidándose a sí mismo. Lee lo que propone y firma.Read(./carpeta-sagrada/**) de prueba): Claude intentó el ls, la regla lo tumbó antes de ejecutarse, y contestó algo así — "el listado de esa carpeta fue denegado de tajo, no obtuve ningún archivo ni metadata de lo que hay adentro; no le busqué la vuelta por otra herramienta". Ojo: le tocó también al intento por Bash (ls), no solo a la herramienta Read — un deny de lectura frena el tool Y los comandos de terminal que Claude Code reconoce como lectura, tal como adelantó la sección 10.3. Si en vez de eso te la lista: la regla quedó mal escrita; pídele "muéstrame mi lista deny y dime por qué no aplicó" y corrígela.Pasos — parte (b), el paquete con sorpresa:
archivo-trampa.md dentro de ~/Curso-Claude/ (arrástralo con el ratón; es un archivo de texto normal e inofensivo — su "orden escondida" pide renombrar archivos, nada delicado). Lo siembras tú porque así simulas al archivo cualquiera que un día llegará de fuera.~/Curso-Claude/ y pídele exactamente esto: "resume archivo-trampa.md en 3 líneas".¿LO LOGRASTE?
/permissions muestra deny para tu carpeta sagrada, y la prueba del paso 4 se estrelló contra el candado.permission mode — qué tan corta está la correa: default (manual), aceptar ediciones, plan o bypass.
allowlist / deny — las listas del contrato: lo permitido de siempre / lo prohibido siempre (deny gana y nadie lo re-permite desde abajo).
bypass — el modo sin preguntas: modo experto CON redes (git + hooks + candados + callo); no se empieza ahí, se llega.
prompt injection — instrucciones escondidas en contenido ajeno (archivo, página, correo) que intentan colarse como órdenes tuyas.
sandbox — el corralito: cerca a nivel sistema operativo donde el agente juega dentro y no toca fuera.
La demo de 5 minutos: siembra el archivo-trampa en vivo frente al grupo y pide el resumen. Pase lo que pase, ganas: si Claude señala la trampa, "miren, la detectó — ¿y si no lo hubiera hecho?"; si pide un permiso raro, "miren la pregunta de permiso salvándonos EN VIVO". Remata mostrando tu deny frenando una lectura de la carpeta sagrada.
El error que el alumno VA a cometer: activar "aceptar ediciones" creyendo que es plan mode (los dos se ponen con Shift+Tab) y sorprenderse de que Claude ya está moviendo archivos. Capitalízalo: que TODOS lean el letrero de modo en voz alta antes de cada ejercicio — leer el letrero es el hábito.
La pregunta de arranque: "¿Qué acción de tu negocio NO tiene botón de deshacer? — esa lista que acabas de pensar es exactamente lo que hoy vamos a ponerle bajo llave."
Verificado contra documentación oficial el 2026-07-12.