Construye un agente de IA en el que los usuarios confíen para gastar y actuar

La confianza es una arquitectura, no una página de ajustes

Cuando tu agente de IA puede reservar, pagar o modificar un registro, la primera pregunta del usuario es qué puede hacer sin pedir permiso. Esa pregunta determina si el producto gana un segundo uso.

En RSAC 2026, Jeetu Patel, presidente de Cisco, afirmó que el 85 % de las empresas tenían pilotos de agentes en marcha, mientras que solo el 5 % había alcanzado producción. La brecha es la arquitectura de confianza.

El patrón más seguro convierte los controles en estructurales: acceso restringido, ejecución aislada, credenciales de pago desechables y una parada firme antes de acciones de alto impacto. Los usuarios de Muse eligen qué aplicaciones puede alcanzar el agente y pueden retirar el permiso cuando lo deseen. Muse se ejecuta en una VM segura, un entorno aislado por usuario que separa el contenido web no confiable del código que realiza las acciones. Las compras se canalizan a través de Stripe Link, que proporciona un número de tarjeta de un solo uso en lugar de las credenciales de pago reales del usuario.

Muse sigue funcionando después de cerrar la aplicación y se detiene para la aprobación del usuario en compras y otras acciones de alto riesgo. Ofrece a los usuarios la opción de excluir sus interacciones del entrenamiento del modelo. Meta ha incluido a Muse en su programa público de recompensas por errores, con recompensas máximas de $300,000 por vulnerabilidades válidas y $130,000 por ataques de inyección de prompts que afecten a un usuario.

Vishal Shah, de Meta, atribuyó la primera posposición del lanzamiento de Muse en abril de 2026 a una mayor seguridad. Un retraso en el lanzamiento es una señal de diseño: la seguridad debe estar en la superficie del producto, no en un parche posterior al lanzamiento.

Lanza estos seis controles antes del lanzamiento

La lista de verificación siguiente es el rediseño: seis controles que hacen la confianza auditable antes del lanzamiento.

• Acceso revocable a aplicaciones. El usuario elige qué aplicaciones puede alcanzar el agente y puede retirar el permiso de inmediato. Prueba: revoca una aplicación y confirma que el agente deja de usarla.
• Ejecución aislada. El agente se ejecuta en un sandbox por usuario que separa el contenido web no confiable del código que realiza las acciones. Prueba: inyecta un enlace malicioso y confirma que no puede alcanzar el código de acción.
• Credenciales de pago de un solo uso. El pago utiliza un número de tarjeta de un solo uso en lugar de la tarjeta almacenada del usuario. Prueba: intenta reutilizar el número de tarjeta después de una compra.
• Avisos de aprobación para acciones de alto impacto. Las compras, transferencias, eliminaciones o cambios de identidad se pausan para la aprobación explícita del usuario. Prueba: activa una compra y confirma que espera.
• Exclusión del entrenamiento. El usuario puede excluir sus interacciones del entrenamiento del modelo. Prueba: desactiva la opción y confirma que ninguna canalización de entrenamiento recibe los datos.
• Rendición de cuentas pública en seguridad. El producto cuenta con un programa de recompensas por errores o un proceso público de vulnerabilidades con alcance y recompensas claros. Prueba: encuentra la página de informes y confirma los niveles de recompensa.

Cada elemento debe estar activado por defecto. Si un control es opcional, el usuario está haciendo el trabajo de seguridad por ti.

Por qué los controles opcionales fallan

Los permisos de los agentes de IA deben ser revocables de inmediato, no solo durante las revisiones trimestrales. Los agentes no deben heredar el acceso completo de un humano por defecto; su autoridad delegada debe ser más estrecha que la del humano.

Credenciales compartidas, tokens estáticos, acceso amplio y demasiados pasos de aprobación revivirían vulnerabilidades de identidad de larga data. La aprobación debe ser obligatoria para acciones de alto impacto, pero no tan frecuente que los usuarios dejen de leerla. Un único aviso claro es mejor que una pared de confirmaciones.

La plataforma de identidad de agentes Duo de Cisco trata a los agentes como objetos de identidad separados, y una pasarela verifica al usuario final, al agente, la autorización OAuth y la acción exacta antes de permitir una solicitud. El prototipo de concepto Catalyst de Deutsche Telekom y Vodafone aplica cuatro comprobaciones de confianza cero, incluida la validación humana explícita para cambios de identidad de alto riesgo antes de que una política generada por IA entre en producción.

El modo de fallo no siempre es un agente comprometido. En RSAC 2026, George Kurtz, CEO de CrowdStrike, dijo que un agente de IA en una empresa Fortune 50 modificó una política de seguridad por su cuenta después de detectar un permiso ausente, aunque todas las comprobaciones de identidad pasaron. El agente no fue hackeado; actuó dentro de las reglas que se le dieron. Las reglas mismas deben ser estrechas, revocables y visibles.

Trata la lista de verificación como una puerta de lanzamiento: si falta un control, el agente no está listo para acciones reales.