Como protegemos os sistemas internos do Figma com agentes

Para proteger nossas plataformas internas, as ameaças que combatemos na equipe de engenharia de segurança da Figma estão sempre mudando. A infraestrutura de nuvem muda frequentemente, os desenvolvedores adotam novas ferramentas, e os programas instalados e executados nos laptops dos usuários mudam a cada trimestre (como quando sua equipe de embaixadores de design começa a programar apps e automações por conta própria).

Nosso SIEM, o Panther, ajuda a prever todas essas ameaças executando diversas verificações em nossa infraestrutura de nuvem, extremidades, apps SaaS e sistemas de identidade. Quando detecta um possível problema, ele publica alertas no Slack e cria um ticket no Asana para informar os engenheiros de plantão. O plantão tradicional envolvia uma enorme quantidade de trabalho manual. Entender o contexto era a maior dificuldade. Era preciso descobrir se o alerta era semelhante a algum evento recente, se havia um PR pendente que poderia resolver o problema, se havia conversas no Slack mencionando algo relacionado, e assim por diante.

Como tantas outras equipes, percebemos a rápida aceleração de capacidade dos modelos de LLM no último ano. Há pouco tempo, contamos como a Figma previne vulnerabilidades com agentes em nosso código, o que identificou problemas em mudanças de configuração em ferramentas sensíveis como Okta e AWS, graças a investimentos anteriores em armazenamento de configurações em forma de código. Mas, para reduzir significativamente o trabalho e melhorar a proteção dos sistemas internos da Figma, era preciso ir além do código e criar um novo sistema, que ajudasse a gerenciar todo o escopo de problemas que nosso SIEM encontra.

Começamos com um objetivo restrito de construir uma camada de recuperação que revelasse o raciocínio dos engenheiros de plantão quando um novo alerta fosse acionado. Esse projeto acabou evoluindo para um sistema totalmente agente que investiga alertas, consulta registros de auditoria, escreve mudanças de programação, abre PRs e melhora com o tempo através de sua própria memória. Ele mudou completamente a forma como nossa equipe de segurança trabalha.

A camada RAG: alertas com memória

A primeira coisa que construímos foi um sistema de classificação aumentado por recuperação sobre as bases de conhecimento AWS Bedrock e Amazon Kendra. Novamente, nosso objetivo inicial era apenas contextualizar o histórico do que tinha acontecido no último acionamento do alerta, e talvez suprimir alertas duplicados.

Quando um alerta do Panther dispara, ele é convertido pelo gerenciador Lambda em um documento padronizado, que é indexado no Kendra. Extraímos campos estruturados do payload bruto do alerta: IPs de p_any_ip_addresses, envolvidos de p_any_usernames e vários campos de usuário específicos do provedor, IDs de contas da AWS de ARNs. Esses campos tornam-se atributos de documento pesquisáveis do Kendra juntamente com o título do alerta, severidade, tags e carimbos de data e hora:

const attrs: DocumentAttribute[] = [
  { Key: 'alert_id', Value: { StringValue: doc.alert_id } },
  { Key: 'alert_type', Value: { StringValue: doc.alert_type } },
  { Key: 'severity', Value: { StringValue: doc.severity } },
  { Key: 'status', Value: { StringValue: doc.status } },
  { Key: 'created_at', Value: { DateValue: doc.created_at } },
  { Key: 'has_investigation_context', Value: { LongValue: doc.has_investigation_context } },
]

Quando o próximo alerta semelhante é acionado, consultamos correspondências semânticas no Bedrock usando o título do alerta (que geralmente é o nome da detecção seguido pelo nome de usuário do envolvido) como o vetor principal:

function buildQueryFromAlert(alert: Alert): string {
  return `${alert.data.title}\n\nhas_investigation_context=1`
}

