Contexte et enjeux
1Password décrit les agents d’intelligence artificielle comme des identités hybrides, capables de se connecter, de porter des identifiants et d’agir au nom d’un utilisateur. Cette dualité rend difficile l’attribution des actions dans les journaux d’audit, car une même entrée peut refléter une action humaine ou logicielle. Face à ce problème, Nancy Wang, CTO d’AgileBits (1Password), a présenté une approche où chaque agent doit justifier son identité et son autorisation avant d’exécuter une tâche précise.
Architecture de la vérification par tâche
Le modèle repose sur un accès « just‑in‑time » (JIT) : aucun privilège permanent n’est accordé aux agents, humains ou machines. L’accès est conditionné à la justification d’une tâche, similaire à la validation d’un stagiaire avant de passer à un nouveau projet. 1Password utilise un Credential Broker qui libère les secrets uniquement au moment où ils sont requis, sans jamais les exposer directement à l’agent ou au modèle d’IA sous‑jacent. Cette couche agit comme un intermédiaire cryptographique, transmettant les informations d’identification dans un format éphémère et limité dans le temps.
Par ailleurs, 1Password s’appuie sur les standards d’identité partagée d’Okta, permettant à l’identité vérifiée et au contexte d’autorisation de circuler entre les deux plateformes. Ainsi, lorsqu’un agent termine une tâche, le système enregistre le niveau de permission utilisé et exige une nouvelle validation avant d’autoriser la tâche suivante.
Analyse des impacts sécuritaires
Cette stratégie élimine le principe de privilège permanent, qui constitue une cible privilégiée dans les attaques classiques. En contraignant chaque action à une validation contextuelle, le risque de compromission massive diminue, car un agent compromis ne pourra exploiter que le périmètre strict de la tâche en cours. De plus, le fait que les secrets ne soient jamais stockés dans le modèle d’IA réduit la surface d’exposition aux fuites de clés ou de mots de passe.
Le positionnement de 1Password sur les « thin clients » et le déplacement du code vers des « remote sandboxes » renforce cette posture : les agents exécutent leurs fonctions dans des environnements isolés, limitant les effets collatéraux d’une éventuelle compromission. La centralisation du contrôle d’accès dans le cloud, comme le souligne Wang, facilite la mise à jour des politiques et la visibilité en temps réel sur les activités des agents.
Limites et perspectives
Le principal point d’interrogation réside dans les mécanismes exacts de vérification de tâche, qui ne sont pas détaillés publiquement. Sans indication sur les critères d’évaluation (par exemple, seuils de confiance, métriques d’audit ou durée de validité des jetons), il est difficile d’estimer la charge opérationnelle induite par ces contrôles répétés. De plus, la dépendance à Okta pour la propagation des contextes d’autorisation crée un point de concentration : une défaillance ou une mauvaise configuration d’Okta pourrait impacter l’ensemble du flux d’accès.
Enfin, la mise en œuvre d’un modèle JIT à grande échelle nécessite une orchestration fine entre les services de gestion des identités, les environnements d’exécution des agents et les systèmes de stockage des secrets. Les organisations devront donc investir dans des pipelines d’automatisation robustes pour éviter les goulots d’étranglement et garantir que la vérification par tâche ne devienne pas un obstacle à la productivité.