PTENES
MÓDULO 2.4 · Ruta 2 · Creación práctica

🔑 Herramientas y permisos

Un subagente bien configurado hace solo lo que necesita, ni más ni menos. Aprender a limitar herramientas es la diferencia entre un agente confiable y uno que dudas en ejecutar en producción.

7
Temas
~30
Minutos
Medio
Nivel
Práctica
Tipo

Piensa en una bóveda con varias capas de seguridad. Qué puede hacer el agente puede hacer está determinado por las herramientas que enumeras en el campo tools — no por el texto del prompt. El prompt dice "qué hacer"; las herramientas dicen "con qué". Mezclar ambos es el error más común al crear subagentes.

Subagente intenta Write() CAPA DE HERRAMIENTAS campo tools: [...] ✓ Read ✓ Grep ✗ Write (bloqueado) ✗ Bash (bloqueado) CAPA DE PROMPT campo description: "Lee archivos .ts y reporta problemas" (orienta el comportamiento) (no concede acceso) Ejecución solo lee, nunca escribe Capa de permisos (tools) = lo que es estructuralmente posible Capa del prompt (description) = cómo se comporta el agente dentro de lo posible

Contenido detallado

1

🎯 Dar solo lo necesario

El principio del mínimo privilegio es simple: un agente que no necesita escribir no debe tener permiso para escribir. Parece obvio, pero se viola constantemente. El costo de ser demasiado generoso con las herramientas no aparece en el primer uso; aparece cuando el agente toma una decisión inesperada en producción.

Principio del mínimo privilegio aplicado a subagentes

Cada herramienta que agregas al campo tools amplía el alcance de acción del agente. Expándelo solo cuando el agente necesite la herramienta para cumplir el objetivo específico. Si tienes dudas, empieza sin ella: puedes agregarla después; reparar daños en producción es mucho más costoso.

Borrador — sin restricción

Incluyes todo: Read, Write, Bash, WebSearch. El agente funciona, pero no es auditable.

Refinamiento — solo lo que usa

Observas qué herramientas llamó realmente el agente. Elimina las demás.

Producción — mínimo validado

Solo las herramientas necesarias. El comportamiento es predecible y el riesgo, controlado.

Qué es: restricción estructural que determina lo que el agente puede hacer, independientemente de lo que diga el prompt.
Por qué importa: daño accidental e imposible cuando la herramienta destructiva simplemente no existe en el contexto del agente.
Conceptos clave: privilegio mínimo · campo tools · expande solo cuando sea necesario · auditabilidad.
2

📖 Agentes de solo lectura: Read, Grep, Glob

La mayoría de los agentes de análisis, revisión e investigación no necesitas escribir nada. El trío Read, Grep e Glob cubre prácticamente todos los casos de uso de lectura — inspeccionar archivos, buscar patrones, listar la estructura. Con solo estas tres, creas un agente que puede aprender todo sobre el repositorio sin cambiar un byte.

✓ Qué abarca el trío

  • ✓Read — leer cualquier archivo del proyecto, incluidos configs y secretos (cuidado al informar)
  • ✓Grep — buscar patrones en texto, ideal para encontrar funciones, TODOs, imports
  • ✓Glob — listar archivos de forma predeterminada, mapear la estructura de carpetas
  • ✓Combinados: mapeo completo + búsqueda semántica + lectura de contexto

✗ Qué no hacen

  • ✗Crear o modificar archivos (Write)
  • ✗Ejecutar comandos del sistema (Bash)
  • ✗Hacer requests HTTP (WebFetch, WebSearch)
  • ✗Interactuar con servidores MCP externos

Consejo: Glob + Read en secuencia

Un patrón muy útil: usa Glob para descubrir qué archivos existen y luego Read para leer solo los relevantes. Eso es mucho más eficiente que pedirle al agente que "lea todo": priorizará según el patrón que definiste en el Glob.