Favorecemos também alertas com investigation_context, os comentários deixados por um engenheiro de plantão no Slack sobre o que foi encontrado. (Um alerta fechado sem comentários não esclarece quase nada.) Capturamos o contexto da investigação sem mudar o fluxo de trabalho atual dos engenheiros. Quando alguém deixa uma nota numa conversa no Slack sobre o alerta (e temos um procedimento semelhante para tickets do Asana), indexamos esse comentário no Kendra como contexto de investigação no alerta original:

export async function addInvestigationContext(
  alertId: string, contextText: string
): Promise<void> {
  const existingDoc = await findAlertDocument(alertId)
  if (!existingDoc) return

  let updatedContext: string[]
  updatedContext = [...existingDoc.investigation_context, contextText]

  const updatedDoc: AlertDocument = {
    ...existingDoc,
    investigation_context: updatedContext,
    has_investigation_context: 1,
  }
  await reindexDocument(updatedDoc)
}

Sempre que alguém escreve um comentário útil numa conversa de alerta, a triagem de qualquer alerta semelhante no futuro fica mais barata. Não precisávamos de uma ferramenta especial de anotação ou de um pipeline de treinamento, porque o fluxo de trabalho atual já é o pipeline de treinamento.

Até onde chegava a recuperação

Nosso sistema de recuperação gera e publica um resumo (para consumo humano) no Slack/Asana para cada alerta. A redução da carga de trabalho do plantão foi quase imediata. Algumas pessoas disseram que estava reduzindo o tempo de triagem de alertas, e também conseguimos fazer algumas mudanças automatizadas para reduzir o excesso de alertas. Quando encontramos alertas semelhantes com alta probabilidade de serem benignos ou duplicados, reduzimos automaticamente a gravidade:

if (autoResolutionConfidence >= 7) {
  if (updatedSeverity === 'high' || updatedSeverity === 'critical') {
    await alertsDb.updateAlertSeverity(alert.alertId, 'medium')
  }
}

Só essa mudança já reduziu em 20% os chamados de plantão.

Instalado o sistema RAG, começamos a considerar um próximo passo, que parecia óbvio: algum tipo de camada agente para ajudar na investigação de alertas e resolver problemas automaticamente.

Adicionar uma camada agente

Usamos o Tines para construir uma camada agente sobre o nosso RAG. Quando o Panther detecta um evento, nosso manipulador de fluxo Lambda envia o alerta para o Slack com o resumo inicial do LLM e referências de alertas semelhantes da camada RAG, e em seguida, marca automaticamente o @Tines Slackbot de Segurança na conversa. Os engenheiros de plantão também podem marcar o bot manualmente em qualquer conversa para fazer perguntas de acompanhamento ou pedir outras informações específicas, conforme a situação exigir.

Quando o bot é marcado, um webhook dispara no Tines e a primeira coisa que roda é o roteamento de intenções. Um modelo mais leve (como o Claude Sonnet) lê toda a conversa do Slack e classifica a solicitação: é uma triagem de alerta, uma pergunta sobre segurança da plataforma, uma consulta de aprovação de app ou outra coisa? Cada classificação é direcionada a um agente especializado, com seu próprio inventário de ferramentas, camada de autorização e prompt do sistema. O agente de triagem de alertas gerencia a maior parte do trabalho, mas ter agentes separados para diferentes intenções significa que podemos dar um conjunto específico de ferramentas para cada um, sem o risco de um agente com alcance crescente e acesso a tudo.

O kit de ferramentas do agente de triagem de alertas

É no agente de triagem de alertas (que usa um modelo como o Claude Opus) que ocorre a maior parte da investigação. Ele recebe o histórico completo da conversa do Slack como contexto, sua própria memória de orientação (já vamos explicar), e um conjunto de ferramentas limitado ao que um engenheiro de segurança de plantão costuma usar durante a triagem, como:

