Michael JohnsonLe 7 octobre 2026, Apollo GraphQL a présenté GraphOS Agent Services, une version préliminaire d’un service de gestion de l’accès des agents IA aux API d’entreprise. Les administrateurs peuvent autoriser, masquer ou bloquer des champs de données individuels. La mise en place se fait avec l’aide d’Apollo.
Ce qu’Apollo a présenté
Selon la description de l’entreprise, Agent Services s’intercale entre l’agent et les systèmes internes : il transforme les requêtes en appels API, gère les identifiants et applique des restrictions. Apollo met en avant quatre fonctions : la découverte des données et des outils, la gestion des identités, les politiques d’accès et l’audit. Elles sont répertoriées dans l’annonce officielle du service.
Le communiqué d’Apollo diffusé sur PR Newswire a été publié le 7 octobre à 12 h 02, heure de l’Est des États-Unis, soit à 19 h 02 à Moscou. Il s’agit de l’heure de publication du communiqué ; l’heure exacte à laquelle l’accès a été ouvert n’est pas indiquée séparément.
Pourquoi limiter l’accès d’un agent
Le cas d’usage pratique présenté par Apollo consiste à faire travailler un même agent avec différents employés. Dans l’exemple publié sur le blog de l’entreprise, un employé du support et un analyste financier demandent des informations sur une facture contestée. Tous deux obtiennent la facture, mais seul l’analyste peut consulter le plafond de crédit du client. La différence repose sur la classification du champ et la politique d’accès.
Cette approche est utile aux équipes qui connectent des agents aux services internes liés à la clientèle, aux finances ou à d’autres domaines : les autorisations peuvent être définies pour des données précises et tenir compte de la personne qui a confié la tâche à l’agent. Apollo signale également un projet pilote chez Intuit. GraphOS, dans sa version classique, y est déjà utilisé en production, tandis que le nouvel Agent Services est en phase de test préliminaire. L’entreprise associe ce projet pilote à l’analyse des dépenses marketing ; l’annonce ne fournit aucun résultat chiffré en matière d’économies.
Fonctionnement des règles
Selon la documentation sur les règles d’accès, une règle définit l’utilisateur ou le groupe, l’application appelante, les données protégées et le résultat du contrôle. Les champs sont classés à l’aide de tags ; une règle peut s’appliquer à un tag ou à un service. Trois effets sont prévus : renvoyer la valeur, en masquer le contenu ou en interdire l’accès.
Plusieurs options sont prévues pour l’interdiction : retirer complètement le champ de la réponse, renvoyer une erreur ou permettre de demander un accès supplémentaire. Si un champ comporte plusieurs tags, l’effet le plus strict prévaut : l’interdiction l’emporte sur le masquage, et le masquage sur l’autorisation.
Un point important de la configuration : Apollo avertit dans le guide destiné aux administrateurs que le service ne vérifie pas encore l’identifiant de l’utilisateur ou du groupe auprès du fournisseur d’identité. Une faute de frappe fait que la règle ne correspond silencieusement plus aux requêtes. La vérification du résultat effectif pour chaque rôle devrait donc faire partie du projet pilote.
Selon la description de l’architecture d’Apollo, la décision d’accès est prise par le moteur de politiques, sans intervention d’un modèle de langage. Apollo précise également qu’un champ dépourvu de tag de classification reste sans restriction. Toutefois, la présentation de la documentation recommande d’interdire les champs du service connecté avant d’accorder des autorisations. Ces formulations doivent être vérifiées dans la configuration concernée : l’équipe devrait tester séparément l’accès aux champs avec et sans tag.
Audit et disponibilité
Le guide de Monitor décrit un journal des requêtes comprenant l’heure de l’appel, le client, l’outil, l’opération, le service concerné et le résultat de l’application des règles. Pour une requête donnée, il est possible de voir quelles règles ont été appliquées et quels champs ont été masqués ou interdits.
Une limite importante de l’audit : le panneau de visualisation des réponses affiche leur structure et les champs modifiés, mais pas les valeurs renvoyées par le service d’origine. La vérification du contenu précis des réponses doit être prévue séparément. L’export CSV couvre les requêtes chargées sur la page actuelle du journal.
Les sources ne s’accordent pas sur le stade de disponibilité. Dans son article du 7 octobre, Apollo annonce une préversion publique et propose une liste d’attente. La documentation du service parle d’une préversion privée et indique que la mise en place nécessite l’aide d’un membre du personnel d’Apollo. Cette page n’indique pas sa date de mise à jour ; il est donc impossible d’établir l’ordre d’apparition de ces formulations.
Pour l’instant, la démarche pratique consiste à convenir d’un projet pilote avec Apollo. Les documents consultés n’indiquent ni calendrier de sortie de la version stable ni tarif d’Agent Services. Avant la mise en place, l’équipe devrait définir les champs accessibles à l’agent, les responsables des autorisations et les requêtes de test pour chaque rôle.