Déclencheurs

tester cette commande dans un sandbox
exécuter cela de façon sécurisée
exécuter du code non approuvé
essayer d'installer ceci
créer un kid
créer un sandbox
tester dans un conteneur
exécuter une commande dangereuse
installer et voir ce qui se passe
essayer ceci sans casser ma machine
isoler ceci
exécuter ceci dans un kid

Kids — agents sandboxés jetables

Vue d'ensemble

Un kid est un enfant EloPhanto exécuté à l'intérieur d'un conteneur Docker renforcé. Il existe pour faire des choses trop dangereuses pour tourner sur l'hôte : installations de paquets, scripts non approuvés, fork bombs, kernel-poking, code en lequel vous n'avez pas pleinement confiance. Le --cap-drop=ALL du conteneur, le rootfs en lecture seule, l'uid non-root, la zone inscriptible réservée aux volumes nommés, et les limites de ressources signifient qu'un kid qui devient incontrôlable ne peut endommager que lui-même.

Les kids ne sont PAS des spécialistes d'organisation. Les kids sont éphémères, n'ont pas d'identité durable, et se connectent à la gateway du parent en tant que client. Les spécialistes sont des pairs persistants avec leur propre gateway et score de confiance. Si l'utilisateur veut une expertise durable, utilisez organization_spawn. Si l'utilisateur veut un test jetable sécurisé, utilisez kid_spawn.

Règles absolues

L'étendue du vault par défaut est vide. Un kid ne reçoit aucun secret sauf si vous accordez explicitement des clés. N'accordez JAMAIS payment_* — les kids ne déplacent jamais d'argent (le registry le bloque de toute façon).
Le réseau par défaut est sortant uniquement. network="host" nécessite une autorisation utilisateur explicite dans le même tour. Ne supposez rien.
Toujours détruire une fois terminé. Les kids inactifs consomment le budget de concurrence. Après avoir lu tout ce dont vous avez besoin, appelez kid_destroy.
Toujours vérifier kid_list avant de créer. Un kid existant configuré pour la même tâche est moins cher qu'un neuf.
Ne jamais utiliser un kid pour des tâches nécessitant l'état du filesystem de l'hôte. Les kids sont isolés. Ils ne peuvent voir vos fichiers que si vous les cp dedans.

Phase 1 — décider si un kid est le bon outil

Utilisez un kid quand l'une de ces conditions est vraie :

La commande pourrait endommager l'hôte : rm -rf, dd, installations système, modules noyau, iptables.
La provenance du code est incertaine : gists GitHub aléatoires, scripts grattés, instructions d'installation générées par IA.
Le travail est ponctuel et ne nécessite pas d'identité durable.

N'utilisez pas de kid quand :

Une expertise de domaine durable est nécessaire → organization_spawn.
La tâche est une pure revue de code ou analyse statique → vos outils existants (aucune isolation nécessaire ; vous lisez juste).
La tâche nécessite le filesystem de l'hôte, une session navigateur, ou des outils de paiement.

Phase 2 — créer

Minimal :

kid_spawn(purpose="test installing cowsay")

Avec un nom clair (pour que les itérations futures puissent le trouver) :

kid_spawn(purpose="test installing cowsay", name="cowsay-test")

Avec une étendue de vault explicite (seulement quand le kid a vraiment besoin de secrets) :

kid_spawn(
    purpose="run a script that calls openrouter",
    vault_scope=["openrouter"],
)

Politiques réseau :

outbound-only (par défaut) : autorisé pour les tâches normales.
none : isolé du réseau — utilisez pour du code supposé hostile.
host : accès réseau complet de l'hôte — NÉCESSITE une autorisation utilisateur explicite.

Phase 3 — exécuter

kid_exec(kid_id_or_name="cowsay-test", task="apt install cowsay && cowsay hello")

Le kid exécute la tâche à l'intérieur de son conteneur. La sortie revient via la gateway. Observez les événements de chat du kid.

Phase 4 — lire les sorties (optionnel)

Si le kid a écrit des artefacts, récupérez-les AVANT destruction :

L'aide côté parent read_kid_file(kid, "/workspace/result.json") copie le fichier via docker cp. La traversée de répertoires est bloquée par le runtime — seules les lectures /workspace/... sont autorisées.

Phase 5 — détruire

Toujours :

kid_destroy(kid_id_or_name="cowsay-test", reason="task complete")

Cela arrête le conteneur, le supprime, et retire le volume nommé. Les sorties du kid sont DISPARUES après ceci.

Modes de défaillance / quand refuser

Aucun runtime de conteneur installé. L'outil retourne une erreur pointant vers la commande d'installation pour l'OS de l'utilisateur. N'essayez pas de contourner ; dites à l'utilisateur d'exécuter la commande suggérée.
Image kid non compilée. Exécutez elophanto kid build une fois. Doctor avertit quand l'image est plus ancienne que le codebase.
L'utilisateur demande network=host sans expliquer pourquoi. Repoussez : le réseau par défaut suffit pour presque tous les tests de commandes dangereuses.
*L'utilisateur veut accorder `payment_` à un kid.** Refusez — les kids ne déplacent jamais d'argent. Utilisez l'agent parent pour les travaux de paiement.
L'utilisateur veut que le kid crée ses propres kids. Refusez — la profondeur est 1 par conception. L'outil kid_spawn est filtré du registry à l'intérieur des kids.

Suivi de réputation

learned/kids/{date}-{purpose-slug}.md pour tout kid dont l'exécution a produit des leçons (commandes d'installation fonctionnelles, motifs cassés, configurations de sandbox utiles). Ignorez le journal pour les tests triviaux à une seule commande.

Vérifier

L'autre agent / outil / canal destinataire a effectivement reçu le message ; un accusé réception, un ID de message, ou une charge utile de réponse est capturé
L'identité, les étendues, et les permissions utilisées par l'appel étaient le minimum requis ; les tokens sur-permissionnés sont signalés
La gestion des défaillances a été exercée : au moins un chemin de retry/timeout/permission-denied montre le comportement correct
Le contexte de transfert passé au prochain acteur est suffisant pour que le destinataire puisse agir sans question de suivi
Tout état muté (config, mémoire, queue, fichier) est listé avec les valeurs avant/après, pas juste 'mis à jour'
Le matériel sensible (clés, tokens, PII) a été redacté des logs/transcriptions partagées dans la preuve de vérification

Anti-motifs

Oublier de détruire. Les kids inactifs gaspillent la concurrence. Règle absolue : détruisez dans le même tour que la lecture finale, sauf si l'utilisateur veut continuer à itérer.
Accorder des secrets "juste au cas où". L'étendue vide est le défaut. Si le kid a besoin de openrouter, accordez SEULEMENT openrouter.
Utiliser un kid pour des tâches que le parent pourrait faire. Si shell_execute sur l'hôte est sûr, faites-le sur l'hôte. Les kids sont pour le chemin non sûr.
Réutiliser un kid pour du travail non lié. Créez un kid neuf par domaine de tâche — le coût est faible et l'isolation est par kid.

kid-agents