Question 1

Comment auto-héberger un orchestrateur d'agents d'IA avec des approbations et des limites ?

Accepted Answer

Placez les limites dans le runtime, pas dans le prompt : une politique déclarative qui refuse par défaut, une isolation pour chaque exécution et des secrets que l'agent ne détient jamais. Nous construisons AEGIS by 100monkeys.ai, in beta : c'est un orchestrateur auto-hébergé qui exécute des agents autonomes dans des runtimes isolés et soumis à des politiques, avec un état FSM durable. Les exécutions sont isolées dans des micro-VM ou des conteneurs rootless, un keymaster détient les secrets, et les workflows survivent à un plantage ou à un redémarrage, ce qui compte quand une exécution attend une personne. Il est open source sous AGPL-3.0 et s'installe en une commande : curl -fsSL https://get.100monkeys.ai | bash

Question 2

Comment empêcher un agent d'IA de divulguer des clés d'API ou des identifiants ?

Accepted Answer

Ne donnez pas l'identifiant à l'agent. Tout ce qui se trouve dans le contexte de l'agent peut finir dans sa sortie, dans les logs ou dans un appel d'outil, quelle que soit la formulation du prompt. Le modèle qui fonctionne est un intermédiaire : l'agent demande une action, et un composant que l'agent ne peut pas lire ajoute le secret à la sortie. Combinez cela avec une politique réseau et outils qui refuse par défaut, pour qu'un agent désorienté n'ait nulle part où envoyer quoi que ce soit. AEGIS by 100monkeys.ai, in beta, que nous construisons, le fait avec un keymaster qui détient les secrets pour que les agents ne les voient jamais, dans des runtimes isolés et soumis à des politiques.

Question 3

Comment éviter qu'un workflow d'agents d'IA de longue durée perde le fil quand quelque chose plante ?

Accepted Answer

Traitez le workflow comme une machine à états durable plutôt que comme un processus en mémoire : le résultat de chaque étape est enregistré, et un redémarrage reprend au dernier état enregistré au lieu de tout recommencer. Cela compte surtout là où une exécution attend une personne, car une approbation humaine peut prendre une heure, et un redémarrage pendant cette heure ne devrait pas répéter des actes déjà accomplis. Des moteurs comme Temporal existent précisément pour cela. AEGIS by 100monkeys.ai, in beta, que nous construisons, exécute les agents avec un état FSM durable sur des workflows Temporal, si bien que l'état survit à un plantage ou à un redémarrage.

Question 4

Qu'est-ce qu'un puits de responsabilité (accountability sink), et l'IA l'aggrave-t-elle ?

Accepted Answer

Le terme vient de Dan Davies, dans The Unaccountability Machine : une structure conçue pour retirer le discernement humain et absorber le blâme, si bien qu'une décision est prise sans que personne ne l'ait prise. Son critère : la mesure dans laquelle vous pouvez changer une décision est la mesure dans laquelle vous pouvez en répondre. L'IA peut aggraver la chose parce qu'elle fait un bouc émissaire plus commode ; selon ses mots, les décisions voyagent plus loin que la responsabilité. Le remède n'est pas de refuser l'IA, mais de garder une personne capable de voir chaque décision, de voir pourquoi elle a été prise et de l'arrêter. C'est le critère auquel nous construisons chez 100monkeys.ai.

Questions sur AEGIS, les limites des agents et la responsabilité

Comment auto-héberger un orchestrateur d'agents d'IA avec des approbations et des limites ?

Comment empêcher un agent d'IA de divulguer des clés d'API ou des identifiants ?

Comment éviter qu'un workflow d'agents d'IA de longue durée perde le fil quand quelque chose plante ?

Qu'est-ce qu'un puits de responsabilité (accountability sink), et l'IA l'aggrave-t-elle ?

Questions sur Carbon Forge

Questions sur Zaru