Anthropic abre su libreta de seguridad para agentes: como estan conteniendo Claude en 2026
El 25 de mayo de 2026 Anthropic publico como contiene Claude en claude.ai, Claude Code y Cowork. La pieza vale por dos razones: muestra fallos reales antes del trust prompt y aterriza por que los agentes utiles necesitan menos aprobaciones manuales, pero más limites duros en sandbox, red y credenciales.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Hay una frase del nuevo post de Anthropic que vale más que muchas demos: el problema ya no es solo que el agente se equivoque; el problema es cuanto dano puede hacer cuando ya hace trabajo útil. Ese es el fondo del articulo "How we contain Claude across products", publicado el 25 de mayo de 2026.
Para quien construye agentes, la importancia del texto no es de branding. Es operativa. Anthropic esta diciendo en voz alta algo que muchos equipos prefieren posponer: si el agente ya puede tocar archivos, correr comandos, leer contexto y usar red, entonces la seguridad real no puede descansar en que una persona apruebe botones para siempre.
La tesis central: bajar blast radius, no solo subir alineacion
Anthropic divide el riesgo en tres grupos:
- mal uso del usuario,
- mal comportamiento del modelo,
- ataques externos como prompt injection o abuso del runtime.
La parte más útil del post es que no se queda en "ten cuidado". Lo aterriza en una idea que cualquier builder deberia copiar: si no puedes garantizar comportamiento perfecto, garantiza limites de dano.
En vez de confiar siempre en supervision humana, Anthropic insiste en contenedores, VMs, fronteras de filesystem, egress controls y credenciales fuera del sandbox. Esa es la diferencia entre una política bonita y una arquitectura que aguanta errores.
Por que las aprobaciones manuales ya no bastan
El post conecta directamente con otro articulo de Anthropic, "Claude Code auto mode: a safer way to skip permissions", publicado el 25 de marzo de 2026. Ahi la empresa admite un dato incomodo: los usuarios aprobaban cerca de 93% de los prompts de permiso.
Eso es exactamente lo que muchos equipos no quieren escuchar. Si casi todo se aprueba, el sistema deja de ser una barrera sería y se convierte en friccion cosmética.
Anthropic intenta reducir esa fatiga con auto mode, pero también deja claro que el clasificador no sustituye al sandbox. Su propio resumen es más sobrio que la mayoria de marketing de agentes: un clasificador ayuda, pero sigue siendo defensa en profundidad, no permiso para bajar la guardia.
El detalle que más deberia preocuparte
La revelacion más importante del articulo no esta en los diagramas. Esta en los fallos que reconoce.
Anthropic cuenta que recibio reportes de vulnerabilidades donde codigo del proyecto se ejecutaba antes de que el usuario aceptara el trust prompt, por ejemplo leyendo configuraciones locales de un repositorio no confiable demasiado pronto. La leccion es brutalmente simple: abrir un repo ajeno ya debe tratarse como entrada hostil.
Ese punto tiene implicaciones inmediatas para cualquiera que construya tooling con hooks, MCP o configuracion por proyecto:
- no parses configuracion local antes de establecer confianza;
- no metas tokens reales dentro del entorno donde el agente ejecuta codigo;
- separa runtime, credenciales y aprobaciones como si fueran componentes distintos.
Si estas empezando a disciplinar ese stack, esta noticia conversa bien con nuestro curso base de Instala tu propio agente, porque la mayoria de errores graves aparece cuando un flujo útil recibe acceso antes de tener fronteras claras.
Lo que un builder pequeno si puede copiar hoy
No necesitas el presupuesto de Anthropic para adoptar las ideas correctas. Un checklist útil sería:
- sandbox por defecto para comandos y herramientas con efectos laterales,
- credenciales fuera del contenedor siempre que sea posible,
- allowlists de red para reducir exfiltracion accidental,
- logs de cada acción si el agente puede tocar algo importante,
- y trust boundary explicita antes de leer configuraciones del proyecto.
El error común es creer que "seguridad de agentes" significa solo bloquear prompts maliciosos. No. Tambien significa limitar escritura, red, secretos y superficie de ejecucion aunque el modelo haga algo torpe o demasiado creativo.
Donde esta el tradeoff
La contencion también cuesta. Menos red significa menos herramientas. Menos filesystem significa más configuracion. Mas aislamiento suele significar peor experiencia inicial.
Pero el articulo ayuda a poner el costo en perspectiva. Si tu única defensa es pedir aprobaciones humanas una y otra vez, lo más probable es que termines con dos males al mismo tiempo:
- una UX cansada,
- y una seguridad mediocre.
Esa es justamente la razon por la que el texto vale la pena: no vende seguridad perfecta. Vende una postura más realista para sistemas que ya estan haciendo trabajo de verdad.
La conclusión útil
El post de Anthropic deja una idea que deberia influir en muchas decisiones de producto este año: los agentes utiles van a necesitar más autonomia, y esa autonomia solo será aceptable cuando el entorno les marque limites duros.
Para trafico cualificado, eso abre queries muy claras: seguridad de Claude Code, sandbox para agentes, prompt injection en agentes con tools, credenciales fuera del runtime y como contener agentes autonomos.
Mi lectura final es directa: en 2026, pedir menos permisos no es la historia; la historia es como haces que menos permisos siga siendo seguro.