Verificare l'accesso ai record prima di rilasciare un agente AI

Il momento più sicuro per scoprire che il tuo agente AI può leggere ogni record degli stipendi dell”org è prima di rilasciarlo — non quando un utente glielo chiede. Poiché un agente Agentforce eredita l’accesso dell’utente con cui viene eseguito, attivarne uno equivale in realtà a decidere di esporre, in modo conversazionale e alla velocità di una macchina, tutto ciò che quell’utente può vedere. Questo playbook verifica prima quell’accesso.

Perché questo audit conta più per gli agenti che per le persone

Una persona si imbatte raramente nell’intera estensione del proprio accesso — apre i record su cui lavora e ignora il resto. Un agente no. Fagli una domanda e recupera, mette in relazione e riassume tutto ciò che è a portata. L’agente non crea alcun nuovo accesso; espone l’accesso che già esiste — incluso quello che tutti avevano dimenticato.

Quindi l’audit non riguarda l’AI. Riguarda il rispondere a una vecchia domanda con nuova urgenza: cosa può davvero vedere questo utente?

Passo 1 — Individua l’identità di esecuzione dell’agente

Determina esattamente con quale utente (o configurazione utente) viene eseguito l’agente. Tutto ciò che l’agente può leggere è definito dai permessi e dalle condivisioni di quell’identità. Se sta riutilizzando un profilo umano ampio, quella è già la scoperta numero uno — vedi il Passo 5.

Passo 2 — Verifica l’accesso a livello di oggetto

Per quell’identità, esamina i permessi a livello di oggetto derivanti dal suo profilo e dai permission set:

• CRUD — quali oggetti può Read / Create / Edit / Delete?
• Field-level security — quali campi sensibili sono visibili?
• View All / Modify All — uno qualsiasi di questi su un oggetto (o “View All Data”) bypassa completamente il modello di condivisione ed è la cosa con la massima priorità da individuare.

L’accesso all’oggetto è il varco; se l’agente non ha alcun motivo per leggere un oggetto, correggilo qui prima di preoccuparti dei record.

Passo 3 — Verifica l’accesso a livello di record

Per gli oggetti che può leggere, determina quali record vede, attraverso ogni meccanismo di condivisione:

• Org-wide defaults — il livello di base è Private o Public? Un OWD Public significa che l’agente vede ogni record di quell’oggetto.
• Gerarchia dei ruoli — l’identità si colloca in alto nella gerarchia, ereditando da tutti quelli sottostanti?
• Regole di condivisione — quali regole basate sulla proprietà e sui criteri la includono?
• Condivisioni manuali — ci sono concessioni occasionali?
• Condivisione implicita — l’accesso agli account che trascina i record figlio, il livello che gli audit dimenticano.

Il risultato che vuoi ottenere: ecco l’insieme reale dei record che questo agente può leggere, e il meccanismo dietro ciascuno.

Passo 4 — Vai a caccia di accessi troppo ampi e obsoleti

Con il quadro completo in mano, cerca le concessioni che non dovrebbero esserci:

• Un OWD Public Read che dovrebbe essere Private.
• Regole di condivisione basate sui criteri che corrispondono a molto più del previsto.
• Permission set con “View All” rimasto attivo da un progetto passato.
• Condivisioni manuali che dovevano essere temporanee.

Ognuna di queste è qualcosa che l’agente esporrebbe altrimenti. Eliminale.

Passo 5 — Assegna all’agente il privilegio minimo

Non riutilizzare un profilo umano ampio. Crea un’identità dedicata a privilegio minimo, limitata al compito dell’agente, e sovrapponi policy basate sugli attributi per regole granulari. L’agente dovrebbe avere l’accesso minimo necessario — nulla ereditato per caso.

Passo 6 — Ripeti l’audit a ogni modifica

L’accesso effettivo cambia nel tempo: una nuova regola di condivisione, uno spostamento di ruolo, una modifica a un permission set, e la portata dell’agente si espande silenziosamente. Rilancia l’audit dopo ogni modifica alla condivisione, e comunque con cadenza regolare. “Configurato correttamente al lancio” non significa “configurato correttamente oggi”.

Trasformare un audit di più giorni in una domanda

I passi 2–6 sono la parte difficile: ricostruire l’accesso effettivo reale di un utente attraverso CRUD, field-level security e sei meccanismi di condivisione — e poi mantenerlo aggiornato. A mano, sono giorni di lavoro ed è facile sbagliare.

AgentForceAccess è costruito esattamente per questo. Chiedi, in linguaggio naturale, cosa può davvero vedere l’utente di esecuzione dell’agente, e traccia ogni concessione — permesso sull’oggetto, regola di condivisione, condivisione manuale o implicita — citando il meccanismo. Trasforma “pensiamo che l’agente sia configurato bene” in “sappiamo che lo è”, prima di rilasciarlo e dopo ogni modifica.

Domande frequenti

Perché verificare gli accessi prima di rilasciare un agente?

Perché l'agente esporrà tutto ciò che il suo utente di esecuzione può raggiungere, all'istante e su richiesta. La maggior parte delle org ha più condivisioni aperte di quanto chiunque ricordi, quindi l'audit individua l'accesso latente che l'agente esporrebbe altrimenti — prima che accada.

Cosa dovrebbe coprire concretamente l'audit?

Due livelli. Livello oggetto: i permessi CRUD dell'utente di esecuzione e la field-level security dal suo profilo e dai permission set. Livello record: quali record specifici può vedere tramite org-wide defaults, gerarchia dei ruoli, regole di condivisione, condivisioni manuali e condivisione implicita.

L'agente dovrebbe usare l'account di un dipendente reale?

No. Crea un'identità dedicata a privilegio minimo, limitata al compito dell'agente, invece di riutilizzare un profilo umano ampio. L'agente dovrebbe avere l'accesso minimo necessario e nulla ereditato per caso.

Con quale frequenza dovremmo ripetere l'audit?

Dopo qualsiasi modifica a org-wide defaults, regole di condivisione, gerarchia dei ruoli, profili o permission set — e comunque con cadenza regolare. L'accesso effettivo cambia nel tempo, e la portata dell'agente cambia con esso.