De quel accès votre assistant IA a-t-il vraiment besoin ?

Illustration éditoriale générée par IA : lire des informations et envoyer des messages nécessitent des autorisations distinctes.

Demander à l’IA d’organiser vos e-mails, de préparer vos réunions et d’assurer le suivi de votre travail paraît de plus en plus naturel. L’hésitation arrive au moment de cliquer sur Autoriser. Que peut-elle voir ? Que peut-elle faire à votre place ? Pouvez-vous reprendre cet accès ?

Une discussion récente a mis ces questions en lumière. Dans une interview publiée par Business Insider le 9 octobre, Shane Mac, PDG de XMTP Labs, a déclaré que son agent de finances personnelles avait publié un rapport sur le Slack de son entreprise. L’article est un récit édité, raconté à la première personne, et non un audit technique indépendant.

L’interview a été partagée sur r/technology de Reddit. Certains commentateurs s’opposaient au fait de confier des informations sensibles à l’IA ; d’autres se demandaient pourquoi des comptes personnels et professionnels étaient connectés. Leurs réactions soulèvent une préoccupation pratique : lorsqu’un assistant peut à la fois lire des informations et envoyer des messages, comment l’utilisateur contrôle-t-il la destination de ces informations ?

Le 12 octobre, la vidéo TikTok de CNA a également abordé la question de savoir si les utilisateurs accordent trop d’accès aux agents. Sa description porte sur la compréhension des autorisations accordées.

Ces sources ne montrent pas que chaque agent échouera. Elles montrent que les autorisations font partie du débat public sur les assistants personnels. Pour quiconque met l’IA au travail, l’accès doit suivre la tâche.

Organiser les e-mails et les envoyer nécessitent des autorisations différentes

Imaginez que vous demandiez à un assistant d’identifier chaque matin les e-mails nécessitant une réponse, d’en lister les points clés et de proposer des réponses.

Cela nécessite de rechercher et de lire les e-mails. Les réponses suggérées peuvent apparaître dans votre conversation pour relecture. L’envoi automatique de messages, leur suppression ou la modification des paramètres de transfert devraient être des décisions d’autorisation distinctes.

Ouvrir toutes les actions dès le départ donne à l’assistant plus de capacités que cette tâche n’en exige. Modifier ensuite son prompt ne change pas forcément l’accès réel du compte.

Commencez par trois questions :

• Que peut-il lire ? Quel compte, quelle période et quels documents ?
• Que peut-il faire ? Rechercher et lire uniquement, ou aussi envoyer, modifier et supprimer ?
• Qui reçoit le résultat ? Cette conversation, ou une destination personnelle précise ?

Traitez ces points séparément. L’autorisation de l’application source détermine les données accessibles. La couche de connexion peut restreindre les actions appelables. Le workflow de l’assistant doit encore définir les paramètres et les destinataires.

Configurez les trois couches séparément. Il s’agit de conseils de conception de tâche ; un seul interrupteur n’applique pas toutes les frontières.

Un accès en lecture seule nécessite aussi une destination claire

L’accès en lecture seule est un bon point de départ : organiser l’information, la faire relire par une personne, puis ajouter des actions progressivement.

La lecture fait aussi entrer l’information dans le contexte de traitement de l’assistant. Même s’il ne peut pas modifier les données sources, un autre outil capable d’envoyer des messages peut lui permettre de transporter cette information ailleurs.

Un brief matinal personnel peut d’abord rester dans votre conversation privée. Un brief d’équipe doit utiliser des sources et des destinations approuvées. Finances personnelles, emplois du temps familiaux et messages d’entreprise méritent des connexions et des canaux de sortie planifiés séparément.

Pour les workflows de messagerie, précisez le compte et le destinataire, utilisez si possible des identifiants de destination stables, et affichez le contenu final pour confirmation si nécessaire. Des noms de groupes, de contacts ou des libellés de compte similaires ne devraient pas être le seul critère de choix d’une destination.

Cela relève de la conception du workflow. L’autorisation d’appeler une action d’envoi de message ne détermine pas automatiquement si chaque contenu convient à chaque destinataire.

Donnez à l’assistant des capacités que vous pouvez expliquer

OOMOL vous permet d’appliquer ces décisions aux connexions de compte et à l’accès aux actions. Sa documentation sur le contrôle d’accès distingue l’autorisation du fournisseur, l’accès de la connexion et les actions autorisées.

Un assistant d’organisation d’e-mails peut utiliser une connexion limitée aux actions de recherche et de lecture. Lorsqu’il doit envoyer en votre nom, configurez cette capacité pour la tâche d’envoi. Un même compte peut avoir plusieurs connexions avec des portées d’actions et d’accès des membres différentes.

Les portées d’autorisation que vous pouvez sélectionner dépendent du service source. Les actions que vous pouvez restreindre dépendent des interfaces de la connexion actuelle. La visibilité sur des enregistrements individuels dépend encore des autorisations de l’application source et des paramètres de la requête.

Un détail utile : les restrictions d’actions personnalisées d’OOMOL désactivent le Proxy et le point d’entrée dynamique call_tool. Les appels restent alors dans les limites des actions explicitement autorisées, au lieu d’emprunter une autre voie généraliste au-delà de la liste sélectionnée. Vérifiez ce comportement en même temps que la configuration dans la documentation.

Les équipes qui doivent gérer leur propre service de connexion peuvent utiliser OpenConnector, la voie open source et auto-hébergée d’OOMOL. Elle permet aux équipes de gérer les identifiants de connexion, les politiques d’action et les enregistrements d’exécution dans leur propre environnement, en exposant les actions applicatives via des interfaces telles que MCP et HTTP. Le guide d’auto-hébergement couvre l’authentification à l’exécution, les actions autorisées et bloquées, ainsi que les enregistrements d’exécution expurgés.

Ces capacités aident à établir et à inspecter les frontières d’accès. Les données métier renvoyées à l’assistant doivent toujours être traitées comme des données sensibles. Les destinataires, les vérifications de contenu et la confirmation d’exécution doivent aussi être traités dans le workflow de l’assistant ou de l’application.

Commencez par une petite tâche utile

La première version peut simplement lire les réunions du jour et les e-mails associés, puis placer les éléments importants dans votre conversation privée.

Une fois qu’il sélectionne les bons comptes, trouve les bons documents et identifie ses sources, envisagez d’ajouter la création de tâches ou l’envoi de messages. Chaque action ajoutée doit avoir une tâche, un compte et une destination clairs.

Sachez quoi révoquer lorsque vous devez arrêter. Déconnecter un compte, révoquer les identifiants d’appel et annuler les tâches planifiées sont des points de contrôle différents. Ils ne suppriment pas automatiquement les informations déjà envoyées.

Pour commencer, configurez une connexion propre à la tâche dans OOMOL Connections, restreignez ses actions autorisées à l’aide du guide de contrôle d’accès, et donnez à votre assistant une demande claire :

Trouve les e-mails auxquels je dois faire attention aujourd’hui. Recherche et lecture uniquement ; n’envoie et ne supprime rien. Affiche les résultats dans cette conversation et conserve les liens vers les e-mails d’origine.

Lorsque les capacités correspondent à la tâche, l’autorisation devient plus facile à comprendre — et vous disposez d’une base plus claire pour en ajouter d’autres par la suite.