Aunque crear una demo de AI se ha vuelto trivialmente fácil, los despliegues de nivel productivo en empresas han sido frenados por problemas de rendimiento, costos y vulnerabilidades de seguridad que sus equipos han señalado desde hace tiempo.

Hoy estamos atacando una de esas vulnerabilidades de frente.

Una nueva clase de ataque de identidad

Investigadores de seguridad de la Universidad China de Hong Kongidentificaron recientemente nuevas variantes de COAT (Cross-app OAuth Account Takeover), un ataque de phishing de identidad dirigido a plataformas de AI agéntica e integración. Presentaron sus hallazgos enBlack Hat 2025, demostrando cómo las arquitecturas OAuth basadas en conexiones usadas en estas plataformas pueden explotarse para obtener acceso no autorizado a sistemas empresariales.

El mecanismo del ataque es simple pero peligroso:

  1. Un actor malicioso (Mallory) inicia un flujo de autorización para, por ejemplo, una integración de GitHub
  2. En lugar de completar el flujo él mismo, Mallory envía el enlace de autorización a una víctima (Bob)
  3. Si Bob hace clic en el enlace y autoriza (o si GitHub autoriza automáticamente porque Bob ya conectó una integración similar), la autorización se completa
  4. Como la sesión original pertenecía a Mallory, ahora él controla la integración de GitHub con el acceso de Bob, lo que resulta en un robo de cuenta.

No es una vulnerabilidad pasiva. Requiere phishing activo. La víctima debe hacer clic en un enlace malicioso y, en la mayoría de los casos, dar su consentimiento activamente. Pero como sabe cualquier equipo de seguridad, el phishing y el spearphishing son vectores de ataque efectivos… y cuando eres unagentic runtime como Arcade.dev, el factor humano es un riesgo que vale la pena atender.

Por qué esto importa para la AI agéntica

A medida que las empresas construyen agentes que necesitan conectarse con sistemas de negocio, recurren a tecnologías como Arcade y otras para intermediar esa conexión segura. Esto da lugar a lo que los investigadores llaman “OAuth basado en conexiones” u “OAuth-as-a-Service”: sistemas centralizados de gestión de tokens que crean “conexiones OAuth” abstractas como manejadores de tokens administrados.

Si no se construyen con cuidado, las plataformas de conexión OAuth pueden caer víctimas de varios ataques documentados contra OAuth. En el escenario más grave, un atacante ni siquiera necesita una cuenta en tu organización. Puede crear una cuenta en una app que use infraestructura OAuth compartida, disparar un flujo de autenticación y hacer phishing a usuarios de organizaciones completamente distintas. Las relaciones de confianza ya existen, muchos usuarios ya dieron consentimiento a accesos amplios, y los usuarios distraídos suelen hacer clic en enlaces sin revisarlos demasiado.

La respuesta de Arcade: actualizar el flujo de autorización

Por la posición de Arcade dentro de cuentas empresariales y el perfil de seguridad del equipo, Luo et al. nos contactaron de manera privada en abril de 2025 con sus hallazgos. Nuestra respuesta fue categórica: había que corregirlo, y corregirlo bien. Nuestros clientes son algunas de las empresas más grandes que despliegan agentes en producción, así que no era negociable. Al evaluar distintas soluciones, también supimos que debíamos mantener dos principios guía del producto:

  • Mantener Arcade fácil de usar
  • Ser seguro por defecto siempre que sea posible

Esto implicó rediseñar el flujo de autorización de Arcade introduciendo verificación de usuario obligatoria. Las apps y agentes construidos en Arcade ahora tienen dos opciones, cada una adecuada para distintas etapas del ciclo de vida de tu proyecto:

  • Verificación de usuario de Arcade: durante la autorización, se pide a los usuarios que entren a su cuenta de Arcade (si no lo han hecho). Es ideal para comenzar, proyectos internos y pruebas de concepto: simple, seguro por defecto, sin desarrollo adicional.
  • Verificación de usuario personalizada: para despliegues en producción, Arcade puede delegar a una ruta en tu aplicación que realiza verificaciones de sesión, para que tus usuarios finales nunca necesiten interactuar con Arcade directamente. Tus usuarios permanecen completamente dentro del contexto de autenticación y UX de tu app.

Puedes encontrar todos los detalles de estos enfoques aquí:docs.arcade.dev/en/home/auth/secure-auth-production.

Ambos enfoques logran el mismo objetivo: vinculan de forma segura el flujo de autorización a una sesión de usuario verificada, sin que el usuario final lo note. Cuando Bob recibe ese enlace de phishing de Mallory, su navegador participa para verificar su identidad antes de que el flujo pueda completarse. El sistema detecta que la sesión pertenece a Bob pero que la autorización fue iniciada por Mallory, y rechaza correctamente el flujo para mantener a Bob seguro.

Escenarios protegidos

Este enfoque elimina tanto las variantes de ataque entre tenants como entre cuentas:

Ataques entre tenants: Un actor malicioso con una cuenta de Arcade engaña a una víctima que usa una aplicación completamente diferente basada en Arcade. Antes era posible en algunos casos donde las relaciones de confianza y las apps de OAuth eran compartidas. Ahora está prevenido en todos los casos, porque la verificación de usuario garantiza que quien completa el flujo coincida con quien lo inició, y las URIs de OAuth deben ser únicas

