Auditar o acesso a registos antes de implementar um agente de IA

O momento mais seguro para descobrir que o seu agente de IA consegue ler todos os registos de salários da organização é antes de o implementar — e não quando um utilizador lho pede. Como um agente Agentforce herda o acesso do utilizador com que é executado, ativá-lo é, na verdade, decidir expor — de forma conversacional e à velocidade da máquina — tudo o que esse utilizador consegue ver. Este guia audita primeiro esse acesso.

Porque é que esta auditoria importa mais para os agentes do que para as pessoas

Raramente uma pessoa esbarra na totalidade do seu acesso — abre os registos com que trabalha e ignora os restantes. Um agente não. Faça-lhe uma pergunta e ele recupera, cruza e resume tudo o que está ao seu alcance. O agente não cria acesso novo; ele expõe o acesso que já lá estava — incluindo o acesso de que todos se esqueceram.

Por isso, a auditoria não é sobre a IA. É sobre responder a uma pergunta antiga com nova urgência: o que é que este utilizador consegue realmente ver?

Passo 1 — Identifique a identidade de execução do agente

Determine exatamente com que utilizador (ou configuração de utilizador) o agente é executado. Tudo o que o agente consegue ler é definido pelas permissões e partilhas dessa identidade. Se estiver a reutilizar um perfil humano abrangente, isso já é a constatação número um — consulte o Passo 5.

Passo 2 — Audite o acesso ao nível do objeto

Para essa identidade, reveja as permissões de objeto do seu perfil e conjuntos de permissões:

CRUD — que objetos pode Ler / Criar / Editar / Eliminar?
Segurança ao nível do campo — que campos sensíveis estão visíveis?
View All / Modify All — qualquer uma destas permissões num objeto (ou “View All Data”) contorna por completo o modelo de partilha e é a prioridade máxima a encontrar.

O acesso ao objeto é a porta de entrada; se o agente não tiver motivo de negócio para ler um objeto, corrija-o aqui antes de se preocupar com os registos.

Passo 3 — Audite o acesso ao nível do registo

Para os objetos que ele consegue ler, determine que registos vê, em cada mecanismo de partilha:

Predefinições para toda a organização — a base é Privada ou Pública? Uma OWD Pública significa que o agente vê todos os registos desse objeto.
Hierarquia de funções — a identidade situa-se num nível elevado da hierarquia, herdando todos os que estão abaixo dela?
Regras de partilha — que regras baseadas na propriedade e em critérios a incluem?
Partilhas manuais — alguma concessão pontual?
Partilha implícita — acesso a contas que arrasta consigo os registos-filho, a camada de que as auditorias se esquecem.

O resultado que pretende: eis o conjunto efetivo de registos que este agente consegue ler, e o mecanismo por detrás de cada um.

Passo 4 — Procure acessos demasiado abrangentes e obsoletos

Com o quadro nas mãos, procure as concessões que não deveriam estar lá:

Uma OWD de Leitura Pública que deveria ser Privada.
Regras de partilha baseadas em critérios que correspondem a muito mais do que o pretendido.
Conjuntos de permissões com “View All” deixado ativo de um projeto antigo.
Partilhas manuais que se destinavam a ser temporárias.

Cada uma delas é algo que o agente exporia de outra forma. Elimine-as.

Passo 5 — Atribua ao agente o privilégio mínimo

Não reutilize um perfil humano abrangente. Aprovisione uma identidade dedicada, de privilégio mínimo, delimitada à tarefa do agente, e sobreponha políticas baseadas em atributos para regras mais detalhadas. O agente deve ter o acesso mínimo necessário — nada herdado por acidente.

Passo 6 — Volte a auditar a cada alteração

O acesso efetivo desvia-se: uma nova regra de partilha, uma mudança de função, um ajuste num conjunto de permissões, e o alcance do agente expande-se sem que ninguém repare. Repita a auditoria após qualquer alteração às partilhas e, independentemente disso, com uma cadência regular. “Delimitado corretamente no lançamento” não é o mesmo que “delimitado corretamente hoje.”

Transformar uma auditoria de vários dias numa pergunta

Os passos 2 a 6 são a parte difícil: reconstruir o acesso efetivo real de um utilizador em CRUD, segurança ao nível do campo e seis mecanismos de partilha — e depois mantê-lo atualizado. À mão, isso são dias de trabalho e é fácil errar.

O AgentForceAccess foi concebido exatamente para isto. Pergunte, em linguagem corrente, o que o utilizador de execução do agente consegue realmente ver, e ele rastreia cada concessão — permissão de objeto, regra de partilha, partilha manual ou implícita — e cita o mecanismo. Transforma “achamos que o agente está bem delimitado” em “sabemos que está”, antes de implementar e após cada alteração.

Perguntas frequentes

Porquê auditar o acesso antes de implementar um agente?

Porque o agente vai expor tudo aquilo que o seu utilizador de execução consegue alcançar, instantaneamente e a pedido. A maioria das organizações tem mais partilhas abertas do que alguém se lembra, por isso a auditoria encontra o acesso latente que o agente exporia de outra forma — antes que o faça.

O que deve a auditoria abranger, na prática?

Duas camadas. Ao nível do objeto: as permissões CRUD do utilizador de execução e a segurança ao nível do campo do seu perfil e conjuntos de permissões. Ao nível do registo: que registos específicos consegue ver através das predefinições para toda a organização, da hierarquia de funções, das regras de partilha, das partilhas manuais e da partilha implícita.

O agente deve usar a conta de um colaborador real?

Não. Aprovisione uma identidade dedicada, de privilégio mínimo, delimitada à tarefa do agente, em vez de reutilizar um perfil humano abrangente. O agente deve ter o acesso mínimo de que necessita e nada herdado por acidente.

Com que frequência devemos voltar a auditar?

Após qualquer alteração às predefinições para toda a organização, às regras de partilha, à hierarquia de funções, aos perfis ou aos conjuntos de permissões — e com uma cadência regular, independentemente disso. O acesso efetivo desvia-se ao longo do tempo, e o alcance do agente desvia-se com ele.