Gli agenti Agentforce aggirano la condivisione di Salesforce?

Ogni discussione sulla sicurezza di Agentforce parte dalla stessa domanda: gli agenti aggirano le nostre regole di condivisione? La risposta breve è no, e capire perché spiega sia il motivo per cui Agentforce è sicuro per progettazione, sia dove vive il rischio reale.

Gli agenti vengono eseguiti come utente — ed ereditano l’accesso di quell’utente

Un agente Agentforce non ha una propria visione magica dei tuoi dati. Viene eseguito come utente Salesforce, e ogni recupero di dati che effettua viene verificato rispetto a quanto segue per quell’utente:

• Permessi sugli oggetti (profilo + permission set)
• Field-level security
• Condivisione a livello di record: org-wide default, gerarchia dei ruoli, regole di condivisione, condivisioni manuali e implicite

Se l’utente con cui viene eseguito non può vedere un record, nemmeno l’agente può farlo. Agentforce opera all’interno dello stesso modello di sicurezza aziendale — profili, permission set, condivisione, accesso basato sui ruoli — che governa il resto della tua org. Supporta inoltre policy basate sugli attributi al di sopra di tutto questo, per regole come “solo gli agenti di vendita dell’UE possono attivare questo workflow”.

Gli agenti Agentforce non aggirano i permessi di Salesforce. Usano in modo aggressivo qualsiasi accesso già esistente.

Quella seconda frase è tutta la storia.

Il rischio reale: esposizione amplificata, non aggiramento

Ecco la parte scomoda. La maggior parte delle org ha molta più condivisione aperta di quanta chiunque ricordi di aver configurato: anni di regole di condivisione, permission set troppo ampi, roll-up della gerarchia dei ruoli e condivisioni manuali “temporanee” che non sono mai state rimosse.

Una persona quasi mai si imbatte nell’intera estensione di ciò a cui tecnicamente può accedere. Apre i record su cui lavora e ignora il resto. Un agente no. Ponigli una domanda e recupererà, metterà in relazione e riassumerà tutto ciò che rientra nella portata dell’utente con cui viene eseguito, inclusi dati che quell’utente aveva dimenticato di poter vedere.

Quindi l’agente non concede nuovi accessi. Porta alla luce gli accessi che avevi già, in modo conversazionale e istantaneo. Una condivisione troppo ampia rimasta latente per anni si trova a un solo prompt di distanza.

Perché gli agenti cambiano i conti del rischio

Due cose rendono tutto questo diverso da una persona con gli stessi permessi:

1. Velocità e scala. Un agente legge e combina record molto più velocemente di qualsiasi essere umano, quindi un permesso mal definito viene sfruttato immediatamente e ripetutamente.
2. Nessun punto di controllo con approvazione. Una volta rilasciati, gli agenti agiscono in base alla configurazione e al contesto senza fermarsi per una revisione umana, eliminando un punto di controllo su cui il modello di sicurezza tradizionale faceva silenziosamente affidamento.

Il modello dei permessi non si è indebolito. Ciò che lo utilizza è diventato molto più scrupoloso.

Cosa fare prima del deployment

La soluzione non è diffidare di Agentforce, ma sapere cosa può vedere il suo utente prima di attivarlo:

1. Esegui una revisione degli accessi per l’utente con cui viene eseguito l’agente, a livello di oggetto e di record. La domanda rilevante è la stessa attorno alla quale ruota tutto questo blog: chi può vedere cosa, e perché. Per un manuale operativo passo passo, vedi come verificare l’accesso ai record prima di rilasciare un agente AI.
2. Restringi la baseline. Imposta gli org-wide default il più restrittivi possibile compatibilmente con il business; da lì l’accesso può solo allargarsi.
3. Sfoltisci regole di condivisione e permission set. Rimuovi le concessioni ampie e obsolete che altrimenti l’agente erediterebbe.
4. Dai all’agente una propria identità a privilegio minimo invece di un ampio profilo umano, oltre a policy basate sugli attributi.
5. Riverifica dopo ogni modifica alla condivisione: gli accessi vanno alla deriva, e così pure ciò che l’agente può raggiungere.

Sapere cosa può vedere l’agente — in parole semplici

I passaggi 1 e 5 sono quelli difficili: ricostruire l’accesso effettivo reale di un utente attraverso CRUD, field-level security e sei meccanismi di condivisione, per poi mantenerlo aggiornato man mano che l’org cambia.

È esattamente ciò che fa AgentForceAccess. Chiedi, in parole semplici, cosa può effettivamente vedere un utente — o l’utente con cui viene eseguito il tuo agente — e ne traccia ogni concessione citando il meccanismo che la determina. È la revisione degli accessi che trasforma il “pensiamo che l’agente sia configurato correttamente” in “sappiamo che lo è” prima del deployment.

Domande frequenti

Gli agenti Agentforce ignorano le regole di condivisione e vengono eseguiti come amministratore?

No. Un agente viene eseguito come uno specifico utente Salesforce ed è vincolato dal profilo, dai permission set, dalla field-level security e dal modello di condivisione dei record di quell'utente. Non può vedere record che quell'utente non potrebbe vedere. Se però l'utente con cui viene eseguito ha privilegi eccessivi, l'agente eredita quel privilegio eccessivo.

Allora perché l'accesso dell'AI è considerato un rischio per la sicurezza se rispetta i permessi?

Perché la maggior parte delle org ha accumulato più condivisione aperta di quanto chiunque immagini. Una persona raramente incappa in ogni record a cui tecnicamente può accedere; un agente li recupererà e li riassumerà volentieri su richiesta. L'agente non crea nuovi accessi: espone gli accessi che avevi già.

Qual è la cosa più importante da fare prima di rilasciare un agente?

Verifica cosa può effettivamente vedere l'utente con cui viene eseguito l'agente, oggetto per oggetto e a livello di record. Restringi gli org-wide default, le regole di condivisione e i permission set in modo che l'utente (e quindi l'agente) abbia solo gli accessi necessari, poi procedi al deployment.

Posso dare a un agente un accesso più ristretto rispetto all'utente che lo esegue?

Sì. Predisponi per l'agente un utente dedicato a privilegio minimo o una configurazione di permission set, invece di riutilizzare un ampio profilo umano, e aggiungi sopra policy basate sugli attributi. L'agente dovrebbe avere l'accesso minimo richiesto per il suo compito.