Rompiendo la tríada letal: cómo Asana aborda la seguridad de la IA agéntica
La IA agéntica introduce una clase de riesgo de seguridad que la industria no ha resuelto. A continuación, te mostramos lo que pensamos en Asana y las invariantes de seguridad que mantenemos en todas nuestras funciones de IA.
El problema
Los sistemas de IA agentiva no solo responden preguntas. Leen documentos, toman medidas y coordinan entre herramientas. Cuanto más puedan hacer, mayor será su superficie de ataque.
A diferencia del código convencional, los LLM tienen una propiedad que hace que esto sea fundamentalmente difícil: no pueden distinguir de manera confiable las instrucciones de los datos. Todo lo que se proporciona a un LLM llega al mismo flujo, por lo que un dato cuidadosamente diseñado puede secuestrar el modelo de la misma manera que lo haría una instrucción legítima. Esta es la raíz de la inyección de prompt, lo que Simon Willison llama “el pecado original” de las aplicaciones basadas en LLM.
No es algo teórico. Los investigadores han demostrado esta clase de ataque contra Microsoft 365 Copilot, el servidor MCP de GitHub, Slack AI y muchos otros. Bruce Schneier lo expresó sin rodeos: la industria aún no tiene defensas sólidas contra esta clase de ataque.
Entonces, ¿cómo se crea una IA agentiva de manera responsable cuando la industria no ha resuelto los fundamentos?
La trifecta letal
Willison resume el riesgo principal en tres capacidades que, en combinación, crean las condiciones para el daño:
Acceso a datos confidenciales. El agente puede leer información confidencial o privada.
Exposición a contenido no confiable. El agente procesa información que puede contener instrucciones adversas ocultas.
La capacidad de comunicarse externamente. El agente puede enviar información fuera del sistema.
Una aclaración útil sobre el tercer pilar: en realidad se trata de la capacidad de crear efectos secundarios, no solo de la comunicación saliente. La exfiltración de datos al servidor de un atacante es el ejemplo clásico, pero una instrucción maliciosa que cambia silenciosamente el título de todos los proyectos en un espacio de trabajo o envía contenido confidencial al canal interno incorrecto es el mismo tipo de problema. Usamos “comunicación externa” como abreviatura, pero la versión más amplia es de lo que realmente nos defendemos.
Cualquiera de las tres etapas es manejable. Incluso dos juntas suelen serlo. Pero cuando las tres convergen, tienes una ruta de ataque viable.
El análisis de datos importante: romper cualquiera de las partes reduce sustancialmente el riesgo general. No necesitamos resolver la inyección de solicitud a la perfección. Nadie lo ha hecho. Necesitamos asegurarnos de que las tres condiciones no puedan coexistir fácilmente.
Korny Sietsma se basa en esto y asigna a la trifecta mitigaciones como el sandboxing, la descomposición de tareas, el mínimo privilegio y el “human-in-the-loop”. Estos son los componentes básicos. La pregunta es cómo ponerlos en práctica.
Contexto, puntos de verificación y controles
Organizamos nuestro pensamiento en torno a tres pilares que se relacionan directamente con la trifecta letal. Cada uno restringe una pata.
Asana tiene varias superficies de IA. Los compañeros de IA son participantes agentes con su propia membresía y permisos en el espacio de trabajo. Otras funciones de IA operan como el usuario, y el límite es lo que ese usuario ya puede acceder. Las invariantes a continuación se centran en el caso de los agentes, donde la superficie es más grande, y señalaremos dónde difiere la implementación según la superficie.
Contexto: Gestionar lo que la IA puede ver
Pata de la trifecta: Acceso a la información confidencial
Para que la IA agentiva sea útil, necesita contexto. El desafío es darle lo suficiente para que sea útil sin entregarle una llave maestra.
Nuestra invariante fundamental es el principio del menor privilegio, cuya expresión exacta depende de la superficie. Para los compañeros de IA, que tienen su propia membresía separada de cualquier usuario individual, el límite es la intersección de los permisos del compañero de equipo y los del usuario. Para las funciones de IA que operan como el usuario, el límite es simplemente el propio acceso de ese usuario. En todos los casos, la misma capa de autorización del lado del servidor que rige todas las demás interacciones en Asana rige el acceso de la IA. Las funciones de IA no obtienen permisos elevados. Operan dentro del sistema de control de acceso de Asana, no fuera de él.
Definir el contexto implica más que regular el acceso a los datos internos dentro de Asana; también abarca las integraciones externas con las que un agente puede interactuar. Si bien las integraciones actualmente requieren la autorización explícita del usuario, estamos desarrollando rutas de control granulares y específicas para cada agente. Esto permite a las organizaciones restringir los privilegios de integración para los compañeros de IA que manejan entradas de alto riesgo. Nuestra invariante arquitectónica central es clara: el límite de lo que una IA puede ver debe ser dinámico y estar controlado por los propietarios de los datos, en lugar de ser un valor predeterminado del producto codificado de forma rígida.
Incluso si un atacante introduce instrucciones maliciosas en el contexto de la IA, lo que la IA realmente puede ver está limitado por el mismo modelo de permisos que todo lo demás.
Puntos de verificación: Filtrar lo que escucha la IA
Etapa de la trifecta: exposición a contenido no confiable
Esta es la etapa más difícil. En una plataforma de gestión del trabajo, la mayor parte de lo que lee la IA es contenido generado por el usuario: tareas, comentarios, documentos adjuntos. Parte de este contenido proviene de fuera de la organización. No puedes negarte a leerlo.
En cambio, establecemos puntos de verificación: lugares donde distinguimos la intención confiable del contenido arbitrario y donde los humanos pueden intervenir si algo parece estar mal.
Gestión de instrucciones con reconocimiento de la fuente. Las funciones de IA etiquetan el contenido según la confianza del autor y la fuente, por lo que el modelo puede priorizar las instrucciones de los usuarios autorizados por encima de las instrucciones encontradas en el contenido arbitrario en el camino. Esto reduce la superficie de ataque para la inyección de prompts, pero no la cierra; el modelo sigue leyendo todo en su contexto y la garantía de seguridad es parcial en lugar de absoluta. A continuación, analizamos los límites de este enfoque.
Registro e investigación forense. Cada llamada al modelo se registra con sus entradas, salidas, actor, contexto de la función y eventos posteriores, incluidos los objetos del grafo de trabajo que una automatización tocó y las URL que aparecieron en la salida. Alertamos automáticamente sobre señales operativas como tasas de error y picos de costos. Para las anomalías relevantes para la seguridad, esos mismos registros respaldan la investigación posterior por parte de los humanos. Como señala Willison, incluso la detección basada en patrones que detecta la mayoría de los ataques sería insuficiente por sí sola; la visibilidad y la capacidad de investigar son la base duradera sobre la que construimos, no el muro.
Diseño “human-in-the-loop”. Las funciones de IA muestran su trabajo para que las personas lo revisen en lugar de realizar acciones irreversibles en silencio.
Descomposición de tareas y acciones de alcance. Los flujos de trabajo complejos se dividen en etapas más pequeñas, y las acciones disponibles para las funciones de IA están intencionalmente limitadas en lugar de ser abiertas.
Ninguna de estas medidas es infalible por sí sola. Juntos forman una defensa en profundidad.
Controles: restringir sobre qué puede actuar la IA
Pata de la trifecta: La capacidad de crear efectos secundarios
La tercera pata es donde se producen la mayoría de los ataques en el mundo real. Si un atacante convence a una IA para que inserte datos confidenciales en una URL, los envíe a través de una integración o cambie un registro del que dependen otras personas, el ataque tiene éxito.
Aquí invertimos en varias categorías de control:
Tratar el resultado del LLM como no confiable. El contenido generado no recibe un aumento de confianza porque proviene de la IA de Asana. Fluye a través de las mismas rutas de validación y renderización que cualquier otro contenido generado por el usuario.
Aprobación humana obligatoria para acciones de alto impacto. Ciertas categorías de acciones siempre requieren la aprobación humana explícita, independientemente de la confianza de la IA o de lo rutinaria que parezca la solicitud. Para los compañeros de IA, esto incluye acciones que modifican el nivel de acceso (cambiar permisos, agregar miembros) y acciones que destruyen datos (eliminaciones). La IA puede proponerlas, pero no puede ejecutarlas por sí sola.
Límites para el manejo de enlaces. Las URL externas en el contenido generado por IA se procesan antes de que lleguen a un usuario. Las URL nuevas que no aparecieron en la entrada reciben un escrutinio adicional y se muestran en su forma completa y sin ocultar en lugar de como texto de enlace reetiquetado, por lo que la IA no se puede utilizar como arma para disfrazar un punto final de exfiltración como un amigable “haz clic aquí para ver el resumen”.
Sin HTTP saliente de uso general. Las funciones de IA no tienen una primitiva abierta de “enviar una solicitud a cualquier URL”. Las integraciones externas pasan por canales delimitados con su propia autorización.
Pista de auditoría de acciones. Cada escritura, mutación y acción saliente que realiza una función de IA se registra junto con la llamada al modelo que la provocó, de modo que un investigador pueda reconstruir lo que hizo una IA, no solo lo que se le pidió.
El objetivo no es hacer imposible la comunicación externa. Las funciones de IA deben hacer referencia a enlaces, actualizar tareas y generar resultados útiles. El objetivo es asegurarse de que no puedan hacerlo de forma encubierta y de una manera que el usuario no pretendía.
Un patrón para los valores emitidos por la IA
Dentro de este marco, sigue surgiendo el mismo subproblema concreto: una función de IA produce algo (un ID de objeto, un destinatario, una URL) y el código posterior actúa sobre ello, con frecuencia con permisos más amplios que la propia IA. Las alucinaciones y las inyecciones de prompts llegan al mismo lugar: se confía en un valor que emite el modelo.
Utilizamos un patrón de cuatro partes como lista de verificación de revisión de diseño para estos valores:
Restringe lo que la IA tiene permiso para producir en primer lugar, antes de que se deba ejecutar la validación.
Valida cada valor producido por la IA del lado del servidor con la misma capa de autorización que todo lo demás. El modelo se trata como un cliente que no es de confianza.
Justifica la elección manteniendo suficiente contexto estructurado para explicar por qué la IA eligió lo que eligió. Eso es lo que hace posible la investigación, las evaluaciones y la respuesta a incidentes más adelante.
Escalar con fricción, alternativa o revisión humana cuando un valor sea de alto riesgo o esté fuera del alcance esperado.
El hilo conductor: el comportamiento del modelo no debe ser el control de seguridad principal. Las mejores indicaciones y el “le dijimos al modelo que no hiciera eso” son una defensa útil en profundidad, pero los controles duraderos se encuentran en el sistema alrededor del modelo.
Basado en principios
Estas opciones no son ad hoc. Se derivan de los principios de IA publicados por Asana.
Las personas son responsables de las decisiones, lo que impulsa el diseño orientado a los puntos de control. La IA ayuda, pero los humanos se mantienen al tanto y son responsables.
Estamos comprometidos con la seguridad, lo que justifica la inversión en controles en capas, incluso cuando agregan fricción. La alternativa aumenta el riesgo a medida que las funciones de IA asumen un trabajo más complejo.
Promovemos la transparencia, por eso estamos escribiendo esta publicación. No hemos resuelto la seguridad de la IA agéntica. Pero ser abiertos sobre cómo razonamos sobre estos riesgos y las mitigaciones que implementamos ayuda a la comunidad en general a avanzar en un desafío compartido e invita al escrutinio que nos hace mejorar.
Los límites honestos
La inyección de indicaciones sigue sin resolverse fundamentalmente, y la inyección indirecta de indicaciones (las instrucciones adversas llegan incrustadas en el contenido que la IA obtiene durante su trabajo, en lugar de ser contenido que un usuario le entrega directamente) es la variante que más ha afectado a la industria en 2026. El etiquetado con reconocimiento de la fuente ayuda, pero no cierra completamente esta brecha, porque el modelo aún tiene que elegir respetar las etiquetas. Nuestros puntos de verificación reducen significativamente el riesgo; no lo eliminan. Mientras las instrucciones y los datos compartan una ventana de contexto, a veces se colarán las entradas maliciosas obtenidas a través de la búsqueda, los formularios públicos o las integraciones. Tratamos esto como un área de inversión activa y continua, con un escrutinio más minucioso de cualquier vía que permita que el contenido de autoría externa llegue a una función de agente IA. El trabajo en los patrones de diseño para proteger a los agentes de LLM apunta en direcciones prometedoras, pero el consenso de la industria aún está surgiendo.
El panorama de las amenazas cambia rápidamente. Siguen apareciendo nuevos vectores, desde la inyección invisible de indicaciones basadas en imágenes hasta las cadenas de exfiltración de varios pasos. Diseñamos controles en capas y componibles para que se puedan agregar nuevas mitigaciones a medida que surjan nuevas amenazas. Es una carrera armamentista, no un problema que se resuelve una vez. Los 10 principales temas según OWASP para aplicaciones LLM son una referencia útil y continua.
No vemos estas deficiencias como razones para reducir la velocidad. Las vemos como razones para actuar de manera deliberada. La trifecta letal nos dice lo que está en juego. El contexto, los puntos de verificación y los controles nos proporcionan un marco para la acción. Y como ningún Equipo resuelve esto por sí solo, estamos invirtiendo activamente junto con nuestros socios de investigación y clientes para fortalecer estas superficies a medida que evoluciona el panorama de las amenazas.
Referencias
Simon Willison, “The lethal trifecta for AI agents”, junio de 2025
Korny Sietsma, “Agentic AI and Security”, Martin Fowler, octubre de 2025
Bruce Schneier, “We Are Still Unable to Secure LLMs from Malicious Inputs”, agosto de 2025