Antes

Después

Ataques entre cuentas: Un actor malicioso con una cuenta en tu aplicación engaña a otro usuario de la misma. Antes era posible porque la identidad del usuario no se verificaba durante la autorización. Ahora está prevenido mediante el mismo mecanismo de verificación de usuario.

Antes

Después

Otros enfoques que evaluamos

Al revisar esta vulnerabilidad con el equipo de investigación, exploramos varias estrategias de mitigación antes de llegar al enfoque de verificación de usuario. Cada una tenía atractivo, pero ninguna atacaba la causa raíz: la falta de vínculo real entre el usuario que inicia la autorización y el que la completa. Estos son los enfoques que evaluamos y que no pasaron el corte:

  • PKCE (Proof Key for Code Exchange) fue nuestro primer instinto. Es una parte importante de la historia de seguridad de OAuth para clientes no confiables (públicos), y los especialistas en OAuth naturalmente recurren a él. Pero PKCE no ayuda aquí, ya que el atacante controla la solicitud inicial y PKCE solo garantiza la integridad de lasolicitud en sí. Cuando la víctima completa el flujo, simplemente está cumpliendo el desafío del atacante.
  • Firma criptográfica de la solicitud inicial era tentadora, pero enfrenta el mismo problema. El atacante es quien inicia el flujo. Él genera y firma la solicitud. Todo esto haría sería validar elinput del atacante, no prevenir el ataque.
  • Validar la identidad del usuario devuelta por IDPs/AS de terceros. Algunos proveedores de identidad y servidores de autorización OAuth devuelven información sobre el usuario que autoriza, pero no todos. Y los que lo hacen, la devuelven en formatos muy distintos: GitHub te identifica por un @usuario y Gmail por una dirección de correo.
  • Timeouts agresivos también parecían tentadores: hacer la ventana de autorización tan corta que sea más difícil de explotar. Pero eso no la hace imposible. Por ejemplo, un spearphishing por Discord, SMS, IRC Slack u otros sistemas de chat podría saltársela con un ataque bien sincronizado. Un atacante hábil y motivado puede hacer que la víctima haga clic en un enlace muy rápido si ya está frente al teclado. Además, una ventana tan corta como para prevenir el ataque también haría tu aplicación/agente inutilizable: es un tradeoff imposible.
  • Seguridad por oscuridad, como ocultar flujos dentro de iFrames o popups del navegador. Esto también podría hacer la explotación más difícil, pero no detendría a un atacante experimentado que puede eludir la ofuscación del lado del cliente con facilidad.
  • Requerir apps OAuth y URIs de redirección dedicadas para cada proyecto resuelve parte del problema y ya es compatible con muchas plataformas, incluida Arcade. Ayuda a mitigar el escenario entre tenants, pero no elimina el vector de ataque entre cuentas, donde tanto el atacante como la víctima usan la misma aplicación.

El problema fundamental de todas estas pseudo-mitigaciones es que la identidad del usuario nunca se confirma realmente. Lo que significa que la única solución real es la que implementamos: vincular el flujo de autorización a una sesión de usuario verificada. Todo lo demás es teatro de seguridad.

El llamado de Arcade a la industria

COAT representa exactamente el tipo de desafío de seguridad que los equipos han temido mientras las empresas se apresuran a desplegar agentes. Mientras el ciclo de hype se centra en lo que los agentes pueden hacer, los equipos de seguridad en producción preguntan: “¿Podemos realmente desplegar esto de forma segura?” La respuestadebeser sí, pero solo si la industria toma estas vulnerabilidades en serio.

El Arcade Runtime es de confianza para algunas de las empresas más grandes que despliegan agentes reales en producción. Eso significa que la seguridad no es un afterthought: es parte fundamental de nuestra arquitectura. Por eso optamos por atender este cambio de forma proactiva y lanzamos las correcciones hace meses. No esperamos a que haya un exploit en la naturaleza. No lo tratamos como una preocupación teórica. Lo corregimos antes de que se convirtiera en un problema para cualquiera de nuestros clientes.

No todas las plataformas de integración han mitigado COAT, pero esperamos que lo hagan. A medida que las empresas construyen y despliegan agentes de AI en producción a escala, no pueden permitirse trabajar con tecnologías que tratan la seguridad como un afterthought. Necesitan confiar en que sus socios tecnológicos tomarán las decisiones arquitectónicas difíciles cuando sea necesario, aunque impliquen una inversión significativa de ingeniería.

Arcade es uno de los pioneros que lideran los despliegues agénticos con seguridad como prioridad, trabajando con los investigadores de seguridad más reconocidos del mundo. Estamos comprometidos a mantenernos a la vanguardia porque creemos que el futuro de la AI agéntica depende de ello. Las empresas que realmente despliegan agentes a escala, las quevan más allá de las demos hacia sistemas en producción que manejan datos sensibles y flujos de trabajo críticos, necesitan socios que prioricen su postura de seguridad tanto como la experiencia de sus desarrolladores. Ese es el estándar que nos exigimos, y no lo vamos a bajar. Porque la promesa de la AI agéntica no es solo lo que los agentes pueden hacer, sino si las empresas pueden confiar en que lo harán de forma segura.