• Okta: acesso ao perfil do usuário, sua lista de grupos, seu histórico de logins, busca de usuários por filtro. Quando um alerta de atividade suspeita de um usuário específico é acionado, geralmente a primeira coisa que o agente faz é acessar o perfil do usuário no Okta para entender quem é e quais são suas permissões de acesso.
• Workshop de Segurança North Pole (que gerencia nossa ferramenta de segurança de extremidade, o Santa): regras de busca, eventos de busca, verificar o status de sincronização do host, encaminhar regras para os hosts. Se o alerta incluir um binário bloqueado ou uma violação de política de extremidade, o agente pode procurar o ID assinante, verificar o histórico de eventos desse binário e ver se outros usuários estão recebendo o mesmo bloqueio.
• Wiz: abrir registros de auditoria, inventário de recursos em nuvem, descoberta de vulnerabilidades, questões em aberto e recursos expostos. Para alertas de infraestrutura em nuvem, o agente pode verificar se um recurso sinalizado tem vulnerabilidades conhecidas ou configurações incorretas.
• Slack: ler respostas em conversas, consultar perfis de usuários, enviar atualizações de progresso. O agente lê conversas anteriores vinculadas a alertas semelhantes para absorver o raciocínio e discussões pertinentes dos engenheiros de plantões anteriores.
• Panther: detalhes do alerta, eventos brutos que acionaram um alerta, lista de alertas relacionados. O agente acessa acesso o payload estruturado do alerta, além do que foi postado no Slack.
• Modificação de código: abrir PRs em nosso repositório de detecções Panther ou nosso monorepo. Já vamos falar mais disso.
• O subagente de investigação Panther: um agente separado, alimentado por LLM, que pode programar e executar Snowflake SQL em todo o nosso data lake de segurança. Esta é a ferramenta mais potente do conjunto, e vamos falar dela em seguida.

Consultar o data lake de segurança

O agente de triagem pode responder muitas perguntas com suas ferramentas diretas: "Quem é este usuário no Okta?", "Quais regras do Santa aplicam-se a este binário?", "Este recurso em nuvem está no Wiz?" Mas muitas investigações precisam ir mais fundo. O que esse usuário estava fazendo na AWS nas duas horas antes do alerta? Quais processos estavam em execução na extremidade dele? Esses processos estavam fazendo algo incomum? Ele acessou outros apps ou fez alterações de configuração nesse período?

O agente de triagem delega essas perguntas a outro subagente de investigação. Esse subagente (que também é um modelo como o Claude Opus) recebe uma consulta em linguagem natural do agente pai, convertendo-a para SQL do Snowflake. Ele roda em nosso data warehouse Panther, que absorve registros de auditoria de toda a empresa: AWS CloudTrail, registros do sistema Okta, eventos de auditoria do GitHub, registros de auditoria do GCP, telemetria de extremidade do osquery, eventos do Workshop/Santa, constatações do Wiz e cerca de cem outras tabelas.

O agente pai chama como você pediria a um colega para fazer uma consulta: “Encontre os últimos logins no Okta do usuário X nas últimas 48 horas” ou “Verifique quais processos o usuário Y executou em sua extremidade nos últimos 2 dias” ou “O que o usuário Z estava fazendo no AWS EKS entre 10:21 e 20:21 UTC em 10 de março?” O subagente descobre quais tabelas acessar, quais colunas usar e como filtrar por tempo.

Isso funciona, mas os esquemas de tabela podem ser um pouco bagunçados. Os nomes das colunas nem sempre são os mesmos em todas as fontes de registro, as chaves de junção não estão bem documentadas e as funções de particionamento por tempo variam de uma tabela para outra. Sem ajuda, o subagente gastaria quatro ou cinco consultas só para descobrir o esquema antes de conseguir responder à pergunta. Ou pior, faria a consulta de uma forma que geraria resultados incorretos ou incompletos. Na seção sobre memória, abaixo, vemos como resolvemos isso.

Desenvolver e segmentar a memória do agente

A memória acabou sendo o maior fator de impacto na utilidade do sistema com o passar do tempo. Temos vários tipos e aprendemos a importância de separá-las.

O corpus RAG é o que chamamos de memória de casos. É o sistema que já descrevemos: histórico de alertas mais contexto de investigação do Slack e Asana. Quando o agente precisa saber como foram as situações semelhantes ou o que um engenheiro de plantão concluiu sobre um incidente anterior, é aqui que ele busca.