Qué es: conjunto mínimo de herramientas para agentes que solo observan e informan — sin capacidad de alterar el estado.
Por qué importa: los agentes read-only son seguros para ejecutarse sin supervisión — lo peor que pueden hacer es entregar un informe incorrecto.
Conceptos clave: Read · Grep · Glob · estado inmutable · revisión segura.
3

⚖️ Permitido x no permitido — la lista concreta

El archivo .md de un subagente tiene un campo tools que recibe una lista. Todo lo que está en la lista está permitido — todo lo que queda fuera se bloquea automáticamente, sin ninguna configuración adicional. No existe "negar explícitamente": tú incluye lo que puede, el resto no existe para el agente.

Herramienta Categoría Riesgo si se incluye sin necesidad Incluir cuando...
Read Lectura Bajo (puede leer secretos) Necesita inspeccionar el contenido de los archivos
Grep Búsqueda Bajo Necesita buscar patrones en el codebase
Glob Listado Bajo Necesita mapear la estructura de archivos
Write Escritura Medio (modifica archivos) El agente necesita generar o editar artefactos
Edit Escritura Medio (parche en archivos) El agente necesita hacer ediciones precisas
Bash Ejecución Alto (ejecuta cualquier comando) El agente necesita ejecutar scripts/pruebas
WebFetch Red Alto (acceso externo) El agente necesita buscar datos externos
Qué es: lista blanca (allowlist) de herramientas — incluye lo permitido; el resto queda bloqueado automáticamente.
Por qué importa: el modelo mental de «denegar por defecto» es más seguro que intentar enumerar lo que está prohibido.
Conceptos clave: lista de permitidos · denegar por defecto · campo tools · niveles de riesgo por herramienta.
4

🔌 MCP permitidos — acceso al mundo externo

Herramientas MCP (Model Context Protocol) dan al agente acceso a sistemas externos: bases de datos, APIs, navegadores, servicios. Son más poderosas — y más riesgosas — que las herramientas nativas. La decisión de incluir un MCP en un subagente debe ser intencional y específica: ¿el agente necesita este servidor MCP para completar su función?

Cómo se heredan los MCP servers

Por defecto, los subagentes heredan los servidores MCP del contexto principal. Esto significa que si tienes un servidor de base de datos configurado globalmente, el agente hijo también puede acceder a él — a menos que lo restrinjas explícitamente con mcpServers: [] (lista vacía = ningún MCP) o enumera solo los permitidos.

  • →Herencia predeterminada: todos los MCP del contexto principal están disponibles
  • →Restricción total: mcpServers: [] — sin acceso a ningún MCP
  • →La lista especifica: solo están disponibles los servidores incluidos en la lista

✓ Los MCP suelen ser seguros para subagentes

  • ✓MCP de lectura de la base de datos (solo SELECT)
  • ✓MCP de búsqueda (Brave, tavily) con límite de solicitudes
  • ✓MCP de acceso a la documentación interna (solo lectura)
  • ✓MCP de GitHub para leer PR y issues

✗ MCP que requieren una revisión cuidadosa

  • ✗MCP que puede enviar correos electrónicos o mensajes
  • ✗MCP con acceso de escritura a la base de datos
  • ✗MCP para ejecutar deploys o tareas de infraestructura
  • ✗MCP de pagos o facturación
Qué es: MCP servers amplían el alcance del agente a sistemas externos: herencia automática del contexto principal.
Por qué importa: un agente de análisis de código no necesita — y no debería tener — acceso a un MCP de despliegues.
Conceptos clave: herencia de MCP · mcpServers: [] · restricción explícita · principio de aislamiento.
5

🛡️ El permiso real supera el prompt «no lo hagas»

Una de las trampas más comunes: incluir en el prompt instrucciones como «nunca elimines archivos» o «no ejecutes comandos del sistema» mientras el campo tools todavía incluye Bash. El prompt es orientación; el campo tools es ley. Las instrucciones en lenguaje natural pueden malinterpretarse, ignorarse bajo presión o evadirse; la lista de herramientas, no.

