Une automatisation qui respecte votre rayon d’impact

Takuto fait tourner des agents IA sur de vrais dépôts : l’isolation est donc la règle par défaut, pas une réflexion après coup. Voici exactement ce qui contient une exécution, et ce qu’elle ne contient pas.

Isolation

Chaque agent tourne dans son propre container

Le travail est isolé par workflow : un container séparé, un git worktree séparé et un environnement séparé. Les descriptions de tickets et le contenu lié sont des entrées non fiables intégrées aux prompts ; la conteneurisation limite donc ce qu’une session d’agent détournée peut atteindre — elle réduit le rayon d’impact d’une prompt injection plutôt que de faire confiance à l’agent pour bien se comporter.

L’egress passe par un firewall en allowlist

Le trafic sortant est filtré par allowlist dès la conception : seul un ensemble choisi d’hôtes est joignable, tout le reste étant refusé par défaut. La liste par défaut va plus loin que vos seuls outils — elle autorise aussi les registres de paquets et les sites de documentation pour développeurs dont un agent de code a légitimement besoin :

  • Votre système de ticketing — Jira / Atlassian (dont developer.atlassian.com) ou GitHub (dont docs.github.com)
  • Les API des fournisseurs d’IA — Claude, Codex (OpenAI) et Cursor sont autorisés d’emblée pour les fournisseurs que vous activez ; OpenCode étant auto-hébergé, c’est plutôt son base_url qui est autorisé
  • Les registres de paquets — npm (ainsi que votre .npmrc), crates.io, docs.rs, nodejs.org
  • La documentation développeur courante — rust-lang.org, MDN, Stack Overflow
  • Les endpoints AWS STS / SSO, pour les exécutions authentifiées sur AWS

Les hôtes des fournisseurs d’IA suivent les fournisseurs que vous activez dans available_providers — réduisez cette liste pour resserrer le firewall, ou ajoutez vos propres hôtes avec extra_egress_hosts. Considérez le firewall comme une couche de défense en profondeur qui réduit le rayon d’impact — pas une garantie absolue ; il est encore en cours de durcissement pendant la bêta.

Défense en profondeur, pas une solution miracle

L’isolation réduit le risque ; elle ne l’élimine pas. Takuto attend que quelques réglages par défaut soient en place pour qu’une exécution compromise ne puisse pas causer de réels dégâts :

Protection de branche requise

Les agents poussent des branches et ouvrent des PR — ils ne commitent jamais sur main. Imposez la protection de branche au niveau de l’hébergeur Git pour qu’elle tienne même si un agent dérape : exigez une revue humaine approuvée avant la fusion.

Identifiants à portée limitée, au moindre privilège

Un agent détourné ne peut atteindre que ce que ses identifiants autorisent : restreignez-les donc strictement — pour votre code comme pour vos tickets. Préférez un PAT GitHub fine-grained (ou une GitHub App) limité au dépôt cible, et un compte de service Jira dédié n’ayant que Browse / Create / Assign sur les projets cibles. Évitez les connexions OAuth larges et les tokens personnels ou admin : ils accordent généralement bien plus que ce dont une exécution a besoin, si bien qu’une prompt injection réussie pourrait lire ou modifier tout ce que cet identifiant peut atteindre.

Encadrement des tickets non fiables

Le texte des tickets est traité comme du contenu fourni par l’utilisateur qui pourrait tenter d’outrepasser les instructions. La protection de branche et les tokens à portée limitée sont la principale défense contre une description malveillante.

Confidentialité par défaut

Takuto ne piste personne — ni dans le produit, ni sur ce site.

  • Aucune analyse d’usage, aucun rapport de crash, aucun phone-home, aucune télémétrie.
  • Votre code, le contenu des tickets et les prompts ne partent que vers le fournisseur d’IA que vous configurez — Takuto lui-même ne les collecte jamais.
  • La conteneurisation signifie qu’il tourne sur votre machine ou sur votre propre serveur : le déploiement vous appartient.