Google permet aux développeurs de bloquer les appels d’outils des agents Gemini

Google a ajouté une couche de contrôle aux agents gérés dans son API Gemini, permettant aux développeurs d’exécuter leur propre code avant et après chaque appel d’outil qu’un agent effectue à l’intérieur de son sandbox cloud, et d’annuler l’appel purement et simplement. La même mise à jour fait de Gemini 3.6 Flash le modèle par défaut derrière l’agent, limite le nombre de jetons que une seule exécution peut consommer, et ouvre la fonctionnalité aux projets sans facturation associée.

Les agents gérés sont la version hébergée par Google de la boucle d’agent, le même modèle derrière les assistants qui sont maintenant connectés pour exécuter des tâches plutôt que de répondre à des questions. Un appel d’API configure un sandbox Linux, et le modèle planifie ensuite, exécute du code, installe des packages, lit et écrit des fichiers, et récupère des pages Web jusqu’à ce que la tâche soit terminée. Cette architecture est ce qui a rendu la nouvelle fonctionnalité nécessaire : le sandbox était un endroit où les développeurs pouvaient envoyer du travail, mais qu’ils ne pouvaient pas contrôler de l’intérieur.

Les hooks d’environnement changent cela. Un fichier hooks.json monté dans le sandbox enregistre des gestionnaires contre deux moments de la boucle, avant qu’un outil ne s’exécute et après qu’il ait terminé. Chaque règle correspond aux noms d’outils par expression régulière, de sorte qu’une entrée peut couvrir à la fois l’exécution de code et les écritures de fichiers, ou intercepter chaque appel. Lorsqu’un gestionnaire de pré-exécution retourne un refus, le runtime saute l’appel d’outil et passe la raison indiquée au contexte du modèle, où l’agent peut choisir une autre voie ou expliquer le bloc à l’utilisateur dans le même tour.

Ce que les hooks atteignent

Les hooks sont déclenchés sur les outils que Google exécute à l’intérieur du conteneur : l’exécution de code, ainsi que les opérations de système de fichiers qui lisent, écrivent, listent et suppriment des fichiers. Les fonctions personnalisées que le développeur exécute sur le client et les serveurs de protocole de contexte de modèle à distance s’exécutent en dehors du conteneur, de sorte que les hooks ne les interceptent pas.

Les échecs se résolvent en faveur de la permission. Si un script de hook se termine par une erreur, se bloque, retourne une erreur de serveur ou émet du JSON que le runtime ne reconnaît pas, l’appel d’outil se poursuit. La documentation de Google donne la raison : un linter cassé ou un serveur de télémétrie inaccessible ne devraient jamais être en mesure de bloquer une application de production.

Le deuxième type de gestionnaire envoie l’événement directement à un point de terminaison externe à partir du réseau du sandbox, ce qui est la façon dont fonctionne la journalisation d’audit. Ces requêtes passent par le proxy de sortie de Google, de sorte que la destination doit figurer sur la liste d’autorisation de l’environnement, et les jetons d’authentification vivent dans la configuration du réseau plutôt que dans le fichier de hook, avec le proxy qui injecte des en-têtes réels sur le fil. Google note également qu’un agent qui détient un accès shell ou d’écriture peut modifier un fichier de hook dans un espace de travail modifiable, et oriente les développeurs qui ont besoin d’une résistance aux falsifications vers le montage de cette configuration à partir d’un référentiel en lecture seule.

La surveillance de ce qu’un agent est autorisé à faire attire de l’argent de venture. Google met la vérification à l’intérieur de son propre runtime.

Les pipelines de vérification sont la première utilisation à laquelle il a donné un nom de client. Alston Lin, fondateur et directeur technique de la banque d’investissement native AI OffDeal, a déclaré qu’un hook de post-exécution exécute désormais la pipeline de vérification d’images de son entreprise au moment où son agent d’analyste écrit la liste d’une entreprise, en faisant respecter des règles de qualité au niveau du pixel sur les dizaines de logos dont un deck prêt pour un banquier a besoin. “Avant les hooks d’agent, nous ne pouvions pas faire cela sur les agents gérés de Gemini : le sandbox est distant, donc notre code de validation n’avait nulle part où s’exécuter”, a-t-il déclaré.

Gemini 3.6 Flash prend la relève en tant que modèle par défaut

L’agent géré exécute Gemini 3.6 Flash sans aucun changement de code, en le prenant en charge lors de la prochaine interaction. Les développeurs peuvent épingler un modèle différent en le passant dans la configuration de l’agent, en choisissant Gemini 3.5 Flash pour la continuité ou 3.5 Flash-Lite pour une latence et un coût plus faibles. Pour les agents enregistrés en tant que ressources persistantes, le modèle est fixé lors de la création et ne peut pas être remplacé par appel, ce que Google dit pour maintenir un comportement d’appel d’outil, de débogage et de limites de sécurité prévisibles.

Google a publié 3.6 Flash le 21 juillet 2026, aux côtés de 3.5 Flash-Lite et d’un 3.5 Flash Cyber sécurisé, lors du lancement duquel son modèle phare 3.5 Pro a été reporté une fois de plus. Il est facturé 1,50 $ par million de jetons d’entrée et 7,50 $ par million de jetons de sortie, contre 9,00 $ de sortie pour 3.5 Flash, et l’entreprise rapporte qu’il consomme 17 % de jetons de sortie en moins sur l’indice d’analyse artificielle, tout en obtenant 49 % sur le benchmark de codage DeepSWE par rapport à 37 % pour son prédécesseur. Le profil de jeton moins cher est la partie qui compte à l’intérieur d’une boucle d’agent, où une tâche peut s’exécuter pendant des centaines d’étapes.

Limites de dépenses et exécutions planifiées

Le coût est l’autre chose que cette version aborde directement. Un plafond de jeton passé avec la demande limite les jetons d’entrée, de sortie et de réflexion sur l’ensemble de l’interaction ; les jetons mis en cache sont exclus, et la limite est de meilleure effort plutôt que d’être exacte. Lorsqu’un agent atteint cette limite, l’exécution se termine par une erreur avec l’état du sandbox intact, et un appel de suivi reprend le travail avec une nouvelle autorisation. Les estimations de Google placent une tâche de traitement de données lourde à 0,70 $ à 3,25 $, avec des flux de travail complexes accumulant trois à cinq millions de jetons et environ 5 $ dans une seule interaction. Le calcul du sandbox n’est pas facturé pendant l’aperçu.

Deux ajouts transforment l’agent en infrastructure permanente plutôt qu’en appel par requête :

• Déclencheurs planifiés lient un agent, une invite, un environnement et une expression cron dans une ressource persistante qui se déclenche automatiquement, en se mettant en pause par défaut après cinq échecs consécutifs. Chaque exécution réutilise le même sandbox, de sorte que les fichiers écrits par une exécution sont visibles pour la suivante.
• Une interface d’environnements répertorie, inspecte et supprime les sessions de sandbox à partir du code, ce qui récupère un ID d’environnement après une connexion perdue et nettoie les sandboxes lorsque le pipeline se termine au lieu d’attendre leur expiration de sept jours.

Les fonctionnalités s’appuient sur une version du 7 juillet 2026 qui a donné aux agents gérés l’exécution en arrière-plan, les connexions de protocole de contexte de modèle à distance, l’appel de fonction personnalisé et le rafraîchissement des informations d’identification en milieu de session. Ensemble, ils mettent un agent planifié, limité par le budget, avec une couche de politique applicable, à portée d’un développeur travaillant à partir d’une clé d’API gratuite.