Considerações sobre Acesso a Dados e Permissões

Segurança por padrão A REDA AI opera dentro do modelo de segurança do Salesforce. O compartilhamento de registros é sempre aplicado — um agente nunca alcança um registro que o usuário com que ele é executado já não pudesse ver. As permissões em nível de campo e de objeto também são aplicadas por padrão, em todos os canais. A única exceção é deliberada e controlada pelo administrador: um agente de API não assistido pode ser configurado para ignorar as permissões de campo e de objeto (nunca o compartilhamento) — consulte Canal API.

Modelo de segurança do Salesforce na REDA AI

Todo acesso a dados por meio dos agentes da REDA AI é regido pelo modelo de segurança abrangente do Salesforce:

Segurança em nível de campo (FLS) — Os agentes não conseguem ler/gravar campos aos quais o usuário não tem acesso
Permissões em nível de objeto — Os agentes não conseguem consultar ou criar registros em objetos aos quais o usuário não tem acesso
Compartilhamento de registros — Os agentes só podem acessar registros explicitamente compartilhados com o usuário
Hierarquia de papéis — Gestores podem ver os registros de seus subordinados de acordo com as regras da hierarquia de papéis
Grupos públicos e equipes — O compartilhamento por meio de grupos e equipes é respeitado

A REDA AI não contorna o compartilhamento de registros. Em todos os canais, um agente alcança apenas registros que o usuário em execução já alcançava.

Existe uma exceção deliberada, e ela vale apenas para permissões de objeto e de campo: um agente cujo Contexto de execução seja Sistema e cujo Canal seja API lê campos que o usuário em execução não pode ver. As duas condições são exigidas, a combinação nem sequer pode ser salva em outros canais e o compartilhamento nunca é ampliado — um agente elevado vê mais colunas em registros que já alcançava, nunca um registro novo. Em todo o resto, o agente opera exatamente como o usuário conectado. Veja Segurança dos dados.

Conjuntos de permissões para a REDA AI

A REDA AI inclui vários conjuntos de permissões para controlar quem pode acessar os agentes:

Conjunto de permissões	Caso de uso	Nível de acesso
REDAAI_Admin	Administradores que configuram e gerenciam agentes	Podem criar, editar e excluir agentes; configurar todas as definições
REDAAI_User	Usuários padrão que usam agentes (canal interno)	Podem conversar com agentes; respeita suas permissões do Salesforce
REDAAI_Community_User	Usuários de portal que acessam agentes pelo canal de comunidade	Podem conversar com agentes; respeita as permissões do usuário de portal
REDAAI_External_Guest_User	Visitantes do site usando o canal de widget externo	Podem conversar com agentes; respeita as permissões do perfil de usuário convidado

Atribua o conjunto de permissões apropriado aos usuários com base em seu papel. Usuários sem um conjunto de permissões não conseguem interagir com os agentes.

Como a segurança funciona por canal

Canal interno

Os usuários são autenticados por login do Salesforce. O agente opera como o usuário conectado:

A FLS do usuário se aplica — o agente só pode acessar campos que o usuário pode ler/gravar
As permissões de objeto do usuário se aplicam — o agente só pode trabalhar com objetos aos quais o usuário tem acesso
As regras de compartilhamento do usuário se aplicam — o agente só pode ver/modificar registros compartilhados com o usuário
Exemplo: um agente de suporte usado por um representante de atendimento ao cliente só pode acessar registros de Caso e Contato compartilhados com esse representante

Canal de comunidade

Os usuários de portal acessam agentes por meio de uma experiência de portal. A segurança se baseia no perfil do usuário de portal:

A FLS do usuário de portal se aplica
As permissões de objeto do usuário de portal se aplicam
Os usuários de portal normalmente veem apenas seus próprios registros (conta, casos, contatos)
As definições padrão da organização (OWD) e o perfil do usuário de portal restringem a visibilidade dos dados

Canal de widget externo

Visitantes do site usam agentes sem autenticação do Salesforce. A segurança se baseia no perfil de usuário convidado configurado no Site:

A FLS do perfil de usuário convidado se aplica — severamente restrita para usuários externos
As permissões de objeto do perfil de usuário convidado se aplicam — geralmente muito limitadas
Usuários convidados normalmente só conseguem acessar dados publicados e registros compartilhados publicamente
Seja conservador: atribua apenas ferramentas que façam sentido para convidados não autenticados

Canal API