Além disso, temos o que chamamos de memória de orientação. É uma orientação comportamental para o agente, armazenada num documento de markdown que é carregado no contexto do agente no início de cada execução. É como se fosse um arquivo AGENTS.md ou o modelo de ameaça que um agente usaria para buscar vulnerabilidades na base de código. Ele contém regras como "ao encontrar alertas de sincronização do Okta obsoletos, verifique os trabalhos de resource-sync e group-sync antes de concluir que o problema é sistêmico" ou "o usuário X vai fazer manutenção no sistema Y esta semana, esses alertas já estão previstos".

O agente pode atualizar sua própria memória de orientação quando corrigido por um engenheiro de segurança. Se alguém diz "você não fez isto certo, deveria ter feito assim", a correção persiste em operações futuras. Mas aprendemos a tomar cuidado com o que colocamos na memória de orientação e o que permanece na camada RAG. Uma lição pontual sobre um tipo específico de alerta deve entrar no contexto de investigação, para ser usada como precedente em alertas futuros semelhantes. Uma regra de comportamento, que deve mudar a abordagem do agente em todos os alertas, pertence à memória de orientação. No início, cometemos o erro de salvar tudo na memória de orientação, o que começou a desviar o comportamento do agente de formas indesejadas. Precedentes e políticas são coisas diferentes e pertencem a ambientes diferentes.

Também usamos registros baseados em banco de dados no Tines para objetos com estado: PRs abertos que o agente criou, estado da investigação no Panther, coisas que precisam de chaves estáveis e rastreamento de status, em vez de acesso por linguagem natural. São coisas mais triviais, mas necessárias.

A camada de memória mais interessante é a processual, que resolve diretamente o problema de descoberta de esquemas descrito acima. Configuramos o subagente de investigação com memória de armazenagem própria, organizada por tags (aws, okta, osquery, workshop, etc.). Antes de iniciar uma consulta, o agente carrega memórias relevantes para as fontes de dados que vai acessar. Após finalizar uma investigação com descoberta de esquema, ele salva o que aprendeu:

Title: Job Description Fields in Workiva Logs (2026-03-12T16:25:21 UTC)
Memory: Job descriptions for each user within the system can be found within the field 'jd' in the table 'WORKIVA_USERS'.

Um segundo LLM (usando um modelo mais leve) gerencia a formatação real da memória: a partir da descoberta bruta, gera um título com um carimbo de data e hora UTC, a marca e grava a memória. Da primeira vez em que perguntamos ao agente de investigação sobre atividades no Zoom, foram necessárias várias consultas de descoberta. Depois que ele salvou uma memória, a mesma pergunta exigiu só uma consulta. Esse padrão se repetiu em todas as fontes de dados à medida que o agente estabeleceu seu próprio manual de operações através de tentativa e erro.

Exemplos de investigações de agentes

Para ilustrar como o agente funciona na prática, veja estes três exemplos recentes.

Primeiro, há o caso de um alerta que foi acionado porque alguém instalou um app de transcrição de áudio para macOS que não tinha sido revisado e aprovado para uso no Figma. O agente de triagem leu a conversa do alerta, acessou alertas semelhantes do histórico na camada RAG e usou suas ferramentas Okta e Workshop para ligar os pontos. O usuário era o mesmo engenheiro que tinha criado a regra de detecção: eu mesmo, Matthew! O Workshop mostrou uma regra criada no mesmo dia, com escopo individual, que havia sido criada para testes. Conclusão: o autor da regra estava testando sua própria detecção. Não era preciso fazer nada. O agente até registrou que, considerando meu status no Slack, eu estava concentrado e provavelmente demoraria um pouco para confirmar minhas atividades.

