Auditer l'accès aux enregistrements avant de déployer un agent IA

Le meilleur moment pour découvrir que votre agent IA peut lire chaque fiche de salaire de l”organisation, c”est avant de le déployer — pas lorsqu”un utilisateur le lui demande. Parce qu”un agent Agentforce hérite de l”accès de l”utilisateur sous lequel il s”exécute, l”activer revient en réalité à décider d”exposer, par la conversation et à la vitesse de la machine, tout ce que cet utilisateur peut voir. Ce guide audite cet accès en premier.

Pourquoi cet audit compte davantage pour les agents que pour les humains

Un humain se heurte rarement à toute l”étendue de son accès : il ouvre les enregistrements sur lesquels il travaille et ignore le reste. Un agent, non. Posez-lui une question et il récupère, croise et synthétise tout ce qui est à sa portée. L”agent ne crée aucun nouvel accès ; il expose l”accès déjà présent — y compris celui que tout le monde avait oublié.

L”audit ne porte donc pas sur l”IA. Il s”agit de répondre à une vieille question avec une urgence nouvelle : que peut réellement voir cet utilisateur ?

Étape 1 — Identifier précisément l”identité d”exécution de l”agent

Déterminez exactement sous quel utilisateur (ou quelle configuration d”utilisateur) l”agent s”exécute. Tout ce que l”agent peut lire est défini par les permissions et les partages de cette identité. S”il réutilise un profil humain trop large, c”est déjà la trouvaille numéro un — voir l”étape 5.

Étape 2 — Auditer l”accès au niveau objet

Pour cette identité, examinez les permissions d”objet issues de son profil et de ses ensembles de permissions :

CRUD — quels objets peut-elle lire (Read), créer (Create), modifier (Edit), supprimer (Delete) ?
Sécurité au niveau des champs — quels champs sensibles sont visibles ?
View All / Modify All — l”une de ces permissions sur un objet (ou « View All Data ») contourne entièrement le modèle de partage et constitue la priorité absolue à repérer.

L”accès objet est le portail ; si l”agent n”a aucune raison métier de lire un objet, corrigez cela ici avant de vous soucier des enregistrements.

Étape 3 — Auditer l”accès au niveau enregistrement

Pour les objets qu”il peut lire, déterminez quels enregistrements il voit, à travers chaque mécanisme de partage :

Valeurs par défaut à l”échelle de l”organisation (OWD) — la base est-elle privée ou publique ? Une OWD publique signifie que l”agent voit tous les enregistrements de cet objet.
Hiérarchie des rôles — l”identité se situe-t-elle haut dans la hiérarchie, héritant de tous ceux qui se trouvent en dessous ?
Règles de partage — quelles règles basées sur la propriété et sur des critères l”incluent ?
Partages manuels — y a-t-il des octrois ponctuels ?
Partage implicite — l”accès aux comptes entraînant celui des enregistrements enfants, la couche que les audits oublient.

Le résultat recherché : voici l”ensemble réel des enregistrements que cet agent peut lire, et le mécanisme derrière chacun.

Étape 4 — Traquer les accès trop larges et obsolètes

Une fois le tableau en main, recherchez les octrois qui ne devraient pas être là :

Une OWD en lecture publique (Public Read) qui devrait être privée.
Des règles de partage basées sur des critères correspondant à bien plus que prévu.
Des ensembles de permissions avec « View All » laissé actif depuis un projet passé.
Des partages manuels censés être temporaires.

Chacun de ces éléments est quelque chose que l”agent exposerait autrement. Élaguez-les.

Étape 5 — Accorder à l”agent le moindre privilège

Ne réutilisez pas un profil humain trop large. Provisionnez une identité dédiée, au moindre privilège, cantonnée à la tâche de l”agent, et superposez-y des politiques basées sur les attributs pour des règles à granularité fine. L”agent doit disposer de l”accès minimal requis — rien dont il aurait hérité par accident.

Étape 6 — Réauditer à chaque changement

L”accès effectif dérive : une nouvelle règle de partage, un déplacement de rôle, un ajustement d”ensemble de permissions, et la portée de l”agent s”élargit discrètement. Relancez l”audit après toute modification de partage, et à intervalle régulier quoi qu”il arrive. « Correctement cantonné au lancement » n”est pas « correctement cantonné aujourd”hui ».

Transformer un audit de plusieurs jours en une simple question

Les étapes 2 à 6 sont la partie difficile : 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. Manuellement, c”est plusieurs jours de travail et facile à se tromper.

AgentForceAccess est conçu exactement pour cela. Demandez, en langage clair, ce que l”utilisateur d”exécution de l”agent peut réellement voir, et il retrace chaque octroi — permission d”objet, règle de partage, partage manuel ou implicite — en citant le mécanisme. Il transforme « nous pensons que l”agent est bien cantonné » en « nous savons qu”il l”est », avant le déploiement et après chaque changement.

Questions fréquentes

Pourquoi auditer l'accès avant de déployer un agent ?

Parce que l'agent exposera tout ce que son utilisateur peut atteindre, instantanément et à la demande. La plupart des organisations ont un partage plus ouvert que personne ne s'en souvient ; l'audit révèle donc l'accès latent que l'agent exposerait — avant qu'il ne le fasse.

Que doit réellement couvrir l'audit ?

Deux couches. Niveau objet : les permissions CRUD de l'utilisateur d'exécution et la sécurité au niveau des champs issues de son profil et de ses ensembles de permissions. Niveau enregistrement : quels enregistrements précis il voit via les valeurs par défaut de l'organisation, la hiérarchie des rôles, les règles de partage, les partages manuels et le partage implicite.

L'agent doit-il utiliser le compte d'un véritable employé ?

Non. Provisionnez une identité dédiée, au moindre privilège, cantonnée à la tâche de l'agent, plutôt que de réutiliser un profil humain trop large. L'agent doit disposer de l'accès minimal nécessaire et de rien dont il aurait hérité par accident.

À quelle fréquence faut-il réauditer ?

Après toute modification des valeurs par défaut de l'organisation, des règles de partage, de la hiérarchie des rôles, des profils ou des ensembles de permissions — et à intervalle régulier quoi qu'il arrive. L'accès effectif dérive avec le temps, et la portée de l'agent dérive avec lui.