Les agents Agentforce contournent-ils le partage Salesforce ?

Toute conversation sur la sécurité d’Agentforce commence par la même question : les agents contournent-ils nos règles de partage ? La réponse courte est non — et comprendre pourquoi explique à la fois en quoi Agentforce est sûr par conception et où se situe le véritable risque.

Les agents s’exécutent en tant qu’utilisateur — et héritent de l’accès de cet utilisateur

Un agent Agentforce ne dispose pas de sa propre vue magique sur vos données. Il s’exécute en tant qu’utilisateur Salesforce, et chaque récupération de données qu’il effectue est vérifiée par rapport aux éléments suivants de cet utilisateur :

Permissions d’objet (profil + ensembles d’autorisations)
Sécurité au niveau des champs
Partage au niveau des enregistrements — valeurs par défaut à l’échelle de l’organisation, hiérarchie des rôles, règles de partage, partages manuels et implicites

Si l’utilisateur d’exécution ne peut pas voir un enregistrement, l’agent ne le peut pas non plus. Agentforce fonctionne à l’intérieur du même modèle de sécurité d’entreprise — profils, ensembles d’autorisations, partage, accès basé sur les rôles — qui régit le reste de votre org. Il prend également en charge des politiques basées sur les attributs par-dessus, pour des règles comme « seuls les commerciaux de l’UE peuvent déclencher ce workflow ».

Les agents Agentforce ne contournent pas les permissions Salesforce. Ils exploitent avec zèle tout accès déjà existant.

Cette deuxième phrase résume tout.

Le véritable risque : une exposition amplifiée, pas un contournement

Voici la partie inconfortable. La plupart des orgs ont beaucoup plus de partage ouvert que quiconque ne se souvient en avoir configuré — des années de règles de partage, d’ensembles d’autorisations larges, de remontées par la hiérarchie des rôles et de partages manuels « temporaires » qui n’ont jamais été supprimés.

Un humain ne se heurte presque jamais à toute l’étendue de ce à quoi il a techniquement accès. Il ouvre les enregistrements sur lesquels il travaille et ignore le reste. Un agent, lui, ne le fait pas. Posez-lui une question et il récupérera, croisera et résumera tout ce qui se trouve à la portée de l’utilisateur d’exécution — y compris des données que cet utilisateur avait oublié pouvoir voir.

L’agent n’accorde donc pas de nouvel accès. Il met en lumière l’accès que vous aviez déjà, de manière conversationnelle, instantanément. Un partage trop large resté latent pendant des années n’est plus qu’à une phrase d’invite.

Pourquoi les agents changent l’équation du risque

Deux choses distinguent cela d’une personne dotée des mêmes permissions :

Vitesse et échelle. Un agent lit et combine des enregistrements bien plus vite que n’importe quel humain, de sorte qu’une permission mal délimitée est exploitée immédiatement et de façon répétée.
Aucun point de contrôle d’approbation. Une fois déployés, les agents agissent en fonction de la configuration et du contexte sans s’arrêter pour une revue humaine — supprimant un point de contrôle sur lequel le modèle de sécurité traditionnel s’appuyait discrètement.

Le modèle de permissions n’est pas devenu plus faible. C’est ce qui l’utilise qui est devenu bien plus exhaustif.

Que faire avant de déployer

La solution n’est pas de se méfier d’Agentforce — c’est de savoir ce que son utilisateur peut voir avant de l’activer :

Réalisez une revue des accès pour l’utilisateur d’exécution de l’agent — au niveau de l’objet et de l’enregistrement. La question pertinente est la même que celle au cœur de tout ce blog : qui peut voir quoi, et pourquoi. Pour un guide étape par étape, consultez auditer l’accès aux enregistrements avant de déployer un agent IA.
Resserrez la base de référence. Définissez les valeurs par défaut à l’échelle de l’organisation aussi restrictives que l’activité le permet ; l’accès ne fait que s’élargir à partir de là.
Élaguez les règles de partage et les ensembles d’autorisations. Supprimez les attributions larges et obsolètes dont l’agent hériterait autrement.
Donnez à l’agent sa propre identité au moindre privilège plutôt qu’un profil humain large, assortie de politiques basées sur les attributs.
Revérifiez après chaque modification de partage — l’accès dérive, tout comme ce que l’agent peut atteindre.

Savoir ce que l’agent peut voir — en langage clair

Les étapes 1 et 5 sont les plus difficiles : reconstituer l’accès effectif réel d’un utilisateur à travers le CRUD, la sécurité au niveau des champs et six mécanismes de partage, puis le maintenir à jour à mesure que l’org évolue.

C’est exactement ce que fait AgentForceAccess. Demandez, en langage clair, ce qu’un utilisateur — ou l’utilisateur d’exécution de votre agent — peut réellement voir, et il retrace chaque attribution en citant le mécanisme qui la sous-tend. C’est la revue des accès qui transforme « nous pensons que l’agent est correctement délimité » en « nous savons qu’il l’est » avant de déployer.

Questions fréquentes

Les agents Agentforce ignorent-ils les règles de partage et s'exécutent-ils en tant qu'administrateur ?

Non. Un agent s'exécute en tant qu'utilisateur Salesforce précis et est soumis au profil, aux ensembles d'autorisations, à la sécurité au niveau des champs et au modèle de partage d'enregistrements de cet utilisateur. Il ne peut pas voir des enregistrements que cet utilisateur ne pourrait pas voir. Si l'utilisateur d'exécution dispose toutefois de privilèges excessifs, l'agent hérite de ces privilèges excessifs.

Pourquoi l'accès de l'IA est-il alors considéré comme un risque de sécurité s'il respecte les permissions ?

Parce que la plupart des orgs ont accumulé plus de partage ouvert que quiconque ne l'imagine. Un humain tombe rarement sur chaque enregistrement auquel il a techniquement accès ; un agent, lui, se fera un plaisir de les récupérer et de les résumer sur demande. L'agent ne crée pas de nouvel accès — il expose l'accès que vous aviez déjà.

Quelle est la chose la plus importante à faire avant de déployer un agent ?

Auditez ce que l'utilisateur d'exécution de l'agent peut réellement voir — objet par objet, et au niveau de l'enregistrement. Resserrez les valeurs par défaut à l'échelle de l'organisation, les règles de partage et les ensembles d'autorisations afin que l'utilisateur (et donc l'agent) ne dispose que de l'accès dont il a besoin, puis déployez.

Puis-je accorder à un agent un accès plus restreint que celui de l'utilisateur qui l'exécute ?

Oui. Provisionnez un utilisateur dédié au moindre privilège ou une configuration d'ensemble d'autorisations spécifique à l'agent plutôt que de réutiliser un profil humain large, et superposez-y des politiques basées sur les attributs. L'agent ne devrait disposer que de l'accès minimal requis pour sa tâche.