Quebrando a tríade letal: como a Asana pensa sobre a segurança da IA agêntica
A IA agêntica introduz uma classe de risco de segurança que a indústria ainda não resolveu. Na Asana, é assim que enxergamos esse conceito, e estas são as invariantes de segurança que mantemos em todos os nossos recursos de IA.
O problema
Os sistemas de IA agentiva não se limitam a responder a perguntas. Eles leem documentos, realizam ações e coordenam entre ferramentas. Quanto mais eles podem fazer, maior é a sua superfície de ataque.
Ao contrário do código convencional, os LLMs têm uma propriedade que torna isso fundamentalmente difícil: eles não conseguem distinguir de forma confiável as instruções dos dados. Tudo o que é fornecido a um LLM chega ao mesmo fluxo, portanto, um dado cuidadosamente elaborado pode sequestrar o modelo da mesma forma que uma instrução legítima faria. Esta é a raiz da injeção de prompt, o que Simon Willison chama de “o pecado original” dos aplicativos baseados em LLM.
Não é algo teórico. Pesquisadores demonstraram essa classe de ataque contra o Microsoft 365 Copilot, o servidor MCP do GitHub, a IA do Slack e muitos outros. Bruce Schneier foi direto: o setor ainda não tem defesas robustas contra essa classe de ataque.
Então, como criar IA agêntica de forma responsável quando a indústria ainda não entendeu os fundamentos?
O trio letal
Willison resume o risco principal em três capacidades que, em conjunto, criam as condições para o dano:
Acesso a dados confidenciais. O agente pode ler informações confidenciais ou privadas.
Exposição a conteúdo não confiável. O agente processa informações que podem conter instruções adversárias ocultas.
A capacidade de se comunicar externamente. O agente pode enviar informações para fora do sistema.
Um refinamento útil na terceira etapa: trata-se realmente da capacidade de criar efeitos colaterais, não apenas da comunicação de saída. A exfiltração de dados para o servidor de um invasor é o exemplo clássico, mas uma instrução mal-intencionada que silenciosamente renomeia todos os projetos em um espaço de trabalho ou envia conteúdo confidencial para o canal interno errado é o mesmo tipo de problema. Usamos “comunicação externa” como abreviação, mas a versão mais ampla é aquilo contra o que realmente nos defendemos.
Qualquer uma das etapas do trio é gerenciável. Mesmo duas juntas geralmente são. Mas, quando todas as três convergem, você tem um caminho de ataque viável.
O insight importante: quebrar qualquer uma das etapas reduz substancialmente o risco geral. Não precisamos resolver perfeitamente a injeção de prompt. Ninguém conseguiu. Precisamos nos certificar de que as três condições não possam coexistir facilmente.
Korny Sietsma desenvolve essa ideia, mapeando o trio para mitigações como sandboxing, decomposição de tarefas, privilégio mínimo e human-in-the-loop. Estes são os elementos essenciais. A questão é como operacionalizá-los.
Contexto, pontos de verificação e controles
Organizamos o nosso pensamento em torno de três pilares que estão diretamente relacionados à tríade letal. Cada um restringe uma perna.
A Asana tem várias interfaces de IA. Os assistentes de IA são participantes agentes com a sua própria participação e permissões no espaço de trabalho. Outras funcionalidades de IA operam como o usuário, tendo como limite o que esse usuário já pode acessar. As invariantes abaixo se concentram no caso da IA como agente, onde a superfície é maior, e destacaremos onde a implementação difere por superfície.
Contexto: Gerenciar o que a IA pode ver
Trifecta leg: Acesso a dados confidenciais
Para que a IA agentiva seja útil, ela precisa de contexto. O desafio é dar a ela o suficiente para ser útil, sem lhe dar uma chave mestra.
A nossa invariante fundamental é o princípio do privilégio mínimo, cuja expressão exata depende da superfície. Para os assistentes de IA, que têm a sua própria associação separada de qualquer usuário individual, o limite é a interseção das permissões do assistente de equipe e do usuário. Para as funcionalidades de IA que atuam como o usuário, o limite é simplesmente o próprio acesso desse usuário. Em todos os casos, a mesma camada de autorização do lado do servidor que rege todas as outras interações na Asana rege o acesso da IA. As funcionalidades de IA não recebem permissões elevadas. Eles operam dentro do sistema de controle de acesso da Asana, não ao redor dele.
Definir o contexto envolve mais do que regular o acesso a dados internos dentro da Asana; abrange igualmente as integrações externas com as quais um agente pode interagir. Embora as integrações atualmente exijam autorização explícita do usuário, estamos desenvolvendo caminhos de controle granulares e específicos para cada agente. Isso permite que as organizações restrinjam os privilégios de integração para os assistentes de IA que lidam com entradas de alto risco. A nossa invariante arquitetônica central é clara: o limite do que uma IA pode ver deve ser dinâmico e orientado pelos proprietários dos dados, em vez de ser um padrão de produto codificado.
Mesmo que um invasor introduza instruções mal-intencionadas no contexto da IA, o que a IA pode realmente ver é limitado pelo mesmo modelo de permissão que todo o resto.
Pontos de verificação: filtrar o que a IA ouve
Etapa da Trifecta: exposição a conteúdo não confiável
Esta é a etapa mais difícil. Em uma plataforma de gestão de trabalho, a maior parte do que a IA lê é conteúdo gerado pelo usuário: tarefas, comentários, documentos anexados. Parte disso vem de fora da organização. Não é possível impedir a leitura.
Em vez disso, estabelecemos pontos de verificação: lugares onde distinguimos a intenção confiável do conteúdo arbitrário e onde os humanos podem intervir se algo parecer errado.
Gestão de instruções com reconhecimento da fonte. Os recursos de IA marcam o conteúdo por confiança do autor e por fonte, para que o modelo possa priorizar as instruções de usuários autorizados em relação às instruções encontradas em conteúdo arbitrário ao longo do caminho. Isso reduz a superfície de ataque para injeção de prompt, mas não a fecha; o modelo ainda lê tudo em seu contexto, e a garantia de segurança é parcial, e não absoluta. Discutimos os limites dessa abordagem a seguir.
Registro e investigação forense. Cada chamada de modelo é registrada com suas entradas, saídas, ator, contexto de recurso e eventos downstream, incluindo quais objetos do work-graph uma automatização tocou e quais URLs apareceram na saída. Alertamos automaticamente sobre sinais operacionais, como taxas de erro e picos de custo. Para anomalias relevantes para a segurança, esses mesmos registros permitem a investigação posterior por humanos. Como Willison observa, mesmo a detecção baseada em padrões, que identifica a maioria dos ataques, seria insuficiente por si só; a visibilidade e a capacidade de investigar são a base durável sobre a qual construímos, não o muro.
Design human-in-the-loop. As funcionalidades de IA expõem o seu trabalho para revisão humana, em vez de realizar ações irreversíveis silenciosamente.
Decomposição de tarefas e ações com escopo definido. Os fluxos de trabalho complexos são divididos em etapas menores, e as ações disponíveis para os recursos de IA são intencionalmente restritas, em vez de abertas.
Nenhuma dessas opções é individualmente à prova de balas. Juntos, eles formam uma defesa em profundidade.
Controles: restringir em que a IA pode agir
Terceira etapa: a capacidade de criar efeitos colaterais
A terceira perna é onde a maioria dos ataques do mundo real acontece. Se um invasor convencer uma IA a incorporar dados sensíveis em um URL, enviá-los por meio de uma integração ou alterar um registro do qual outras pessoas dependem, o ataque será bem-sucedido.
Investimos em várias categorias de controle aqui:
Tratar o resultado do LLM como não confiável. O conteúdo gerado não recebe um aumento de confiança por ter sido produzido por uma IA Asana. Ele passa pelos mesmos caminhos de validação e renderização que qualquer outro conteúdo gerado pelo usuário.
Aprovação humana obrigatória para ações de alto impacto. Certas categorias de ações sempre exigem aprovações humanas explícitas, independentemente do grau de confiança da IA ou do quão rotineira a solicitação pareça. Para os assistentes de IA, isso inclui ações que elevam o acesso (alteração de permissões, adição de membros) e ações que destroem dados (exclusões). A IA pode propor essas ações, mas não pode executá-las por conta própria.
Barreiras de proteção para o tratamento de links. Os URLs externos no conteúdo gerado por IA são processados antes de chegarem a um usuário. Novos URLs que não apareceram na entrada passam por um escrutínio extra e aparecem em sua forma completa e não ocultada, em vez de como texto âncora renomeado, para que a IA não possa ser usada como arma para disfarçar um endpoint de exfiltração como um amigável "clique aqui para ver o resumo".
Sem HTTP de saída de uso geral. As funcionalidades de IA não têm uma primitiva aberta do tipo “enviar uma solicitação a qualquer URL”. As integrações externas passam por canais com escopo definido e com a sua própria autorização.
Trilha de auditoria de ações. Cada gravação, mutação e ação de saída que uma funcionalidade de IA realiza é registrada juntamente com a chamada do modelo que a acionou, para que um investigador possa reconstruir o que uma IA fez, não apenas o que lhe foi solicitado.
A meta não é impossibilitar a comunicação externa. As funcionalidades de IA precisam fazer referência a links, atualizar tarefas e produzir resultados úteis. A meta é assegurar que elas não possam fazer isso de forma oculta, de uma maneira que o usuário não pretendia.
Um padrão para valores emitidos pela IA
Dentro desse quadro, o mesmo subproblema concreto continua surgindo: um recurso de IA produz algo (um ID de objeto, um destinatário, um URL) e o código downstream age sobre isso, muitas vezes com permissões mais amplas do que a própria IA. As alucinações e as injeções de prompt chegam ao mesmo lugar: um valor emitido pelo modelo passa a ser confiável.
Nós utilizamos um padrão de quatro partes como uma lista de verificação de revisão de design para esses valores:
Em primeiro lugar, restrinja o que a IA tem permissão para produzir, antes que a validação precise ser executada.
Valide cada valor produzido pela IA no lado do servidor em relação à mesma camada de autorização que todo o resto. O modelo é tratado como um cliente não confiável.
Justifique a escolha mantendo contexto estruturado suficiente para explicar por que a IA escolheu o que escolheu. É isso que possibilita a investigação, as avaliações e a resposta a incidentes posteriormente.
Encaminhe com fricção, fallback ou revisão humana quando um valor for de alto risco ou estiver fora do escopo esperado.
O fio condutor: o comportamento do modelo não deve ser o principal controle de segurança. Prompts melhores e “dissemos ao modelo para não fazer isso” são uma defesa em profundidade útil, mas os controles duráveis estão no sistema ao redor do modelo.
Fundamentadas em princípios
Essas escolhas não são pontuais. Elas decorrem dos princípios de IA publicados pela Asana.
As pessoas são responsáveis pelas decisões, o que impulsiona o design orientado a pontos de verificação. A IA auxilia, mas os humanos ficam por dentro de tudo e são responsáveis.
Estamos comprometidos com a segurança, o que justifica o investimento em controles em camadas, mesmo quando eles geram atrito. A alternativa aumenta o risco à medida que os recursos de IA assumem trabalhos mais complexos.
Promovemos a transparência, e é por isso que estamos escrevendo esta publicação. Ainda não resolvemos a segurança da IA agentiva. Mas sermos abertos sobre como raciocinamos sobre esses riscos e as mitigações que realizamos ajuda a comunidade em geral a progredir em um desafio compartilhado e incentiva o escrutínio que nos torna melhores.
Os limites honestos
A injeção de prompt ainda está fundamentalmente sem solução, e a injeção indireta de prompt (as instruções adversárias chegam incorporadas ao conteúdo que a IA obtém durante o seu trabalho, em vez de serem um conteúdo que um usuário fornece diretamente) é a variante que mais afetou o setor em 2026. A marcação com reconhecimento da fonte ajuda, mas não resolve totalmente esse problema, porque o modelo ainda precisa escolher respeitar as tags. Os nossos pontos de verificação reduzem significativamente o risco, mas não o eliminam. Enquanto as instruções e os dados compartilharem uma janela de contexto, as entradas adversárias obtidas por meio de pesquisa, formulários públicos ou integrações às vezes passarão despercebidas. Tratamos isso como uma área de investimento ativa e contínua, com um escrutínio mais minucioso de qualquer caminho que permita que o conteúdo de autoria externa chegue a um recurso de agente. O trabalho em padrões de design para proteger os agentes de LLM aponta para direções promissoras, mas o consenso do setor ainda está em formação.
O cenário de ameaças muda rapidamente. Novos vetores continuam aparecendo, desde a injeção invisível de prompts baseados em imagens até as cadeias de exfiltração de várias etapas. Projetamos controles em camadas e compostos para que novas mitigações possam ser adicionadas à medida que surgem novas ameaças. É uma corrida armamentista, não um problema que se resolve uma única vez. Os dez principais riscos de segurança em aplicativos LLM, segundo a OWASP, são uma referência útil e atual.
Não vemos essas lacunas como motivos para desacelerar. Nós as vemos como razões para sermos deliberados. O trio letal nos mostra o que está em jogo. Contexto, pontos de verificação e controles nos fornecem uma estrutura para a ação. E, como nenhuma equipe resolve isso sozinha, estamos investindo ativamente, juntamente com os nossos parceiros de pesquisa e clientes, para fortalecer essas superfícies à medida que o cenário de ameaças evolui.
Referências
Simon Willison, "The lethal trifecta for AI agents", junho de 2025
Korny Sietsma, “Agentic AI and Security”, Martin Fowler, outubro de 2025
Bruce Schneier, “We Are Still Unable to Secure LLMs from Malicious Inputs”, agosto de 2025
