Ce qu'il faut pour confier un vrai travail à un agent d'IA

La plupart des produits de sécurité pour l'IA partent d'une liste de menaces et ajoutent une fonction pour chacune. Les listes de menaces s'allongent chaque mois, si bien qu'un produit construit ainsi a toujours un temps de retard. Il existe un point de départ plus solide : l'agent lui-même, ce qu'il est, et ce qui devrait être vrai pour qu'une entreprise puisse lui confier un vrai travail.

Un agent lit, décide et agit. Il envoie l'e-mail, met à jour la fiche, appelle le service de paiement, avec les identifiants que votre entreprise lui a donnés.

Le risque d'un agent ne tient donc pas à ce qu'il dit. Il tient à ce qu'il peut atteindre, à la vitesse à laquelle il agit, et au temps qu'il faut pour que quelqu'un remarque qu'un problème survient.

Cette seule observation écarte beaucoup de choses. Un filtre qui ne lit que ce qu'une personne tape dans une fenêtre de discussion manque la partie qui compte : ce que l'agent fait ensuite.

Aucun outil ne peut lire le but derrière une action. Ce qui peut être lu, de façon fiable et à chaque fois, c'est l'action elle-même : l'outil appelé et avec quels arguments, la destination d'une requête sortante, le contenu d'un appel à un modèle.

Excubitor contrôle donc au point d'action.

Dans l'application, ou dans une passerelle placée devant les serveurs d'outils, chaque appel est contrôlé avant de s'exécuter : par rapport à la politique de l'agent, par rapport aux destinations autorisées par l'entreprise, et à la recherche d'instructions cachées dans ce que l'agent a reçu. Les contrôles sont déterministes et rapides, car un contrôle qui ajoute des secondes à chaque action ne reste pas activé.

Il en découle que le contenu lu par un agent n'est pas digne de confiance. Un document, un e-mail ou la réponse d'un outil peuvent contenir des instructions écrites par quelqu'un d'autre. Excubitor le traite ainsi : un outil dont la description cache une instruction est retiré de la liste de l'agent, et une réponse qui en contient une est retenue avant que l'agent ne la lise.

Si un agent peut agir seul, quelqu'un doit pouvoir l'arrêter seul, et cet arrêt ne peut pas dépendre de l'accord de l'agent.

Dans Excubitor, une exécution qui tourne en boucle ou s'emballe est contenue par une règle. N'importe quel membre de l'équipe peut geler un agent, et son appel suivant est refusé. Le libérer demande un administrateur et une note. Tout ce qui ne peut pas être annulé, comme un paiement ou une suppression, attend l'approbation d'une personne nommée. L'arrêt n'est automatique que là où il est réversible.

Après un incident, ou devant un auditeur, la question est de savoir ce qui s'est passé. Un journal que les personnes concernées auraient pu modifier ne répond à rien.

Chaque action entre donc dans un registre où chaque enregistrement est chaîné au précédent, et la chaîne est signée toutes les heures.

Sur notre service hébergé, chaque enregistrement est accompagné d'une courte preuve que n'importe qui peut contrôler hors ligne avec notre clé publique, sans accès à la console et sans nous faire confiance. Les enregistrements conservent les empreintes de ce qui a été envoyé et reçu, jamais le contenu lui-même, pour que le registre de sécurité ne devienne pas une seconde copie des données de l'entreprise.

Géré avec des preuves, jamais sur parole.

Certaines entreprises peuvent envoyer des enregistrements à un service hébergé. D'autres ne peuvent rien laisser sortir de leur propre cloud, et certaines exploitent des réseaux totalement fermés. Un contrôle qui ne fonctionne que dans le cloud du fournisseur est un contrôle que ces entreprises ne peuvent pas utiliser.

Excubitor fonctionne en mode hébergé, dans le cloud du client ou en environnement totalement isolé, à partir d'un paquet signé contrôlé avant installation.

Aucun accès permanent du fournisseur, jamais.

Reste une question : que se passe-t-il quand le contrôle lui-même ne peut pas s'exécuter. Un outil de sécurité doit alors choisir entre arrêter l'activité et laisser le travail continuer.

Par défaut, Excubitor laisse l'agent poursuivre et enregistre la lacune, pour que la panne d'un outil de sécurité ne soit jamais la panne de l'entreprise.

Une équipe qui préfère s'arrêter peut le configurer pour échouer en mode fermé.

Ce que tout cela donne

Ensemble, ces constats décrivent le produit :

• Un contrôle au point d'action : appels d'outils, connexions sortantes et appels au modèle, contrôlés avant d'avoir lieu.
• Un arrêt sans coopération : confinement par règle, gel par une personne, actions irréversibles retenues jusqu'à approbation.
• Des preuves qui ne reposent pas sur la confiance : un registre chaîné et signé, avec des preuves par enregistrement sur notre service hébergé.
• Un déploiement là où sont les données : hébergé, dans le cloud du client ou isolé.
• Des défaillances qui n'arrêtent pas l'activité : la lacune est enregistrée, le travail continue, sauf si le client en décide autrement.

Ce qu'il ne fait pas

Le même raisonnement fixe les limites. Excubitor enregistre ce qu'un agent a fait et ne prétend jamais juger ce que l'agent voulait faire. Ses contrôles détectent les schémas qu'ils connaissent ; un attaquant assez patient pour rester dans un comportement normal ne déclenchera pas de seuil en temps réel, et c'est pourquoi chaque agent est aussi comparé à son propre comportement habituel dans la durée. Enfin, il fonctionne dans l'application : il s'associe à la politique réseau, il ne la remplace pas.

Si vous cherchez à savoir si votre entreprise peut confier un vrai travail à des agents d'IA, partez de l'agent, pas de la liste des menaces. Nous serons heureux de vous montrer comment Excubitor se comporte sur un agent de votre propre entreprise.