Haz que los agentes de navegador sean fiables: una lista de verificación para validar acciones de alto impacto antes de ejecutarlas

Cuando un agente está a punto de enviar un formulario en un navegador con sesión iniciada, la pantalla del usuario es el único lugar donde el error se vuelve visible. Anthropic clasificó la inyección de prompts como la mayor amenaza de la IA, con instrucciones hostiles ocultas en páginas web, correos electrónicos o documentos capaces de desviar a Claude sin que el usuario se dé cuenta.

Eso convierte las acciones de alto impacto en el navegador en eventos de permiso, no en clics rutinarios. Si el producto trata cada acción como ordinaria, el usuario paga el precio del error. La respuesta de diseño es una puerta que comprueba la acción propuesta contra la solicitud original del usuario antes de ejecutarla.

El lanzamiento muestra por qué la puerta es importante

El 12 de agosto de 2026, Anthropic convirtió la extensión de Claude para Chrome en una sesión completa de Claude Cowork. El panel lateral de Claude en Chrome comparte historial, habilidades y conectores entre las aplicaciones de escritorio, web y móvil de Claude. Los suscriptores Max y Team pudieron usar Cowork en Chrome en el lanzamiento, mientras que los usuarios Pro estaban programados para recibirlo en las semanas siguientes.

Anthropic describió una verificación que compara las acciones de alto impacto, incluidos los envíos de formularios y las descargas de archivos, con la solicitud original antes de permitirlos. Para clientes empresariales, Cowork en Chrome comienza desactivado, y los administradores pueden activarlo limitando a Claude a dominios aprobados mediante los controles de administración de Chrome. Un lanzamiento que incorpora un agente en el navegador sin una puerta visible es un fallo de diseño, porque el usuario no puede auditar cada clic.

La puerta de verificación es el rediseño

Usa esta lista de verificación antes de cualquier acción del agente que cambie el estado. Cada punto debería poder responderse en un minuto. Si la respuesta no es clara en la interfaz, la acción no debe ejecutarse.

• Nombra la clase de acción. ¿Envía un formulario, envía un mensaje o descarga un archivo? Si es así, márcala como de alto impacto.
• Reformula la solicitud original del usuario. Si el agente no puede expresarla en una frase, detente y pregunta.
• Compara la acción propuesta con esa frase. Cualquier discrepancia en el destinatario, dominio, archivo o campo es un bloqueo.
• Exige confirmación explícita para acciones irreversibles. Para acciones de menor riesgo, ofrece un alcance reversible y muestra lo que se deshacerá.
• Establece el valor predeterminado empresarial en desactivado. Mantén el agente de navegador desactivado hasta que un administrador lo active y configure una lista de dominios aprobados.

Convierte la puerta en una solicitud de permiso

Debe nombrar la acción, el objetivo y la razón por la que se propone. La puerta debe mostrar el nombre del formulario, el dominio de destino y los campos para un formulario; el destinatario y el asunto para un mensaje; y el tipo de archivo y la fuente para una descarga.

El texto de confirmación importa. No pidas al usuario que apruebe un prompt vago. Pide la acción específica: enviar el mensaje al destinatario mostrado. El usuario debe poder ver la solicitud original junto a la acción propuesta. Si ambas no coinciden, la interfaz debe indicarlo en lenguaje claro.

Después de que la acción se ejecuta, el producto debe mantener un registro de auditoría breve: qué se propuso, qué aprobó el usuario, qué cambió y cómo deshacerlo. Debe ser lo suficientemente breve para leerse, pero lo suficientemente completo para responder qué ocurrió y quién lo aprobó. Esa es la diferencia entre un usuario que puede recuperarse de un error y uno que tiene que abrir un ticket de soporte.

La política empresarial debe ser visible

El ámbito empresarial es donde la confianza se convierte en un problema de administración. Un agente de navegador que puede actuar en una sesión iniciada también puede actuar sobre todo lo que esa sesión puede alcanzar. La política debe ser visible para el usuario como una restricción, no como una regla oculta. Cuando un límite bloquea una acción, el usuario debe ver qué configuración de administrador se aplica y por qué.

Las restricciones de dominios aprobados son el mínimo. Limitan lo que el agente puede alcanzar, pero no demuestran que una acción permitida coincida con la intención del usuario antes de ejecutarse. El producto sigue necesitando una verificación por acción, una razón de bloqueo claramente visible y una vía para deshacer o escalar.

Los controles de administración deben ser aburridos. Una lista de dominios aprobados es útil, pero debe ir acompañada de límites en las acciones de alto impacto: sin envíos de formularios, sin envíos de mensajes, sin descargas, a menos que un administrador los active. El usuario debe ver qué límites se aplican antes de que el agente se ejecute, no después del hecho.