Um agente do canal API é acionado por outro sistema, não por uma pessoa, então é executado de forma não assistida como um usuário de integração ou automação — e não como quem iniciou o processo. Tudo o que foi dito acima continua valendo: o compartilhamento de registros, as permissões de objeto e a segurança em nível de campo desse usuário determinam o que o agente pode fazer — a menos que você defina o Contexto de execução como Sistema no agente, o que é possível apenas neste canal e eleva o acesso a objetos e campos (nunca ao compartilhamento). Se fizer isso, as permissões de campo do usuário de integração deixam de ser o limite, então decida de forma deliberada.

Isso cria um problema prático que os outros canais não têm. Como um agente do REDA AI decide o que consultar a partir do contexto, nem sempre é possível listar de antemão todos os objetos e campos que ele pode tocar — então acertar as permissões do usuário de integração é difícil, e o agente funciona nos testes e depois falha em um registro que ninguém previu.

Contexto de execução

Contexto de execução, no registro Definição de agente, resolve isso. Ele tem dois valores:

Usuário (o predefinido) — as ferramentas do agente aplicam as permissões de objeto e de campo do usuário em execução, exatamente como nos demais canais.
Sistema — as ferramentas do agente deixam de aplicar as permissões de objeto e de campo. Isso só tem efeito no canal API; defina-o em um agente de qualquer outro canal e ele é ignorado.

Sistema não amplia quais registros o agente pode ver. Este é o ponto mais mal compreendido, então vale ser preciso. O compartilhamento em nível de registro — tratado em Exemplo de compartilhamento de registros, abaixo — é sempre aplicado, com os dois valores. Sistema muda apenas quais campos e objetos o agente pode ler ou gravar em registros que ele já alcançava. Um agente não pode usar isso para chegar a um registro que estava oculto para ele.

Três controles o delimitam:

Controle	O que significa
Apenas o canal API	Ignorado em todos os outros canais. Agentes internos são executados como a pessoa conectada, onde as permissões dela são o limite correto; agentes de comunidade e do widget externo são executados como convidado, onde ignorar permissões não seria seguro.
Somente administradores	É um campo do registro Definição de agente, editável pelo conjunto de permissões REDAAI Admin. O agente não pode ativá-lo sozinho, e nenhuma instrução escrita em um prompt pode alterá-lo.
Toda chamada elevada é registrada	Sempre que uma ferramenta é executada ignorando permissões, uma entrada é gravada no registro de incidentes com a ferramenta, o objeto de destino e o usuário com que foi executada — para que “o que este agente fez com acesso elevado?” tenha sempre resposta.

Deixe o Contexto de execução em Usuário a menos que você tenha um agente de API não assistido falhando por permissões. Não é uma opção de desempenho e não há benefício em ativá-la por precaução. Quando usar, o padrão mais seguro continua sendo conceder ao usuário de integração o acesso de que ele precisa e manter o Contexto de execução em Usuário — recorra a Sistema quando essa lista realmente não puder ser definida de antemão.

A FLS em ação

Exemplo de segurança em nível de campo:

Cenário: campo de salário

Seu agente está configurado com Account.AnnualRevenue como campo de contexto. Um representante de RH tem acesso de leitura FLS ao campo. Um representante de vendas NÃO tem acesso FLS ao campo (política da empresa — vendas não deve ver a receita).

Quando o representante de RH abre uma conta, o agente vê AnnualRevenue no contexto. Quando o representante de vendas abre a mesma conta, o agente NÃO vê AnnualRevenue (a FLS impede isso). Os dois usuários veem dados diferentes de acordo com suas permissões de FLS.

Exemplo de regras de compartilhamento:

Cenário: registros de Caso

Um agente de suporte é implantado para uso pelos representantes de suporte. O Representante A foi atribuído aos Casos 001, 002 e 003. O Representante A abre o Caso 001 e conversa com o agente. O agente pode consultar e modificar o Caso 001 porque o Representante A tem acesso.

O Representante A tenta perguntar ao agente sobre o Caso 099 (atribuído ao Representante B). O agente não consegue acessar o Caso 099 porque o Representante A não tem acesso de compartilhamento a ele. Se o Representante A tentar usar ferramentas para consultá-lo, recebe um erro de permissão.

Os agentes de widget externo são acessados por visitantes não autenticados do site. A segurança é crítica aqui:

Configure um perfil de usuário convidado restritivo — o perfil deve ter permissões mínimas
Revise a FLS com cuidado — exponha apenas campos seguros para visualização pública (sem dados confidenciais)
Limite a atribuição de ferramentas — agentes de widget externo normalmente não devem ter ferramentas de gravação (sem create_record, update_record)
Teste minuciosamente — use um navegador anônimo para simular o acesso de convidado e verificar se os dados estão devidamente restritos

Exemplo: um visitante do site conversando com um Agente de Suporte de Widget Externo deve conseguir:

Pesquisar artigos da base de conhecimento (somente leitura)
Enviar um caso de suporte (create_record restrito ao próprio caso)
Verificar o status do caso (soql_query limitado aos próprios casos)

Ele NÃO deve conseguir:

Ver os casos de suporte de outros clientes
Acessar dados de funcionários
Modificar dados de preços ou configuração

Boas práticas para implantação segura de agentes

Princípio do menor privilégio

Atribua o mínimo necessário de permissões e ferramentas. Os agentes de widget externo devem ser os mais restritivos, os agentes internos um pouco mais permissivos, e os agentes de administração os mais abertos.

Revise a FLS antes de implantar — antes de adicionar um campo como campo de contexto, verifique se todos os usuários que usarão o agente devem ter acesso a esse campo. Não exponha dados sensíveis por acidente.

Atribua ferramentas de gravação com cuidado — ferramentas como create_record, update_record, delete_record e send_email devem ser restritas a agentes em que essas ações sejam apropriadas. Widgets externos raramente precisam de ferramentas de gravação.

Teste como usuários diferentes — teste seus agentes conectado como:

Um usuário padrão com permissões básicas
Um usuário com permissões restritas (sem acesso a determinados objetos)
Um usuário convidado (para widgets externos)

Verifique se cada usuário vê apenas os dados que está autorizado a ver.

Monitore a execução das ferramentas — revise os registros para ver quais ferramentas os agentes estão chamando e quais usuários as estão usando. Identifique e trate quaisquer padrões suspeitos.

Preocupações comuns de segurança e soluções

Preocupação	Solução
O agente pode expor campos confidenciais	Use a FLS para impedir o acesso. Verifique a FLS em campos sensíveis (Salário, CPF, etc.)
Usuários externos podem acessar dados internos	Use um perfil de usuário convidado restritivo para agentes de widget externo. Teste minuciosamente.
Usuários podem criar/atualizar registros errados por acidente	As ferramentas de ação exibem cartões de confirmação. Use prompts de proteção (guardrail) para evitar uso indevido.
Os agentes podem contornar as regras de compartilhamento	Impossível — a REDA AI opera dentro das regras de compartilhamento. Os agentes não conseguem acessar registros que o usuário não pode ver.
Os agentes podem consultar dados sensíveis	Use prompts e guardrails para restringir o comportamento do agente. Teste os resultados das consultas.

Conectar agentes por MCP

MCP conecta um assistente aprovado aos agentes ativos selecionados do canal Interno. Cada pessoa entra com sua identidade Salesforce. O cliente recebe pontos de entrada de agentes; ferramentas e prompts individuais não são publicados como ferramentas MCP. Configure um Site, aplicativo cliente externo, as atribuições REDA AI User e REDA AI MCP User e a habilitação do agente. Consulte o guia administrativo e o guia de uso. Os dados podem chegar ao assistente e aos provedores configurados além do Salesforce. Revise dados e contratos: isso não garante que os dados nunca saiam do Salesforce.

Perguntas frequentes

Não. A REDA AI opera como o usuário conectado. Se o usuário não pode ver um registro, o agente também não pode. Isso é aplicado na camada de dados.

O campo não é retornado. Se estiver configurado como campo de contexto, é omitido do contexto. Se o agente o consultar por meio de uma ferramenta, ele é excluído dos resultados. Nenhum erro é exibido ao usuário — o agente simplesmente não vê o campo.

Somente se você atribuir explicitamente a ferramenta create_record e o perfil de usuário convidado tiver permissões de criação nesse objeto. Isso raramente é recomendado. Para a maioria dos widgets externos, use ferramentas somente leitura ou permissões de criação bastante restritas.

Não atribua a ferramenta delete_record ao agente. Se a ferramenta não estiver atribuída, o agente não pode chamá-la. Alternativamente, use o perfil de usuário convidado ou a FLS para impedir operações de exclusão na camada de dados.

Próximos passos

Consulte configuração do canal interno para implantar agentes para sua equipe, ou explore implantação de widget externo para agentes voltados ao cliente.

← Anterior: Agente de Comunidade

Próximo: Integração de canal de mensagens →