Accès aux données et autorisations

Le modèle de sécurité Salesforce dans REDA AI

Les accès des outils intégrés reposent sur les contrôles Salesforce suivants :

• Sécurité au niveau des champs (FLS) : l’agent ne lit ou ne modifie que les champs autorisés à l’utilisateur, sauf exception API explicitement configurée.
• Autorisations d’objet : l’agent travaille uniquement sur les objets accessibles, sauf cette même exception API.
• Partage des enregistrements : l’agent accède uniquement aux enregistrements visibles par l’utilisateur.
• Hiérarchie des rôles : les responsables accèdent aux données de leurs subordonnés selon les règles applicables.
• Groupes publics et équipes : les accès accordés par ces mécanismes sont respectés.

Les outils intégrés REDA AI n’élargissent pas le partage. Sur chaque canal, leur accès aux enregistrements suit celui de l’utilisateur d’exécution.

Il existe une exception volontaire, limitée aux autorisations d’objet et de champ : un agent dont Contexte d'exécution vaut Système et dont le canal est API peut accéder à davantage de champs. Les deux conditions sont nécessaires ; cette combinaison ne peut pas être enregistrée sur les autres canaux. Le partage n’est jamais élargi : l’agent obtient davantage de colonnes sur des enregistrements déjà accessibles, pas de nouveaux enregistrements. Consultez Sécurité des données.

Ensembles d’autorisations REDA AI

REDA AI fournit plusieurs ensembles pour contrôler les accès :

Attribuez les ensembles adaptés aux rôles et au type d’accès. Un utilisateur doit disposer des autorisations requises pour interagir avec les agents.

Sécurité selon le canal

Canal interne

Les utilisateurs sont authentifiés dans Salesforce. L’agent agit pour l’utilisateur connecté :

• Sa FLS s’applique aux champs lus et modifiés.
• Ses autorisations d’objet déterminent les objets accessibles.
• Ses règles de partage déterminent les enregistrements accessibles en lecture et modification.
• Par exemple, l’agent d’un conseiller d’assistance ne peut accéder qu’aux requêtes et contacts visibles par ce conseiller.

Canal communauté

Les utilisateurs du portail accèdent à l’agent via leur session Experience Cloud. Les accès dépendent de leur identité authentifiée, de leur profil et des droits accordés :

• La FLS de l’utilisateur du portail s’applique.
• Ses autorisations d’objet s’appliquent.
• La visibilité est généralement limitée à ses propres données, comme le compte, les requêtes et contacts autorisés.
• Les paramètres de partage, le profil et la configuration du portail délimitent les données visibles.

Canal widget externe

Les visiteurs utilisent l’agent sans session Salesforce personnelle. Les accès reposent sur le profil invité du site configuré :

• La FLS du profil invité s’applique et doit rester restrictive.
• Ses autorisations d’objet sont généralement très limitées.
• L’accès invité porte normalement sur des données publiées ou explicitement partagées au public.
• Rendez accessibles uniquement les outils adaptés à des visiteurs non authentifiés.

Canal API

Un agent API est appelé par un autre système ou une automatisation. Il utilise l’identité d’exécution du processus, souvent un utilisateur d’intégration ou d’automatisation, qui doit être vérifiée pour le flux ou l’appel concerné. Ses autorisations de partage, d’objet et de champ s’appliquent, sauf si Contexte d'exécution vaut Système. Cette option est possible uniquement sur API et élève l’accès aux objets et champs, jamais le partage. Choisissez-la explicitement en connaissance de cause.

Un agent pouvant décider quelles données consulter selon le contexte, il peut être difficile d’anticiper tous les objets et champs nécessaires. Une configuration peut réussir en test puis rencontrer un refus sur un cas non prévu. Examinez ces refus avant de choisir les autorisations de l’utilisateur d’exécution.

Contexte d’exécution

Contexte d'exécution dans la définition de l’agent possède deux valeurs :

• Utilisateur, par défaut : les outils appliquent les autorisations d’objet et de champ de l’utilisateur d’exécution.
• Système : les outils intégrés n’imposent plus ces autorisations d’objet et de champ. Cette valeur est réservée au canal API ; la validation empêche de l’enregistrer sur un autre canal, et les protections d’exécution maintiennent les autres canaux en mode utilisateur.

Trois contrôles encadrent cette option :

Conservez Contexte d'exécution sur Utilisateur sauf besoin explicite d’un agent API autonome rencontrant des refus d’accès. Ce n’est pas un réglage de performance. Privilégiez l’attribution des droits nécessaires à l’utilisateur d’intégration ; envisagez Système seulement lorsque le périmètre ne peut pas être défini à l’avance et que l’élévation est maîtrisée.

La FLS en pratique

Exemple de sécurité au niveau des champs :

Exemple de partage

Exemple de règles de partage :

Widget externe : sécuriser le profil invité

Les visiteurs du widget externe ne sont pas authentifiés individuellement dans Salesforce. Configurez cet accès avec soin :

• Profil invité restrictif : accordez le minimum d’autorisations.
• FLS vérifiée : exposez uniquement les champs destinés au public, sans données confidentielles.
• Outils limités : privilégiez la lecture seule ; n’autorisez une création que pour un parcours explicitement défini et contrôlé.
• Tests réels en mode invité : utilisez une fenêtre privée et vérifiez les restrictions effectives.

Selon la configuration, un agent public d’assistance peut proposer :

• La recherche d’articles de connaissance publics, en lecture seule.
• La création d’une demande d’assistance avec un outil et des champs strictement limités.
• Pour consulter des requêtes personnelles, un parcours authentifié et correctement partagé, par exemple le portail de communauté ; une simple identité déclarée dans le chat ne suffit pas à sécuriser les données d’un visiteur.

Il ne doit PAS permettre de :

• Consulter les requêtes d’autres clients
• Accéder aux données du personnel
• Modifier les tarifs ou la configuration

Bonnes pratiques de déploiement

Vérifiez la FLS avant le déploiement : avant d’ajouter un champ au contexte, examinez les droits des utilisateurs concernés et le comportement en mode strict ou dégradé.

Choisissez les outils d’écriture avec soin : create_record, update_record, delete_record et send_email ne doivent être disponibles que pour des parcours qui les nécessitent. Les widgets externes ont rarement besoin d’écrire.

Testez avec plusieurs utilisateurs : vérifiez le comportement avec :

• Un utilisateur standard disposant des autorisations de base
• Un utilisateur restreint, sans accès à certains objets
• Un utilisateur invité pour le widget externe

Confirmez que chacun voit uniquement les données auxquelles il est autorisé à accéder.

Surveillez les appels d’outils : examinez les outils utilisés et leurs utilisateurs. Analysez les comportements inattendus.

Questions de sécurité courantes

Connecter les agents via MCP

MCP relie un assistant approuvé à des agents actifs sélectionnés du canal Interne. Chaque personne s’authentifie avec son identité Salesforce. Le client reçoit des points d’entrée d’agents ; les outils et prompts REDA ne sont pas publiés individuellement comme outils MCP. Configurez un Site, une application cliente externe, les attributions REDA AI User et REDA AI MCP User et l’activation de l’agent. Consultez le guide administrateur et le guide utilisateur. Les données peuvent être traitées par l’assistant et les fournisseurs configurés en plus de Salesforce. Examinez données et accords ; cela ne signifie pas qu’elles ne quittent jamais Salesforce.

Questions fréquentes

Prochaines étapes

Consultez la configuration du canal interne pour votre équipe, ou le déploiement du widget externe pour les visiteurs du site.