Ressources

Donner aux agents IA l’accès à vos systèmes sans partager de mots de passe

Les agents IA ont besoin de clés d’API pour travailler, mais une clé dans un prompt peut fuiter. Voici comment un courtier d’identifiants permet à une IA d’utiliser un secret sans le voir.

Publié 3 min de lecture

Pour faire un vrai travail, un agent IA doit accéder à vos systèmes : la boutique en ligne, le logiciel de comptabilité, le CRM. Ces systèmes demandent une clé d’API ou un mot de passe. La solution rapide consiste à coller la clé dans les instructions de l’agent. C’est aussi comme cela que les clés fuitent.

Ce guide explique pourquoi les secrets n’ont rien à faire sous les yeux d’un modèle, et comment un courtier d’identifiants permet à une IA d’utiliser un identifiant sans jamais le voir.

Pourquoi une clé dans un prompt est une clé divulguée

Un modèle de langage traite tout ce qui se trouve dans son contexte comme du texte qu’il peut répéter. Une clé placée dans un prompt peut se retrouver :

  • dans la réponse du modèle, quand un utilisateur ou un document la demande ;
  • dans les journaux et l’historique des conversations, sur vos serveurs ou ceux d’un fournisseur ;
  • entre les mains d’un attaquant, par injection de prompt : des instructions cachées dans un e-mail, une page web ou un fichier que l’agent lit.

Dire au modèle « ne révèle jamais cette clé » ne sert à rien. Les instructions données à un modèle ne sont pas un contrôle de sécurité. Le seul secret sûr est celui que le modèle ne reçoit jamais.

Utiliser sans voir

La solution consiste à séparer le fait d’utiliser un identifiant du fait de le voir. Dans OrgKeep, les coffres ont un niveau d’accès appelé Utilisation. Un membre disposant de l’accès Utilisation, humain ou IA, peut envoyer une requête avec un identifiant, mais ne peut pas lire sa valeur.

Voici ce qui se passe quand un employé IA appelle un système :

  1. L’IA décide de récupérer les nouvelles commandes et appelle l’outil de la boutique avec une référence à l’entrée du coffre, pas avec la clé.
  2. Le courtier d’identifiants, sur le serveur, vérifie que cet employé IA dispose de l’accès Utilisation sur cette entrée.
  3. Le courtier insère la clé dans la requête sortante et l’envoie.
  4. La réponse revient à l’IA. La clé, jamais.

Comme l’IA ne détient jamais le secret, elle ne peut ni le répéter, ni le journaliser, ni être amenée par la ruse à l’envoyer ailleurs.

Donnez à chaque employé IA sa propre clé

Avec des identifiants partagés, impossible de savoir qui a fait quoi. Pour chaque employé IA, créez une clé d’API distincte dans le système externe, avec uniquement les permissions dont sa mission a besoin.

  • Moindre privilège. Une IA qui gère une boutique doit lire les commandes et mettre à jour le stock, pas supprimer des produits ni modifier les paramètres de paiement.
  • Révocable séparément. Si quelque chose semble anormal, révoquez une seule clé sans gêner personne d’autre.
  • Des journaux lisibles. Les propres journaux du système externe montrent exactement ce que cette IA a fait.

Gardez les permissions sur le serveur

Le courtier n’est qu’un élément d’une règle plus large : c’est le serveur qui décide de ce que chaque membre peut faire. Une IA peut demander à faire n’importe quoi ; la couche d’outils vérifie les permissions avant d’agir, avec la même vérification que pour les personnes. L’accès suit l’appartenance aux projets : un employé IA ajouté à un projet peut utiliser les identifiants de ce projet, et rien d’autre.

Ajoutez deux garde-fous de plus, et l’essentiel du risque est couvert :

  • Étapes réservées aux humains. Les paiements, les contrats et les déploiements en production s’arrêtent toujours pour une personne, quels que soient les réglages de l’IA.
  • Un seul journal d’audit. Chaque action est enregistrée au nom du membre qui l’a effectuée : vous pouvez ainsi retracer chaque modification jusqu’à un humain ou une IA.

Une liste de contrôle

  • Aucune clé d’API ni aucun mot de passe dans les prompts, les instructions ou les fichiers de compétences.
  • Des identifiants stockés dans un coffre, avec l’accès Utilisation pour les employés IA.
  • Une clé distincte, aux droits restreints, pour chaque employé IA.
  • Des vérifications de permissions dans le serveur, pas dans les instructions du modèle.
  • Une approbation humaine pour les paiements, les contrats et les déploiements.
  • Chaque action journalisée sous sa propre identité.

Consultez le glossaire pour des définitions courtes de ces termes, ou réservez une démo pour voir le coffre en action.

Questions fréquentes

Faut-il mettre des clés d’API dans le prompt d’un agent IA ?
Non. Tout ce qui figure dans un prompt peut être répété par le modèle, journalisé ou divulgué par injection de prompt. Gardez les clés sur le serveur et laissez un courtier d’identifiants les insérer dans les requêtes.
Qu’est-ce qu’un courtier d’identifiants ?
Un composant serveur qui ajoute un secret à une requête sortante pour le compte de l’IA. L’IA transmet une référence à l’identifiant, et le secret lui-même n’atteint jamais le modèle.
Qu’est-ce que l’accès Utilisation ?
Un niveau d’accès au coffre qui permet à un membre, humain ou IA, d’utiliser un identifiant sans voir sa valeur.

Voyez ce qu’OrgKeep ferait pour votre équipe.

Parlez-nous de votre organisation et nous vous montrerons des employés humains et IA qui travaillent ensemble.

Réserver une démo