No confíes solo en el prompt para la seguridad

El agente recibe el prompt como contexto de alto nivel, pero el LLM es un sistema probabilístico. En escenarios de mucha presión, instrucciones ambiguas o cadenas largas, puede:

  • —Razonar que "la excepción se aplica a este caso específico"
  • —Interpretar una instrucción vaga de manera inesperada
  • —Ser manipulado por prompt injection en el contenido que procesa

Elimina la herramienta. No le indiques al agente que no la use.

Regla práctica: las herramientas como contrato, el prompt como estilo

Usa el campo tools para definir lo que el agente puede hacer (contrato inmutable). Usa el prompt / description para definir como debe hacer (tono, formato, criterios). Mezclar ambos — usar el prompt para prohibir lo que permite el tools — es una falsa seguridad.

Qué es: la restricción estructural (tools) es absoluta; las instrucciones en el prompt son probabilísticas y se pueden eludir.
Por qué importa: la seguridad real no depende de que el LLM siga instrucciones: depende de que el LLM no tenga la herramienta necesaria para causar el daño.
Conceptos clave: tools como contrato · prompt como estilo · falsa seguridad · prompt injection.
6

👁️ "Si puede leerlo, asume que lo hará"

Cuando incluyes Read en el campo tools, el agente puede leer cualquier archivo accesible en el proyecto — incluso .env, claves SSH, tokens en configuraciones. Esto es esperado y útil, pero exige que sepas qué hace el agente puede hacer y que los informes que genera no filtren datos sensibles.

code-reviewer — ejecución ILUSTRATIVO
→ Read(".env")
# el agente puede leer — tools incluye Read
→ leyendo 12 variables de entorno...
→ análisis completado
INFORME — code-reviewer
Encontré 3 variables sin prefijo de alcance. Detalles enviados
al orquestador. [valores ocultos por seguridad]
✓ Bien: el agente leyó, analizó y ocultó valores en el informe
✗ Malo: el agente leyó y reprodujo los valores en el informe

Indica al agente que no reproduzca datos sensibles

Para agentes con acceso de lectura en proyectos reales, incluye en el prompt: "Nunca reproduzcas valores de variables de entorno, claves, tokens ni contraseñas en los informes. Menciona solo que existen y si están configurados correctamente." Aquí sí es el prompt y el lugar correctos: no estás prohibiendo una herramienta, estás orientando el comportamiento dentro de lo permitido.

Qué es: el acceso de lectura implica acceso a todo el contenido legible — incluidos los datos sensibles del repo.
Por qué importa: los informes generados por agentes pueden filtrar datos si el agente reproduce sin filtro lo que leyó.
Conceptos clave: acceso implícito · datos sensibles · separación lectura / informe · instrucción de ocultación.
7

🔬 Granularidad — Bash y el caso especial

Bash y la herramienta más poderosa y la que exige más cuidado. Con Bash, el agente puede ejecutar cualquier comando del sistema: instalar paquetes, eliminar archivos, hacer solicitudes con curl, iniciar procesos. Cuando Bash sea necesario, la granularidad viene de la descripción precisa en el prompt sobre cuáles comandos se esperan, combinada con allowedTools en settings.json del proyecto para restringir qué binarios se pueden llamar.

code-reviewer.md — ejemplo de subagente de solo lectura ejemplo .md
---
name: code-reviewer
description: |
  Revisor de codigo que analisa qualidade, padroes e problemas potenciais.
  Leia arquivos .ts, .js e .py no caminho indicado. Reporte: (1) problemas
  criticos, (2) sugestoes de melhoria, (3) pontos positivos. Nao altere
  nenhum arquivo. Nao execute comandos. Entregue um relatorio estruturado.
tools:
  - Read
  - Grep
  - Glob
# Sem Write, sem Edit, sem Bash, sem WebFetch
# Nenhum MCP server necessario para este agente
---

Prompts listos

Prompt 1 — crear un agente de solo lectura

