La réponse courte
Le modèle de responsabilité partagée n'est pas qu'un simple document formel ; il définit clairement qui est responsable en cas de problème. La règle est simple : la plateforme est responsable de la sécurité du service lui-même, tandis que l'organisation est responsable de toutes les décisions concernant ce que l'agent voit, ce qu'il est autorisé à faire et à qui il s'adresse.
Le risque majeur ne réside pas dans une intrusion dans la plateforme. Il provient plutôt d'un agent disposant de trop de privilèges qui divulgue des informations à une partie non autorisée ou qui exécute une action non prévue, deux types d'échecs entièrement imputables à l'organisation.
Répartition réelle des responsabilités
| Domaine | Responsabilité de la Plateforme | Responsabilité de l'Organisation |
|---|---|---|
| Infrastructure | Chiffrement, isolation, disponibilité, gestion des vulnérabilités | Choix de l'environnement et configuration du réseau approuvés |
| Données | Stockage et traitement conformément à l'accord | Ce qui est indexé et ce qui est classé comme sensible |
| Identité et autorisations | Mécanismes d'autorisation de la plateforme | Définition de qui peut voir et faire quoi |
| Comportement de l'agent | Capacités du modèle et outils de contrôle | Instructions, limites, points d'approbation |
| Actions | Infrastructure d'exécution | Autorisation pour chaque Action et validation interne |
| Surveillance et audit | Journaux de la plateforme | Piste d'audit métier, échantillonnage et examen |
Les nouveaux risques absents des CRM traditionnels
Le premier risque est la divulgation d'informations via la récupération (retrieval). Dans un système classique, l'utilisateur voit ce qui est affiché à l'écran ; avec un agent, du texte libre peut conduire à la récupération d'un fragment de document qui ne lui était pas destiné. Par conséquent, la récupération doit impérativement s'exécuter dans le contexte des autorisations de l'utilisateur, et non dans le contexte d'un compte d'intégration étendu.
Le deuxième est l'injection de prompt (Prompt Injection). Le contenu lu par l'agent (un e-mail client, un champ de description, un document joint) peut comporter des instructions visant à modifier son comportement. Il est impossible de s'en prémunir par la seule formulation ; la protection doit être architecturale.
Le troisième est la fuite de contenu interne vers un canal externe. Un article rédigé pour les représentants, contenant des marges de réduction ou des formulations de refus, ne doit pas atteindre le client. La séparation doit s'opérer par une liste blanche (whitelist) et non par une liste noire (blacklist).
Le quatrième risque est l'escalade silencieuse des privilèges : l'ajout d'une Action ou d'une autorisation pour résoudre un problème ponctuel, sans suivre le processus d'approbation habituel.
Les cinq contrôles les plus déterminants
Récupération de données dans le contexte de l'utilisateur. C'est le seul contrôle qui, s'il est compromis, rend tous les autres inefficaces.
Autorisation séparée pour chaque Action, selon le principe du moindre privilège. Un agent doté d'un profil générique et étendu anéantit toute possibilité de contrôle futur.
Validation interne à l'opération plutôt que dans les instructions. Une instruction est une intention ; une validation est un contrôle. Une opération qui exécute un remboursement doit vérifier le montant, l’éligibilité et l’autorisation dans son propre code, même si les instructions indiquent à l'agent de ne pas l'activer dans certains cas.
Approbation humaine pour toute action irréversible. Ce contrôle transforme un échec potentiel en un événement stoppé à temps.
Une piste d'audit qui lie l'utilisateur, l'action, la source et l'approbateur. Sans cela, il n'y a pas de réponse à la question d'audit : « Sur quelle base l'agent a-t-il effectué cette action ? »
Les principes généraux du modèle d'autorisations Salesforce sont détaillés dans le modèle d'autorisations Salesforce.
Que vérifier avant la mise en production (Go Live)
Tests de Persona : Dix à vingt questions identiques sont exécutées sous différentes identités (représentant, manager, utilisateur restreint, client externe) et les réponses sont comparées. Tout écart non justifié par une permission constitue une anomalie.
Red Teaming de contenu : Tentatives délibérées d'extraire des informations non autorisées, d'activer des actions interdites et de contourner les procédures d'escalade. Les scénarios sont écrits une fois et conservés pour être réexécutés à chaque nouvelle version.
Vérification du parcours des actions : Pour chaque Action, il est vérifié que la validation fonctionne même lorsqu'elle est déclenchée directement, et pas uniquement via l'agent.
Vérification de la rétention des données : Quoi est conservé, pendant combien de temps, et qui peut accéder aux journaux contenant le contenu des conversations avec les données client.
L'intégration de ces tests dans un cadre de test plus large est expliquée dans Tests Agentforce.
Cas d'étude : une anomalie détectée lors d'un test de Persona
Une entreprise de santé avait développé un agent interne pour répondre aux questions relatives aux procédures. Lors des tests de Persona avant le déploiement, il a été constaté qu'un utilisateur occupant un rôle administratif obtenait une réponse basée sur une procédure classifiée pour le personnel médical uniquement.
La cause n'était pas un bug dans l'agent. L'index avait été construit par un compte d'intégration avec un accès étendu, et la récupération ne restreignait pas les résultats en fonction des permissions de l'utilisateur. La même exposition potentielle existait pour toute question liée à ce domaine.
La correction a consisté en deux points : le déplacement de la récupération dans le contexte de l'utilisateur, et le marquage explicite des documents classifiés afin qu'ils ne soient pas inclus dans l'index général. Ce test a été ajouté comme scénario permanent, exécuté avant chaque nouvelle version.
Risques et actions préventives
| Risque | Comment il est détecté | Action préventive |
|---|---|---|
| Récupération avec permissions larges | Divulgation d'un document classifié dans une réponse innocente | Récupération dans le contexte de l'utilisateur et tests de Persona |
| Injection d'invite (Prompt Injection) | Action déclenchée suite à un contenu externe | Permissions réduites, validation dans l'action, approbation humaine |
| Mélange de contenu interne et externe | Une formulation interne parvient à un client | Liste blanche (whitelist) pour le contenu sur les canaux externes |
| Augmentation silencieuse de l'autorité | L'agent fait plus que ce qui a été approuvé | Étiquetage des modifications importantes et nouvelle approbation |
| Absence de piste d'audit | Pas de réponse pour l'audit | Enregistrement de l'utilisateur, de l'action, de la source et de l'approbateur |
Indicateurs de sécurité
| Indicateur | Ce qu'il révèle | Fréquence |
|---|---|---|
| Résultats des tests Persona | Écarts d'autorisation dans la récupération | À chaque version |
| Résultats du Red Teaming | Résilience face aux tentatives de contournement | À chaque version |
| Actions sensibles sans approbation | Lacunes dans le chemin de contrôle | Mensuel |
| Modifications ayant contourné l'approbation | Discipline du processus de modification | Trimestriel |
| Couverture de la piste d'audit | Pourcentage des actions sensibles entièrement documentées | Trimestriel |
Le cadre des certifications dans lequel les contrôles sont appliqués est détaillé dans Gouvernance de l'IA pour Agentforce.
Lorsque vous avez besoin d'un accompagnement pour définir le modèle de responsabilité et les tests avant le déploiement, le service Agentforce et IA est la voie pratique à suivre.
Checklist de sécurité avant la mise en production (Go Live)
- ☐ Le document de répartition des responsabilités est rédigé et approuvé.
- ☐ Les conditions d'utilisation des données avec le modèle sont documentées par écrit.
- ☐ La récupération (retrieval) s'exécute dans le contexte des autorisations de l'utilisateur.
- ☐ Des tests Persona ont été effectués pour chaque niveau d'autorisation.
- ☐ Chaque Action dispose d'une autorisation distincte et d'une validation interne.
- ☐ Les actions irréversibles nécessitent une approbation humaine.
- ☐ Un canal externe utilise une liste blanche (whitelist) pour le contenu.
- ☐ Des scénarios de Red Teaming de contenu ont été rédigés et exécutés.
- ☐ La piste d'audit relie l'utilisateur, l'action, la source et l'approbateur.
- ☐ La politique de conservation des journaux et du contenu des conversations est approuvée.