Segurança Agentforce e o Modelo de Responsabilidade Compartilhada

A Resposta Breve

O modelo de responsabilidade compartilhada não é apenas um documento formal – é a linha que determina quem é o culpado quando algo dá errado. A regra é simples: a plataforma é responsável pela segurança do serviço em si, e a organização é responsável por todas as decisões sobre o que o agente vê, o que ele pode fazer e a quem ele responde.

O grande risco não é uma falha na segurança da plataforma. É um agente com permissões excessivas que expõe informações à parte errada ou executa uma ação que não deveria ter executado – duas falhas que têm sua origem inteiramente no lado da organização.

Divisão Real da Responsabilidade

Os Novos Riscos que Não Existiam em um CRM Regular

O primeiro é a exposição através da recuperação (retrieval). Em um sistema regular, o usuário vê o que a tela exibe; em um agente, um texto livre pode resultar na recuperação de um trecho de um documento que não era destinado a ele. Portanto, a recuperação deve ser executada no contexto das permissões do usuário, e não no contexto de uma conta de integração ampla.

O segundo é o Prompt Injection. O conteúdo que o agente lê – um e-mail de cliente, um campo de descrição, um documento anexado – pode conter instruções que tentam alterar seu comportamento. Não é possível se proteger disso apenas com a formulação; a proteção é arquitetônica.

O terceiro é o vazamento de conteúdo interno para um canal externo. Um artigo escrito para representantes com margens de desconto ou formulações de objeção não deve chegar ao cliente, e a separação deve ser feita por uma lista de permissões (allowlist) e não por uma lista de bloqueio (blocklist).

O quarto é a ampliação silenciosa da autoridade: adicionar uma Action ou permissão para resolver um problema pontual, sem passar pelo processo de aprovação.

Cinco Controles que Sustentam a Maior Parte do Peso

Recuperação no contexto do usuário. Este é o único controle que, se falhar, todo o resto não ajuda.

Autorização separada para cada Action, de acordo com o princípio da permissão mínima. Um agente que recebe um perfil amplo e único impede qualquer controle futuro.

Validação dentro da ação e não nas instruções. Uma instrução é uma diretriz; uma validação é um controle. Uma ação que realiza um estorno deve verificar o valor, a elegibilidade e a autorização em seu próprio código, mesmo que as instruções digam ao agente para não ativá-la em certos casos.

Aprovação humana para uma ação irreversível. Este é o controle que transforma uma possível falha em um evento que é interrompido a tempo.

Trilha de auditoria (audit trail) que conecta usuário, ação, origem e aprovador. Sem isso, não há resposta para a pergunta de auditoria "com base em quê o agente fez isso".

Os princípios gerais do modelo de permissões no Salesforce são detalhados no Modelo de Permissões no Salesforce.

O Que Verificar Antes do Go Live

Testes de Persona: As mesmas dez a vinte perguntas executadas com diferentes identidades – representante, gerente, usuário limitado, cliente externo – e as respostas são comparadas. Qualquer discrepância que não seja explicada por uma permissão é um achado.

Red Teaming de Conteúdo: Tentativas deliberadas de extrair informações não autorizadas, executar uma ação proibida e contornar a escalada. Os cenários são escritos uma vez e mantidos para execução repetida em cada versão.

Teste do Fluxo de Ações: Para cada Action, verifica-se se a validação funciona mesmo quando ativada diretamente, não apenas através do agente.

Teste de Retenção de Dados: O que é armazenado, por quanto tempo e quem pode acessar os logs que contêm o conteúdo da conversa com dados do cliente.

Como esses testes se integram a uma estrutura de testes mais ampla é explicado em Testes do Agentforce.

Cenário: Um Achado Capturado em um Teste de Persona

Uma empresa de saúde preparou um agente interno para responder a perguntas sobre procedimentos. Em um teste de Persona antes do lançamento, descobriu-se que um usuário com função administrativa recebeu uma resposta baseada em um procedimento classificado apenas para a equipe médica.

A razão não foi um bug no agente. O índice foi construído por uma conta de integração com acesso amplo, e a recuperação não restringia de acordo com as permissões do usuário. A mesma exposição existia potencialmente em qualquer pergunta relacionada a essa área.

A correção incluiu dois pontos: a recuperação passou para o contexto do usuário e a marcação explícita de documentos classificados para que não entrassem no índice geral. O teste foi adicionado como um cenário permanente que é executado antes de cada lançamento de versão.

Riscos e Ações Preventivas

Métricas de Segurança

A estrutura de aprovações na qual os controles são aplicados é detalhada na Governança de IA para o Agentforce.

Quando for necessário suporte na definição do modelo de responsabilidade e nos testes antes da entrada em produção, o Serviço Agentforce e IA é o caminho prático a seguir.

Lista de Verificação de Segurança Antes do Go Live

• ☐ O documento de divisão de responsabilidades foi escrito e aprovado.
• ☐ As condições de uso de dados em relação ao modelo estão documentadas por escrito.
• ☐ A recuperação é executada no contexto de permissões do usuário.
• ☐ Testes de Persona foram realizados para cada nível de permissão.
• ☐ Para cada Action, há uma permissão separada e validação interna.
• ☐ Ações irreversíveis exigem aprovação humana.
• ☐ Em canais externos, uma lista de permissões para conteúdo está ativa.
• ☐ Cenários de Red Teaming de conteúdo foram escritos e executados.
• ☐ O Audit Trail conecta usuário, ação, origem e aprovador.
• ☐ A política de retenção de logs e conteúdo de conversa foi aprovada.