"Crea un subagente llamado doc-auditor que sea completamente de solo lectura. Debe leer archivos Markdown en el directorio /docs, verificar si cada uno tiene frontmatter con 'title', 'date' y 'author', y generar un informe de compliance. Enumera las herramientas necesarias y explica por qué no necesita Write ni Bash."

Prompt 2 — auditar los permisos de un agente existente

"Lee el archivo .claude/agents/meu-agente.md y evalúa si todas las herramientas enumeradas en tools son necesarias para la tarea descrita en description. Para cada herramienta, indica: necesaria, innecesaria o depende. Sugiere una versión más concisa de la lista de tools."

Prompt 3 — comparar la granularidad de Read y Bash

"Quiero un agente que verifique si el archivo package.json tiene la dependencia X. Explica cómo hacerlo solo con Read (sin Bash) y cuándo sería necesario agregar Bash. ¿Cuál es el riesgo de cada enfoque?"

Qué es: Bash es la herramienta de máximo poder — cualquier comando del sistema — y exige el mayor nivel de deliberación antes de incluirla.
Por qué importa: muchas tareas que parecen necesitar Bash se resuelven con Read + Grep; compruébalo antes de agregarlo.
Conceptos clave: Bash como herramienta de último recurso · allowedTools · granularidad mediante prompt · alternativas de solo lectura.
🎯

Ejercicio

Crea el archivo .claude/agents/log-analyzer.md para un agente que analiza archivos de log (.log, .txt) en busca de errores críticos y genera un informe con: cantidad de errores por nivel (ERROR, WARN, FATAL), los 5 errores más frecuentes, y una línea de recomendación. El agente no puede modificar ningún archivo.

Pasos

  1. 1Define el campo tools — enumera ÚNICAMENTE las herramientas necesarias para leer y buscar en archivos de texto.
  2. 2Escribe el campo description con instrucciones claras sobre cómo informar los resultados (sin reproducir líneas completas del log).
  3. 3Verifica: ¿el agente necesita Bash? ¿Necesita Write? Si no, elimínalo.
  4. 4Prueba invocando: «usa el agente log-analyzer para inspeccionar los archivos en /tmp/logs»

Criterio de verificación: cómo saber si lo hiciste bien

El agente está correcto si cumple con todos los criterios a continuación:

  • ✓Mínimo necesario: tools contienen solo Read, Grep y Glob; sin Write, Edit, Bash ni herramientas de red.
  • ✓Description precisa: el campo description especifica los tres elementos del informe (recuento, top-5, recomendación).
  • ✓Sin falsa seguridad: no hay ninguna instrucción en el prompt que prohíba Write; simplemente, Write no está en tools.
  • ✓Datos sensibles: description orienta a no reproducir líneas completas de stack trace con datos de usuarios.
  • ✓Comprobable: al invocar al agente, este completa la tarea sin solicitar permisos adicionales y sin intentar editar archivos.

Próximo módulo:

2.5 — Proyecto x Global. Cuándo colocar el agente en .claude/agents/ del proyecto frente a la carpeta global del usuario.

✅ Resumen del módulo

✓
Mínimo privilegio — incluye solo las herramientas que el agente realmente usa para cumplir su función.
✓
Solo lectura por defecto — Read + Grep + Glob cubren la mayoría de los casos de análisis sin riesgo de daño.
✓
Lista de permitidos, no lista de bloqueados — el campo tools solo incluye lo permitido; todo lo demás se bloquea automáticamente.
✓
MCP con intención — se heredan de forma predeterminada, pero puedes —y debes— restringirlas para agentes especializados.
✓
La herramienta supera al prompt — nunca uses el prompt para prohibir lo que las tools permiten; elimina la herramienta.
✓
Datos sensibles — Read implica acceso a .env y a secretos; indícale al agente que no reproduzca valores en los informes.
✓
Bash es el último recurso — verifica si Read/Grep son suficientes antes de agregar Bash.