Outro caso: páginas de alerta do Snowflake dispararam repetidamente para a mesma conta de serviço. O agente descreveu o estado atual, delegou ao subagente de investigação a consulta dos registros de auditoria relevantes, identificou por que os alertas estavam recorrendo, descobriu que já havia uma PR de rascunho aberta para suprimi-los, e explicou a solução de longo prazo que estava sendo discutida noutra conversa. O engenheiro de plantão recebeu a análise completa sem abrir uma única aba, um feito inimaginável até poucos meses atrás.

Finalmente, muitas vezes disparamos alertas em situações que poderiam ser ataques de malware, mas geralmente são comportamentos bastante legítimos (como um serviço de lançamento desconhecido sendo instalado em MacBook com o Figma). Antes, isso seria impensável; nossa equipe atende milhares de Figmates, o volume de alertas seria estratosférico. No entanto, no novo modelo, nosso agente pode conferir se o binário foi assinado por uma entidade confiável, usar o recurso de consulta no Panther para descobrir como foi instalado (brew, App Store, etc.) e e gravar automaticamente as alterações necessárias no código para suprimir o alerta em condições sabidamente seguras no futuro, tudo isso sem nenhuma intervenção humana.

Da investigação às alterações no código

O recurso mais surpreendente em termos de economia de tempo foi a distância entre o agente dizer "Descobri o que está acontecendo" e "aqui está uma PR para fazer a correção".

Existem dois caminhos para o código. Nas alterações de regras de detecção, listas de permissão e supressão de alertas, o agente abre PRs em nosso repositório de detecções Panther. O caso mais comum: um alerta dispara repetidamente para um padrão sabidamente benigno, um engenheiro de plantão confirma que é um falso positivo na conversa do Slack e o agente gera uma entrada na lista de permissões ou ajusta a regra de detecção. Para todo o resto, como alterações na infraestrutura, configurações de serviço, Terraform, ou configuração de RBAC e provedor de identidade, o agente trabalha em nosso monorepo.

Se um revisor comentar a PR, o agente acessa os comentários com um webhook do GitHub e pode fazer novas alterações ou responder. Ele também pode rebasear ramificações desatualizadas no último master quando as PRs ficam abertas por mais tempo.

Limites

Todas as chamadas de ferramenta incluem salvaguardas determinísticas para garantir que o agente não tente fazer algo que não queremos que ele faça. Por exemplo, toda PR que o agente cria é configurada automaticamente como rascunho. Isso é executado como etapa posterior obrigatório no fluxo de trabalho do Tines, não como instrução de prompt, porque constatamos logo no início que pedir para o LLM lembrar de "criar sempre como rascunho" não era uma opção confiável.

Usamos esse tipo de contrato de chamada de ferramenta para impor vários controles obrigatórios, como garantir que o agente não receba nem processe dados confidenciais de funcionários ao acessar o Okta, ou impedir que o agente tente fechar ou modificar pull requests que não sejam de sua autoria. Como a segurança de qualquer sistema depende de camadas de controles, também temos o cuidado de garantir que as ferramentas disponíveis para o agente estejam devidamente dimensionadas, autorizadas e monitoradas, e que o próprio agente trabalhe em nome de um membro da equipe autorizado.

Também tentamos restringir as consequências de contextos inadequados. O agente não tem acesso ambiente a canais inteiros do Slack e, fora das DMs, só pode ler uma conversa quando foi explicitamente remarcado na mensagem mais recente.

Finalmente, a autonomia em ações limitadas, reversíveis e baseadas em evidências claras nos deixa muito mais tranquilos do que ações amplas, destrutivas ou difíceis de auditar. Na prática, isso significa que investigações com muita leitura, detecção de duplicatas, busca de precedentes e remediação em rascunho são processo mais adequados para execução com agentes do que operações genéricas de gravação de alta potência.

Esperamos que, com o tempo, mais alertas passem a ser resolvidos automaticamente, mas apenas com padrões de segurança mais rigorosos: escopos de ação mais restritos, avaliação melhor (como neste exemplo de estabelecimento de confiança em agentes de IA por meio de métricas) e mais clareza nos motivos que levam o sistema a cada conclusão.

