# Quebrando a tríade letal: como a Asana pensa sobre a segurança da IA agêntica > Saiba como a Asana desenvolve a IA agêntica de forma responsável quando o setor ainda não definiu os fundamentos. Source: https://asana.com/inside-asana/how-asana-thinks-about-agentic-ai-security ## 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](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) 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](https://simonwillison.net/2025/Jun/11/echoleak/),[o servidor MCP do GitHub](https://simonwillison.net/2025/May/26/github-mcp-exploited/), a[IA do Slack](https://simonwillison.net/2024/Aug/20/data-exfiltration-from-slack-ai/) e muitos outros. Bruce Schneier[foi direto](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html): 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](https://martinfowler.com/articles/agentic-ai-security.html), 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](https://asana.com/ai-principles). **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](https://simonwillison.net/2025/Jun/13/prompt-injection-design-patterns/) 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](https://brave.com/blog/unseeable-prompt-injections/) 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](https://genai.owasp.org/llm-top-10/), 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",](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/) junho de 2025 - Korny Sietsma,[“Agentic AI and Security”,](https://martinfowler.com/articles/agentic-ai-security.html) Martin Fowler, outubro de 2025 - Bruce Schneier,[“We Are Still Unable to Secure LLMs from Malicious Inputs”,](https://www.schneier.com/blog/archives/2025/08/we-are-still-unable-to-secure-llms-from-malicious-inputs.html) agosto de 2025 - [Princípios da IA Asana](https://asana.com/ai-principles) - OWASP,[“Top 10 for LLM Applications”](https://genai.owasp.org/llm-top-10/) - [Microframeworks no painel do administrador](/pt/inside-asana/microframeworks-admin-console) engenharia Toda implementação da Asana tem um painel do administrador. É onde os administradores de TI configuram como a empresa usa a Asana, por exemplo, ajustando os requisitos de senha, a ... - [Desenvolvimento orientado por especificações: os aspectos positivos e o que aprendemos após três meses](/pt/inside-asana/spec-driven-development) engenharia #### Engenheiro/a de software da equipe Depois de três meses, tínhamos uma ideia mais clara de quando a estrutura adicional ajudava e quando atrapalhava.Um dos nossos engenheiros estava preparando uma migração de dados ... - [Migramos do Enzyme em duas semanas. Deveria ter levado cinco anos.](/pt/inside-asana/migrating-off-enzyme-2-weeks) engenharia Recentemente, usamos a IA para concluir anos de trabalho de engenharia em cerca de um sprint. Veja como e por que isso mudou a nossa maneira de pensar sobre o que é possível.O pro ... - [Como os Assistentes de IA criam memória: transformando o trabalho em conhecimento reutilizável](/pt/inside-asana/ai-teammates-turn-work-into-reusable-information) Inteligência artificial (IA) engenharia A maioria dos produtos de IA trata a memória como um recurso pessoal — lembrando fatos sobre um usuário ou uma conversa. Mas a IA que colabora entre equipes precisa de um tipo de ... - [Quebrando a tríade letal: como a Asana pensa sobre a segurança da IA agêntica](/pt/inside-asana/how-asana-thinks-about-agentic-ai-security) engenharia - [Engenheira de segurança de pessoal](/author/varun-prusty) 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 ... - [engenharia](/inside-asana/engineering-spotlight)