Os agentes Agentforce ignoram a partilha do Salesforce?

Todas as conversas sobre segurança em torno do Agentforce começam com a mesma pergunta: será que os agentes contornam as nossas regras de partilha? A resposta curta é não — e perceber porquê explica tanto a razão pela qual o Agentforce é seguro por conceção como onde mora o verdadeiro risco.

Os agentes correm como um utilizador — e herdam o acesso desse utilizador

Um agente Agentforce não tem uma visão mágica própria dos seus dados. É executado como um utilizador Salesforce, e cada recuperação de dados que realiza é verificada em relação a esse utilizador:

Permissões de objeto (perfil + conjuntos de permissões)
Segurança ao nível do campo
Partilha ao nível do registo — valores predefinidos a nível da organização (OWD), hierarquia de funções, regras de partilha, partilhas manuais e implícitas

Se o utilizador em execução não consegue ver um registo, o agente também não. O Agentforce opera dentro do mesmo modelo de segurança empresarial — perfis, conjuntos de permissões, partilha, acesso baseado em funções — que rege o resto da sua organização. Suporta também políticas baseadas em atributos por cima, para regras como “só os agentes de vendas da UE podem despoletar este fluxo de trabalho”.

Os agentes Agentforce não contornam as permissões do Salesforce. Usam agressivamente todo e qualquer acesso que já exista.

Esta segunda frase é a história toda.

O verdadeiro risco: exposição amplificada, não contorno

Aqui está a parte incómoda. A maioria das organizações tem muito mais partilha aberta do que alguém se lembra de ter configurado — anos de regras de partilha, conjuntos de permissões abrangentes, acumulações na hierarquia de funções e partilhas manuais “temporárias” que nunca chegaram a ser removidas.

Uma pessoa quase nunca esbarra na totalidade daquilo a que tecnicamente tem acesso. Abre os registos com que trabalha e ignora o resto. Um agente não. Faça-lhe uma pergunta e ele recupera, cruza e resume tudo o que está ao alcance do utilizador em execução — incluindo dados que esse utilizador se esqueceu de que podia ver.

Portanto, o agente não concede novos acessos. Expõe o acesso que já existia, de forma conversacional e instantânea. A partilha demasiado abrangente que esteve latente durante anos passa a estar à distância de uma única frase.

Porque é que os agentes mudam a matemática do risco

Duas coisas tornam isto diferente de uma pessoa com as mesmas permissões:

Velocidade e escala. Um agente lê e combina registos muito mais depressa do que qualquer pessoa, pelo que uma permissão mal dimensionada é explorada de imediato e repetidamente.
Sem ponto de aprovação. Uma vez implementados, os agentes atuam com base na configuração e no contexto sem fazerem uma pausa para revisão humana — eliminando um ponto de controlo no qual o modelo de segurança tradicional discretamente assentava.

O modelo de permissões não ficou mais fraco. Aquilo que o utiliza tornou-se muito mais minucioso.

O que fazer antes de implementar

A solução não é desconfiar do Agentforce — é saber o que o seu utilizador consegue ver antes de o ligar:

Faça uma revisão de acessos ao utilizador em execução do agente — ao nível do objeto e do registo. A pergunta relevante é a mesma que está no centro de todo este blogue: quem consegue ver o quê, e porquê. Para um guia passo a passo, veja auditar o acesso a registos antes de implementar um agente de IA.
Aperte a base de referência. Defina os valores predefinidos a nível da organização tão restritivos quanto o negócio permitir; o acesso só alarga a partir daí.
Limpe as regras de partilha e os conjuntos de permissões. Remova as concessões abrangentes e obsoletas que o agente, de outra forma, herdaria.
Dê ao agente a sua própria identidade com o mínimo de privilégios em vez de um perfil humano abrangente, mais políticas baseadas em atributos.
Volte a verificar após cada alteração de partilha — os acessos derivam, e o que o agente consegue alcançar também.

Saber o que o agente consegue ver — em linguagem simples

Os passos 1 e 5 são os difíceis: reconstruir o acesso efetivo verdadeiro de um utilizador através de CRUD, segurança ao nível do campo e seis mecanismos de partilha, e depois mantê-lo atualizado à medida que a organização muda.

É exatamente isso que o AgentForceAccess faz. Pergunte, em linguagem simples, o que um utilizador — ou o utilizador em execução do seu agente — realmente consegue ver, e ele rastreia cada concessão e cita o mecanismo que está por trás. É a revisão de acessos que transforma o “achamos que o agente está corretamente delimitado” em “sabemos que está” antes de implementar.

Perguntas frequentes

Os agentes Agentforce ignoram as regras de partilha e correm como administrador?

Não. Um agente é executado como um utilizador Salesforce específico e está vinculado ao perfil, conjuntos de permissões, segurança ao nível do campo e modelo de partilha de registos desse utilizador. Não consegue ver registos que esse utilizador não conseguisse ver. No entanto, se o utilizador em causa tiver privilégios excessivos, o agente herda esse excesso de privilégios.

Então porque é que o acesso da IA é considerado um risco de segurança se respeita as permissões?

Porque a maioria das organizações acumulou mais partilha aberta do que se imagina. Uma pessoa raramente tropeça em todos os registos a que tecnicamente tem acesso; um agente recupera-os e resume-os de bom grado quando lho pedem. O agente não cria novos acessos — expõe o acesso que já existia.

Qual é a coisa mais importante a fazer antes de implementar um agente?

Auditar o que o utilizador do agente realmente vê — objeto a objeto e ao nível do registo. Restrinja os valores predefinidos a nível da organização, as regras de partilha e os conjuntos de permissões para que o utilizador (e, por conseguinte, o agente) tenha apenas o acesso de que necessita, e só depois implemente.

Posso dar a um agente um acesso mais restrito do que o do utilizador que o executa?

Sim. Provisione um utilizador dedicado, com o mínimo de privilégios, ou uma configuração de conjunto de permissões própria para o agente, em vez de reaproveitar um perfil humano abrangente, e acrescente políticas baseadas em atributos por cima. O agente deve ter o acesso mínimo necessário para a sua tarefa.