El mayor avance para los agentes de AI en producción no son mejores modelos, sino aceptar que los agentes son solo aplicaciones.
Suena obvio. Quizás hasta aburrido. Pero esta idea corta años de confusión, elimina categorías enteras de problemas de seguridad “nuevos” y hace que el despliegue de agentes multiusuario sea realmente viable.
Aquí te explicamos por qué importa.
La Trampa de la Identidad No Humana
Cuando los agentes empezaron a colarse en la conversación empresarial alrededor de 2023, las empresas de identidad se apresuraron a definir el problema. “Los agentes necesitan identidad no humana”, dijeron. “Son empleados de silicio. Necesitan sus propias cuentas, sus propios permisos, su propio todo.”
Tenía sentido intuitivo en ese momento. Si los agentes son autónomos, inteligentes y toman decisiones, ¿no deberían tener su propia identidad? ¿Su propio lugar en tu sistema IAM?
No.
Porque cuando intentas implementar la identidad no humana en la práctica, para agentes que actúan en nombre de usuarios, te topas de inmediato con una pared: ¿quién es la identidad cuando el agente accede a Gmail?
¿El agente? ¿Tú? ¿Alguna entidad híbrida en superposición cuántica de permisos? La respuesta se complica rápido, y esa complejidad crece cuando construyes sistemas que deben funcionar de forma confiable, segura y a escala.
El Hallazgo Que Lo Cambia Todo
Esto descubrimos después de construir decenas de agentes en producción:los agentes son solo aplicaciones con modelos de lenguaje en partes específicas del flujo de trabajo.
No son una nueva categoría. No son un cambio de paradigma revolucionario. Son automatización de flujos de trabajo muy sofisticada que usa razonamiento no determinista en ciertos puntos.
Piénsalo:
- Cursor es VS Code con un agente insertado en el flujo de edición
- ChatGPT es una app en el App Store (de las más descargadas)
- Spotify usa modelos para recomendaciones; no es un agente, pero tiene no-determinismo integrado
La línea entre “app” y “agente” ya se está borrando. Las apps tradicionales añaden interfaces conversacionales. Los productos centrados en agentes se convierten en aplicaciones completas. Al final, todo es automatización de flujos de trabajo, lo mismo que el software ha hecho desde los mainframes.
Por Qué Esto Importa para la Seguridad
Una vez que aceptas que los agentes son aplicaciones, tu infraestructura de seguridad existente funciona de inmediato. No necesitas nuevos constructos. No necesitas inventar identidad no humana. Ya sabes cómo hacer seguridad de aplicaciones.
Así funciona OAuth para agentes: la aplicación obtiene su propio client ID y secret, que identifican la app, no al usuario. Cuando un usuario autoriza a la app a acceder a un recurso (como Gmail o Slack), concede scopes que representan la intersección de dos cosas: lo que la app quiere hacer y lo que el usuario tiene permitido hacer. Si el agente aún no fue autorizado, lanzamos un flujo OAuth. Una vez autorizado, si el usuario puede realizar la acción, la ejecutamos. Si no, la bloqueamos.
La parte importante no es solo cómo funciona la autorización, sino cuándo ocurre. En lugar de pre-aprobar cada acción posible de antemano, como hacen la mayoría de las apps y agentes con OAuth, Arcade.dev autoriza después de que el modelo decide qué quiere hacer. Este enfoque “post-prompt” habilita la autorización justo a tiempo: el acceso se otorga solo para la acción específica que se realizará, exactamente cuando se necesita. Es más rápido, más seguro y se siente natural para el usuario. No tienes que conectar quince servicios antes de hacer algo útil; el agente simplemente pide lo que necesita, cuando lo necesita.
Esto se llama autorización delegada de usuario. Lleva más de una década funcionando para apps web. Y funciona igual de bien para los agentes.
El Problema Que Todos los Demás Resuelven Mal
La mayoría de los constructores de agentes usa hoy uno de dos enfoques que no funcionan:
1. Cuentas de Servicio (El Problema del RAG)
Le das al agente una cuenta de servicio con acceso amplio. Esto crea una vulnerabilidad de escalada de privilegios. ¿Qué pasa cuando un pasante usa el agente para acceder a datos sensibles que no debería ver?
La mayoría de las empresas resuelven esto restringiendo severamente al agente, limitándolo a información casi pública. Por eso la mayoría de los chatbots de soporte pueden repetir su base de conocimiento pública pero no pueden decirte dónde está tu pedido. No tienen forma de garantizar que yo no pueda hacer ingeniería de prompts para obtener la información de tu cuenta, es decir, no hay manera clara de afirmar a qué tengo acceso a través del agente.
2. Credenciales Directas del Usuario
Guardas las credenciales del usuario directamente en la configuración del agente. Así funcionan la mayoría de los servidores MCP de escritorio. Técnicamente funciona para escenarios de un solo usuario, pero no escala. Y aunque es seguro, es riesgoso: si el agente hereda todas tus credenciales, podría borrar archivos y correos porque tú también tienes esa capacidad. En Cursor, lo he visto intentar borrar mi directorio raíz. Por suerte no tenía acceso sudo y fue bloqueado. Se disculpó profusamente, lo cual fue muy amable.
Reintentar
Cómo Se Ve la Auth de Agentes de Nivel Producción
En Arcade.dev construimos el primer sistema que permite a los agentes pasar por flujos OAuth dentro del loop del agente, después del prompt del usuario.
Esto significa:
- El agente tiene su propio registro de aplicación OAuth
- El agente obtiene permisos acotados (leer correos, no borrarlos)
- El usuario mantiene sus permisos existentes
- La autorización ocurre en tiempo real, en cada llamada a herramienta
- Sin cuentas de servicio con acceso dios
- Sin credenciales hardcodeadas esperando filtrarse
Cuando un agente intenta acceder a Slack en tu nombre, verificamos: ¿puede este agente, en nombre de este usuario, realizar esta acción sobre este recurso?
Si el agente aún no fue autorizado, pausamos la solicitud y lanzamos un flujo OAuth, una pantalla de autorización estándar que tu equipo de seguridad ya conoce. Una vez autorizado, verificamos los permisos del usuario. Si puede realizar la acción, la ejecutamos. Si no, la bloqueamos.
El agente nunca almacena credenciales. El modelo tampoco: solo recibe salidas autorizadas, nunca los secretos en sí. El agente solo hace solicitudes, y nosotros aplicamos la política basada en la intersección de los scopes del agente y los permisos del usuario.
Por Qué Esto Reduce la Complejidad
Tratar a los agentes como apps significa:
Tu equipo de seguridad no necesita aprender conceptos nuevos. OAuth, OIDC, SAML: todo sigue funcionando. Sin nuevo paradigma de identidad que diseñar.
Tu agente no necesita acceso de superusuario. Los permisos acotados te permiten desplegar agentes en producción sin crear riesgos de escalada de privilegios.
Tu stack de IAM no necesita cambiar. Seas Okta, Active Directory o Saviynt, tus políticas de acceso existentes aplican. Nosotros solo ayudamos a aplicarlas en la capa de llamada a herramientas.
Tus desarrolladores pueden concentrarse en construir agentes, no en resolver auth. En lugar de pasar seis meses descubriendo cómo conectar un agente a Gmail de forma segura, conectan un toolkit y publican.
El Futuro Ya Llegó
Las empresas que construyen agentes en producción ya convergen en este modelo, muchas veces sin darse cuenta.
Empiezan insertando un modelo de lenguaje en un flujo de trabajo. Listo, ahora es un agente. Luego descubren que necesita conectarse de forma segura a sistemas internos. Implementan OAuth. Después construyen otro agente que necesita hablar con el primero. Añaden una interfaz MCP. Luego una herramienta necesita más lógica, así que añaden razonamiento dentro de la misma herramienta.
Sin darse cuenta, han construido un sistema multiagente sofisticado que en realidad es solo una aplicación bien arquitectada con LLMs en lugares específicos.
No se propusieron demostrar un punto filosófico. Solo resolvieron el problema que tenían enfrente. Y la solución resultó ser… una app.
Qué Significa Esto para Ti
Si estás construyendo agentes:
- Deja de intentar inventar nuevos constructos de identidad
- Usa OAuth como fue diseñado
- Trata a tu agente como una aplicación en tu stack de seguridad
- Acota los permisos y aplícalos en tiempo de ejecución
Si estás evaluando plataformas de agentes:
- Pregunta cómo manejan la auth multiusuario
- Evita cualquier cosa que requiera cuentas de servicio o credenciales hardcodeadas
- Busca un MCP runtime que ofrezca autorización delegada con aplicación de políticas en tiempo real
Si eres líder de seguridad:
- La buena noticia: tu modelo de seguridad existente funciona
- El reto: aplicarlo en la capa de llamada a herramientas requiere nueva infraestructura
- La ganancia: sin escalada de privilegios, sin nuevo paradigma de identidad, sin rediseñar el IAM
La Conclusión
Los agentes no son una nueva categoría de identidad. Son aplicaciones que usan razonamiento no determinista en partes de su flujo de trabajo.
Aceptar esto no hace que la seguridad de los agentes sea trivial: todavía hay trabajo real en torno a la gestión de tokens, la aplicación de scopes y la autorización en runtime. Pero sí lo hace resoluble usando patrones e infraestructura que tu equipo ya conoce.
No necesitas esperar a que la industria invente estándares de identidad no humana. No necesitas rediseñar tu stack de IAM. Solo necesitas aplicar la autorización a nivel de aplicación en la capa de llamada a herramientas.
Para eso construimos Arcade.dev. Y por eso las empresas están publicando agentes en producción en semanas, en lugar de esperar años a que el problema de “seguridad de agentes” se resuelva.
*¿Quieres ver cómo funciona esto en la práctica? Revisa nuestra* documentación o habla con nosotros *sobre cómo desplegar agentes con OAuth real en tu entorno.*