O que aprendemos

Algumas coisas que faríamos diferente se fôssemos começar do zero hoje:

• A memória processual deveria ter existido desde o início. A memória de esquema auto-desenvolvida pelo agente de investigação foi uma adição tardia, e a melhora foi tão radical que, com a perspectiva de hoje, tudo que fizemos antes parece quase um desperdício de trabalho.
• A configuração em forma de código é essencial para evitar a fragmentação da camada do agente. Como os membros da equipe querem fazer testes rápidos, as pessoas acabam criando e operando cópias ligeiramente diferentes do mesmo agente central com configurações de ferramentas um pouco diversas, usadas para fins distintos. Não é difícil imaginar que fica muito difícil manter a padronização e o funcionamento uniforme de todas as ferramentas disponíveis para esses agentes. Hoje, nosso conjunto central de ferramentas é configurado e gerenciado independentemente de qualquer agente específico, com configuração programada em código, garantindo que todos os agentes sigam um conjunto de ações bem organizado e padronizado.
• Se estiver criando um agente para integrar com o Slack, recomendamos analisar antes o modelo de confiança para canais públicos. Nossos agentes têm controles de autorização para garantir que apenas membros da equipe de segurança possam comandá-los, mas se um agente decidir fazer buscas em registros detalhados de atividades de usuários, vários tipos de dados confidenciais podem aparecer. Os dados que descrevem as atividades de um usuário naquele dia são completamente aceitáveis em uma conversa privada na área de segurança, mas são muito problemáticos numa sala com cem pessoas. Gerenciamos isso criando prompts que levam em conta os canais e outros controles obrigatórios, mas é o tipo de coisa que deve ser projetado desde o início, não adicionado depois.

Onde estamos e para onde vamos

O sistema gerencia todo o trabalho inicial de resposta de segurança para a equipe. A função do engenheiro de plantão deixou de ser "investigar do zero" e agora é “revisar o que o agente encontrou, confirmar ou corrigir, e gerenciar os casos que precisam de decisões humanas”.

Houve uma redução de cerca de 70% no tempo de resolução de alertas complexos, 20% de redução nos chamados de plantão (resultado de rebaixamento do nível de gravidade pela IA), 25% menos solicitações de aprovação de software de extremidade (o agente detecta quando um usuário está buscando uma ferramenta e indica opções semelhantes aprovadas) e aumento significativo da confiança dos engenheiros de plantão na qualidade de resolução, porque a cadeia de evidências do agente é aberta e revisável.

Daqui a um ano, o sistema terá internalizado milhares de decisões de triagem, mapeamentos de esquemas e correções de comportamento que nenhuma pessoa da equipe conseguiria memorizar. Essa é a parte que nos deixa mais otimistas: não cada execução de agente, mas o fato de que cada execução faz com que a próxima fique mais barata e mais precisa.

Para a próxima fase, planejamos melhorar o plano de controle do modelo. Queremos esclarecer as distinções entre nossas camadas de memória para precedentes, políticas e estados. Queremos melhorar as formas de decidir quando é seguro fechar um alerta automaticamente ou quando ele deve ser encaminhado, mesmo que o modelo pareça confiante. E queremos que os fluxos de trabalho em que mais confiamos avancem do comportamento imediato para a automação determinística e inspecionável.

Uma última observação: discute-se muito se vale a pena usar IA para investigar problemas, porque a IA não é perfeita. Mas os seres humanos também não são perfeitos. Para nós, não é uma questão de escolher entre humanos e IA. Existem muitas coisas que podem ser feitas entre esses dois extremos para reduzir o risco e melhorar a eficiência, e ainda estamos só começando a criar essas regras.

Temos orgulho do que construímos e estamos empolgados com o futuro, mas sabemos que é só o começo de uma longa jornada com imenso potencial e prováveis armadilhas. Se outras equipes estiverem criando sistemas semelhantes, falem com a gente! Seria muito bom comparar as experiências.