Le problème d’automatisation.
Une boucle computer use devient dangereuse si suggestion du modèle et autorité du programme se confondent. Un prompt décrit un objectif ; il ne doit pas accorder silencieusement l’accès aux fichiers, au shell ou au bureau.
Le projet devait n’exposer que les capacités réellement disponibles, appliquer le niveau de permission choisi par l’opérateur et exiger une observation après chaque action.
Les limites imposées par le runtime.
L’agent repose sur des limites explicites :
- Le niveau observe par défaut fournit des contrôles du runtime et un accès en lecture seule aux chemins approuvés.
- Les outils bureau, navigateur, fichiers et système n’apparaissent que si runtime et niveau de permission les autorisent.
- Il n’existe pas de shell généraliste. Le lanceur borné invoque directement un seul exécutable en allowlist et refuse pipelines, substitutions et chaînage.
- Une tâche n’est terminée qu’après une observation post-action vérifiée.
Séparer raisonnement et autorité.
Le modèle choisit l’action déclarée qu’il souhaite demander. Il ne décide ni de sa permission, ni de sa durée, ni de la quantité de sortie ajoutée au prompt suivant.
J’ai placé ces décisions dans un registre d’outils protégé par politique et une orchestration bornée. Les outils inconnus échouent, les tentatives et la durée sont limitées, et les événements d’audit sont expurgés avant écriture.
Une boucle observer–décider–autoriser–vérifier.
La perception capture une image ou l’arbre d’accessibilité. Gemini renvoie un appel de fonction déclaré. La politique vérifie runtime, niveau et allowlists avant exécution. L’observation obtenue devient la preuve du tour suivant.
Les choix qui réduisent la surface d’attaque.
Les capacités relèvent de la configuration et du code, pas de la politesse du prompt.
Construire le registre au runtime
Les outils indisponibles sont omis au lieu d’être annoncés puis de tomber en échec après leur sélection.
Le modèle voit moins d’outils, ce qui vaut mieux que de prétendre chaque environnement aussi puissant.
Utiliser des contrôles indépendants
Les outils système exigent le niveau system, une confirmation séparée et des allowlists de chemins, applications et exécutables.
La configuration prend plus de temps, mais un seul interrupteur ne peut pas exposer toutes les actions sensibles.
Authentifier la console locale
Le plan de contrôle échange un jeton opérateur contre une session HttpOnly courte et limite origine, débit, uploads et concurrence.
Il reste local et mono-processus, pas un service public multi-tenant.
Vérification du runtime et des publications.
Les tests portables tournent sous Linux et la CI Windows couvre les fonctions de bureau. Analyse statique, audit des dépendances, validation du site et smoke tests Docker vérifient les autres chemins de livraison.
Les conteneurs ne sont promus par digest qu’après contrôles des vulnérabilités, SBOM et provenance. Le contrôle natif reste hors de Docker ; le site Pages est une présentation, pas une console opérateur.
Ce que prouve l’alpha.
L’agent utilise des outils déclarés dans une boucle dont l’autorité est visible et bornée en dehors de la réponse du modèle.
Il ne revendique pas d’autonomie générale. Qualité de l’interface, focus, latence tierce et surfaces Canvas limitent encore sa fiabilité ; il doit rester dans un environnement jetable ou soigneusement borné.
Registre des preuves.
Les affirmations reposent sur des limites vérifiées, pas sur des anecdotes d’autonomie :
- Vérification
- 155 déclarations de tests unitaires et un seuil de couverture du dépôt de 70 %.
- Limites des tâches
- Par défaut : 50 tours, 900 secondes par tâche, 120 secondes par requête modèle et 45 secondes par action.
- Plan de contrôle
- Jeton opérateur d’au moins 24 caractères, huit WebSockets et deux flux natifs au maximum par défaut.
- Limite
- Gemini est une dépendance cloud ; Docker ne contrôle pas le bureau hôte et la fiabilité native dépend de l’accessibilité et du focus.