# Claude Duet: cómo leer su informe de seguridad **URL:** \ **Category:** Community\ **Created:** [26 Octubre, 2026 09:23 UTC](https://www.yodev.dev/t/claude-duet-como-leer-su-informe-de-seguridad/5795 "2026-10-26T09:23:01Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![xiaoying\_zhou](https://yyz1.discourse-cdn.com/flex009/user_avatar/www.yodev.dev/xiaoying_zhou/32/2522_2.png) [@xiaoying\_zhou](https://www.yodev.dev/u/xiaoying_zhou)\ **Post date:** [26 Octubre, 2026 09:23 UTC](https://www.yodev.dev/t/claude-duet-como-leer-su-informe-de-seguridad/5795/1 "2026-10-26T09:23:01Z")
![image](https://canada1.discourse-cdn.com/flex009/uploads/inovacon/original/2X/0/0b6734081f85c62573df191218ac5a1a7942b12f.jpeg) ## **El problema** Cada anuncio de un agente autónomo llega con la misma frase: se probó con equipos rojos, hubo auditoría externa, hay un programa de recompensas por errores. Esa frase es cierta casi siempre y, aun así, informa muy poco. La pregunta útil no es si se probó, sino **qué tipo de fallo cubre cada prueba y cuál queda fuera**. Claude Duet, el agente proactivo de Anthropic, empezó como vista previa de investigación el 21 de octubre de 2026, limitado a suscriptores Pro y Max en Estados Unidos con lista de espera. Su documento de seguridad describe el programa de pruebas con un detalle poco habitual, lo que lo convierte en un buen caso para practicar esta lectura. ## **La evidencia: qué se probó y con qué método** El documento enumera tres variantes de comportamiento durante el desarrollo: una versión normal, una con instrucciones hostiles inyectadas en el contenido que lee, y una diseñada para forzar un exceso de alcance. A eso suma tráfico en sombra, equipos rojos internos, una prueba de penetración externa con acceso al código fuente y un programa de recompensas. | **Prueba** | **Qué cubre** | **Qué no cubre** | | --- | --- | --- | | Tres variantes de comportamiento | Fallos del modelo ante contenido hostil | Decisiones humanas bajo cansancio | | Tráfico en sombra | Comportamiento con carga real antes del lanzamiento | Casos límite que no aparecen en el tráfico | | Equipos rojos internos | Clases de ataque conocidas por el equipo | Ataques que el equipo no imaginó | | Prueba de penetración externa | Infraestructura y manejo de credenciales | Uso cotidiano del producto | | Programa de recompensas | Fallos encontrados por terceros con incentivo | Todo lo que nadie reportó | ## **El resultado: tres conclusiones que sí se sostienen** Primera: el diseño separa credenciales del entorno de ejecución. El documento indica que contraseñas, tarjetas y números de cuenta no llegan al modelo, y que los pagos usan tarjetas virtuales de un solo uso atadas a comercio y monto. Eso es verificable en el diseño y reduce el daño máximo de un error de forma estructural, no por disciplina del usuario. Segunda: las acciones irreversibles se detienen. Enviar mensajes sensibles, pagar, firmar, borrar y crear cuentas requieren confirmación, y la tarjeta de confirmación muestra la acción, el objetivo, el contenido y todos los destinatarios. Además, no existe la opción de «no volver a preguntar» para pagos, transferencias, borrado de pedidos o creación de cuentas. Tercera: hay acciones bloqueadas incluso con confirmación: operar valores, transferir entre cuentas y acceder a cuentas ajenas. La lista es corta y explícita, que es exactamente lo que se quiere de una lista así. ![Captura de la sección oficial sobre el programa de pruebas, 26 de octubre de 2026.](https://canada1.discourse-cdn.com/flex009/uploads/inovacon/original/2X/b/b72f2750d6ad29ce112e7e67740336e0e9aa667a.png) ![Captura de la lista oficial de límites del centro de ayuda, 26 de octubre de 2026.](https://canada1.discourse-cdn.com/flex009/uploads/inovacon/original/2X/d/d79c27bf994421299f558fef8e80649cfd8cc374.png) ## **Los límites de esa evidencia** Un informe de seguridad de un producto en vista previa tiene tres límites que conviene escribir al lado de cada conclusión. El primero es de alcance: se prueba el sistema contra ataques y contra errores del modelo, no contra el dueño del negocio que aprueba cinco tarjetas seguidas antes del café. La fatiga de aprobación se menciona en la documentación como motivo para calibrar la frecuencia, pero no hay medición pública de cuántas personas leen realmente cada tarjeta. El segundo es de acceso: sin cuenta no se puede reproducir nada. El producto no está disponible fuera de Estados Unidos y se entrega por invitación, así que la latencia, la calidad del resumen matinal y la frecuencia real de aprobaciones quedan fuera del alcance de cualquier lector externo. El tercero es temporal: el documento describe el estado en un momento dado. Un programa de pruebas que hoy es sólido puede quedarse atrás cuando se añadan conectores nuevos, y el propio documento advierte que las pruebas de navegador e inicio de sesión siguen en curso. ## **Qué hacer con esto** Si hay que decidir con base en un informe así, tres preguntas ordenan la lectura más rápido que cualquier lista de funciones: ¿qué fallo concreto cubre cada prueba?, ¿qué parte del sistema queda fuera del alcance declarado?, y ¿qué cambió desde que se escribió el documento? Para quien construye algo parecido, la lección transferible no es copiar la lista de pruebas, sino copiar su granularidad: separar comportamiento, infraestructura y decisiones humanas, porque cada uno se rompe por motivos distintos y se arregla con instrumentos distintos. ## **Discusión** Queda abierta una pregunta que ningún documento responde: ¿cómo se mide si las confirmaciones se leen? Tiempo hasta aprobar, tasa de rechazo y desplazamiento dentro de la tarjeta son tres métricas baratas que cualquier equipo puede instrumentar desde el primer día. Si su equipo ya opera un agente con permisos de escritura, ¿qué métrica usan para saber que las aprobaciones siguen siendo reales y no un trámite? Cuando un producto agrupa varios proveedores de modelos, las claves y la facturación suelen concentrarse en una pasarela en lugar de repartirse por el código; [Crazyrouter](https://crazyrouter.com/en/?utm_source=yodev&utm_medium=article&utm_campaign=claude-duet-2026&utm_content=boluo_yodev_claude-duet-2026) documenta sus endpoints y precios como una de esas opciones, y la decisión depende del volumen de llamadas y de las normas internas. Fuentes: anuncio de Claude Duet, documento de seguridad y privacidad, página del producto y centro de ayuda de Anthropic, consultados el 26 de octubre de 2026.