Blog

Vos agents IA vont bientot se parler. Qui verifie leurs identites?

L'interopérabilité entre agents est fixée, pas la gouvernance. Vérifiez l'identité externe à la source, auditez chaque contact, restez neutre cloud et modèle.

Quelque chose de discret mais significatif s’est produit dans le logiciel enterprise cette derniere annee. Les grands editeurs de plateforme - Microsoft, AWS, Google, Salesforce, SAP, ServiceNow - se sont accordes sur une facon commune pour que les agents IA communiquent entre eux. Les propositions concurrentes ont converge. En pratique, le standard est fixe.

En surface, c’est une bonne nouvelle. Cela signifie qu’un agent construit par la finance peut confier du travail a un agent des achats, qui peut a son tour joindre un agent heberge chez un fournisseur. Pas d’integration sur mesure pour chaque paire. Ils se decouvrent, echangent des taches et avancent.

Si vous gerez la securite ou la technologie dans votre organisation, ce dernier paragraphe devrait vous inquieter legerement. Non parce que la technologie est mauvaise - mais parce qu’elle repond a une question qui ne vous preoccupait pas tout en laissant une question bien plus grande entierement ouverte.

Operateur dans un centre d'operations reseau supervisant l'activite gouvernee des agents IA dans les systemes enterprise.

L’interoperabilite repond a “peuvent-ils parler”. Pas a “devraient-ils.”

Le nouveau standard est tres bon pour connecter les agents. Il ne dit presque rien sur la gouvernance. Quand des agents de differentes equipes, fournisseurs et clouds peuvent se joindre librement, quelqu’un doit pouvoir repondre a trois questions a tout moment:

  • Qui a le droit d’appeler qui?
  • Quelles donnees chaque agent peut-il toucher quand il le fait?
  • Qui a enregistre que cela s’est produit?

Ce ne sont pas des questions auxquelles le protocole repond. Ce sont des questions que vous repondez - ou pas. Et des l’instant ou vos agents peuvent depasser vos propres murs, “ou pas” devient une observation d’audit en attente.

Une version concrete du probleme

Voici le scenario qui rend cela reel, sans detail technique.

Un agent se presente a vos systemes comme l’agent d’un fournisseur de confiance. Il apporte des identifiants - des papiers, en pratique - qui disent “je suis celui que je pretends etre.” Vos agents sont configures pour faire confiance a ce fournisseur. Le nouvel agent peut donc participer: recevoir des taches, demander des donnees, agir.

La question qui decide si vous avez un programme de securite ou une responsabilite est simple: votre systeme verifie-t-il reellement que les papiers ont ete emis par le fournisseur - ou prend-il l’agent au mot?

Car une presentation falsifiee est facile. Un attaquant peut presenter un agent qui pretend etre votre fournisseur et fournir ses propres identifiants pour etayer la pretention. Un systeme naif verifie que les papiers sont coherents en interne, voit qu’ils le sont, et laisse passer l’agent. L’imposteur est desormais dans votre workflow, de confiance, agissant sur de vraies donnees.

Un systeme concu pour la gouvernance fait l’inverse. Il traite chaque agent externe comme non prouve jusqu’a ce que son identite soit verifiee contre la partie qu’il pretend representer - pas contre des identifiants que l’agent a lui-meme remis. L’agent reel du fournisseur entre. L’imposteur est arrete a la porte, et le rejet est consigne dans un journal que vous pouvez montrer a un auditeur.

Cette distinction - verifier l’identite contre la source revendiquee, pas contre la parole du demandeur - est toute la difference entre un reseau d’agents ouvert et une porte ouverte. Elle est peu glamour, invisible quand elle fonctionne, et c’est ce que la plupart des equipes n’ont pas encore construit.

”Ne pouvons-nous pas utiliser la plateforme d’agents de notre fournisseur cloud?”

Vous le pouvez. Plusieurs offrent desormais une gestion d’agents avec gouvernance attachee, et pour une organisation qui vit entierement dans un cloud et un modele IA, cela peut suffire.

La plupart n’y vivent pas ainsi. Vos agents tourneront dans plus d’un cloud. Ils seront construits avec plus d’un modele IA - parce que le meilleur modele pour une tache est rarement le meilleur pour la suivante, et parce que parier toute votre strategie d’agents sur un seul fournisseur IA est le type de dependance que vous regretterez le reste de votre carriere. Et de plus en plus, vos agents devront interagir avec des agents hors de votre organisation.

Une couche de gouvernance qui ne fonctionne qu’a l’interieur des murs d’un fournisseur ne voit rien de tout cela. Elle gouverne les agents heberges par ce fournisseur, sur son modele, et devient aveugle des qu’un agent sort. Ce n’est pas de la gouvernance - c’est une cloture autour d’un champ pendant que le troupeau erre sur trois autres.

La couche de gouvernance qui vous protege vraiment doit etre neutre: independante du cloud ou tourne l’agent, independante du modele IA sur lequel il est construit, et capable d’appliquer les memes controles d’identite, regles d’acces et piste d’audit a chaque agent quelle que soit son origine. La neutralite n’est pas une fonctionnalite ici. C’est la precondition pour que cela vaille la peine.

Ce n’est pas votre incendie aujourd’hui. Ca le sera bientot.

Soyez honnetes sur le timing. Si votre organisation a trois agents et qu’ils tournent tous au meme endroit, vous n’avez pas encore ce probleme. Quiconque dit que votre maison brule vend quelque chose.

Mais la direction n’est pas incertaine. Le standard est fixe, chaque grand editeur livre le support, et le nombre d’agents dans une entreprise typique ne va que dans un sens. Les equipes qui pensent identite, acces et audit avant la proliferation y consacrent un apres-midi. Celles qui attendent passent un trimestre a demeler, probablement apres qu’une erreur se produise.

La gouvernance coute dramatiquement moins cher a installer avant quarante agents qu’apres. C’est tout l’argument. Pas la peur - l’ordre.

Ce qu’il faut demander

Vous n’avez pas besoin de comprendre le protocole pour poser les bonnes questions a celui qui possede votre strategie d’agents:

  1. Quand un agent externe se presente a nos systemes, comment verifions-nous qu’il est ce qu’il pretend etre - et verifions-nous contre la source, ou faisons-nous confiance a ses propres identifiants?
  2. Si nous devions montrer a un auditeur chaque agent qui a touche un jeu de donnees donne, le pourrions-nous?
  3. Notre gouvernance d’agents fonctionne-t-elle entre nos clouds et nos modeles IA - ou seulement chez un fournisseur?
  4. Pouvons-nous repondre a tout ce qui precede aujourd’hui, ou seulement dans une presentation?

Si les reponses sont solides, vous etes en avance sur la plupart. Sinon, la bonne nouvelle est que le travail est bien plus petit maintenant que dans un an.

Les agents vont commencer a se parler de toute facon. Le seul choix est de savoir si quelqu’un verifie les identites a la porte.


Besoin d’une couche de gouvernance neutre pour les agents entre clouds, modeles et fournisseurs? Decrivez votre environnement dans le formulaire ci-dessous - nous parcourons identite, acces et audit sur votre propre architecture.

Nous contacter

Réservez une démo, contactez le support ou explorez les partenariats. Nous sommes là pour vous aider à construire, intégrer et automatiser plus vite.

Envoyez-nous un message

Remplissez le formulaire ci-dessous et nous vous répondrons sous 24 h.

Required fields are marked with *. Do not send passwords, card numbers, or other sensitive data through this form.