Segurança com Agentforce: o que o Security Center revela sobre agentes de produção de verdade
Salesforce usou o próprio Agentforce para acelerar investigação de incidentes internamente, e o case técnico expõe os problemas reais de colocar LLM em workflow crítico
O time de Trusted Services da Salesforce reconstruiu o Security Center como plataforma de investigação stateful powered by Agentforce. O interessante não é o resultado de marketing, é a engenharia por trás: como validar um agente não-determinístico em cenário de segurança, e por que chat sozinho não resolve incidente real.
Todo projeto de Agentforce que passa pela minha mesa começa com a mesma pergunta do cliente: "dá para colocar isso em produção com confiança?". A resposta técnica geralmente vem depois de eu explicar que agente de IA não é Flow, não é determinístico, e que "funcionou no teste" não significa "vai funcionar sempre". O case do Security Center, ferramenta interna da Salesforce para investigação de segurança, é um dos raros relatos que mostra esse problema sendo resolvido de forma honesta, sem vender solução mágica.
O time começou simples: uma interface conversacional em que o analista de segurança perguntava sobre um alerta e recebia contexto. Bonito na demo, insuficiente na prática. Investigação de incidente real não é uma pergunta e uma resposta, é um processo que atravessa triagem, escalonamento, comunicação e remediação, muitas vezes ao longo de dias. Isso é exatamente o tipo de coisa que quem trabalha com Flow e processo de negócio reconhece de cara: workflow com estado, não conversa avulsa. A saída foi transformar o agente em uma plataforma de investigação com gestão de ciclo de vida, rastreamento de remediação e auditoria, algo muito mais parecido com um sistema de case management do que com um chatbot.
O problema que todo arquiteto de Agentforce vai enfrentar
A parte mais valiosa do relato é a validação de comportamento não-determinístico. Prompt idêntico pode gerar resposta diferente em execuções diferentes, e isso é inaceitável quando o agente está avaliando o raio de impacto de um possível ataque. A solução foi usar IA para validar IA: pipelines de avaliação automatizados que simulam interação de cliente em massa e usam LLMs avaliadores para checar se a resposta atende ao resultado investigativo esperado, sem exigir correspondência exata de texto. O ganho de throughput de teste foi de 10 a 20 vezes.
Isso é a peça que falta em boa parte dos projetos de Agentforce que vejo no mercado brasileiro. Todo mundo testa prompt manualmente, aprova em três ou quatro cenários felizes e libera para produção. Não escala e não segura estabilidade em ambiente com dados reais e variação de linguagem do usuário.
Janela de contexto, agregação de telemetria e o limite real do agente
Outro ponto técnico relevante: quando a investigação cresce, o volume de telemetria supera a janela de contexto do modelo, criando o que o time chamou de "colapso de contexto", onde informação operacional crítica cai fora da janela ativa. A resposta foi particionar telemetria em segmentos menores e usar sumarização via IA antes de alimentar o agente, em vez de tentar jogar dado bruto direto no modelo.
Isso tem paralelo direto com qualquer projeto de Data Cloud ou Agentforce que lida com histórico grande de caso, contrato ou interação: não existe atalho para engenharia de contexto. Grounding malfeito gera alucinação, e alucinação em contexto de segurança significa falso positivo caro ou, peor, falso negativo que passa batido.
Esse relato não é sobre feature nova, é sobre arquitetura de agente em produção crítica, algo que a maioria dos projetos de Agentforce ainda não enfrentou na prática. Ele valida um padrão que arquitetos de Salesforce precisam levar para qualquer conversa de Agentforce: chat isolado não resolve processo de negócio complexo, e validação de comportamento de LLM exige pipeline próprio, não teste manual pontual.
Para quem lidera arquitetura de dados e IA, o ponto sobre grounding Salesforce-específico também é um alerta: o time reconhece que os modelos fundacionais públicos não entendem lógica de remediação ou modelo de ameaça específico da plataforma. Isso reforça que Data Cloud, metadados corretos e conteúdo curado são pré-requisito, não acessório, para qualquer Agentforce sério.
Vale notar que isso é uma ferramenta interna da Salesforce, o Security Center, não um produto disponível hoje para clientes usarem como está. O valor aqui é o padrão de engenharia exposto, não uma feature que você vai configurar em setup na segunda-feira. Trate como referência de arquitetura, não como release note.
Se você está desenhando um Agentforce Agent para qualquer processo com estado (atendimento complexo, aprovação, investigação, disputa comercial), não modele como conversa única. Pense em ciclo de vida: estados, handoffs, auditoria e ponto de escalonamento humano. Use Flow ou Apex para orquestrar transição de estado e deixe o agente lidar com raciocínio e comunicação dentro de cada etapa.
Monte, desde o início do projeto, um conjunto de cenários de teste automatizados que avaliam intenção e resultado, não texto exato da resposta. Se seu cliente não tem apetite para isso, é sinal de que o projeto ainda não está maduro para produção real com dados sensíveis.
Cuidado com a tentação de jogar todo o histórico e todo o dado bruto no prompt do agente esperando que "a IA lida com isso". Contexto grande demais gera degradação de raciocínio, não precisão maior. Planeje sumarização e particionamento de dado como parte da arquitetura, especialmente em Data Cloud com volume alto de registros.
Outro ponto de atenção: agente de IA aplicado a decisão sensível (segurança, financeiro, compliance) exige grounding específico do domínio. Modelo fundacional genérico não conhece sua regra de negócio nem seu processo de remediação. Sem conteúdo curado e sem Trust Layer bem configurado, você está expondo o cliente a alucinação com custo real.
Este conteúdo foi reescrito e analisado editorialmente em português a partir de informações públicas da fonte indicada.