Utiliser le profil d'execution durci

Le profil durci est opt-in. Copiez le contrat publie contracts/hardened/profile.json vers touba.hardened-profile.json, renseignez ce chemin dans votre profil projet, puis preparez et lancez le run.

{
  "run_profiles": {
    "hardened": {
      "require_supply_chain_lock": true,
      "supply_chain_lock": "touba.lock.json",
      "hardened_profile": "touba.hardened-profile.json"
    }
  }
}

Déclarez les budgets dans la source .tb, après les imports, avant les déclarations ; le compilateur produit les limites AIR requises.

module examples.bounded

limits run
    max_run_ms as 30000
    max_steps as 100
    max_tool_calls as 20
    max_agent_invocations as 5
    max_provider_calls as 10

Chaque binding de tool doit contenir "sandbox": { "required": true }. La commande doit aussi fournir un chemin de checkpoint durable. Le runtime choisit opaque_refs pour le provider et refuse avant effet si le lock, la sandbox, les budgets, la redaction ou le stockage de checkpoint ne sont pas prouves.

Ce profil reduit des risques locaux. Il ne garantit ni absence d'exfiltration par un handler autorise, ni detection generale des injections, ni isolation equivalente entre Linux, macOS et Windows.

Avec un plan déjà préparé et un lock vérifié :

touba run --run-plan .touba/build/hardened/touba.run-plan.json \
  --human-checkpoint-out .touba/pending-approval.json --output json

HardenedBudgetRequired indique une limite absente dans la source compilée ; HardenedDurableCheckpointRequired indique l’absence du chemin de checkpoint. La sortie JSON et sa trace d’admission conservent ces codes, sans payload métier. Un programme pur permet de vérifier le chemin budgets/lock/checkpoint ; cela ne qualifie pas l’isolation OS d’un handler.

Retrouver le contrat installé

Avec une distribution Touba installée, cette commande macOS/Linux affiche le chemin du contrat livré, sans modifier l'installation :

Localiser le profil

node --input-type=module <<'JS'
import {execFileSync} from 'node:child_process';
import {accessSync} from 'node:fs';
import {dirname, resolve} from 'node:path';
const info = JSON.parse(execFileSync('touba', ['version', '--json'], {encoding: 'utf8'}));
if (!info.distribution.sdk_archive) throw new Error('An installed Touba distribution is required');
const profile = resolve(dirname(info.distribution.sdk_archive), '../lib/contracts/hardened/profile.json');
accessSync(profile);
console.log(profile);
JS

Copiez ce fichier dans votre projet et conservez les contrôles du profil. Dans le dépôt source, le chemin est implementation/contracts/hardened/profile.json.

Qualification de la sandbox

Lorsque sandbox.required: true, macOS utilise sandbox-exec ; Linux x64 combine bubblewrap, seccomp et le lanceur natif touba-sandbox avec Landlock ABI 3 minimum. Les données hors périmètre, écritures, descendants et connexions réseau sont refusés par défaut. Les essais natifs Linux couvrent Ubuntu 24.04, Node et Python, y compris l'arrêt des descendants au timeout.

Sous Linux, bubblewrap doit être installé et les user namespaces utilisables. Un hôte Ubuntu protégé par AppArmor peut nécessiter un profil administrateur limité à ce binaire, sans désactiver les protections globales. Un chemin write_paths doit déjà exister : utilisez un répertoire de sortie dédié pour créer des fichiers. Écrire n'accorde pas la lecture. Les sockets Unix exacts exigent Landlock ABI 9 ; une politique non applicable est refusée avant lancement. La sonde exécute une commande sous confinement pour vérifier les prérequis.

Le backend Windows est encore en qualification pour la V1, notamment pour les handlers Python asynchrones sans autorisation réseau. Il n'est pas annoncé comme disponible dans une distribution finalisée. Un confinement indisponible ou une politique non applicable bloque le lancement, sans exécution directe de secours. Sans sandbox obligatoire, les handlers restent du code hôte de confiance. Le code HandlerSandboxUnsupportedPolicy désigne une politique non prise en charge par le backend sélectionné.

La base technique autorise les bibliothèques natives et métadonnées nécessaires à l'interpréteur, pas tous les modules JavaScript ni le dossier utilisateur. Pour un SDK JavaScript installé et vérifié, prepare inventorie ses fichiers individuels dans sandbox.code_paths. Les dépendances tierces restent à déclarer explicitement ; aucun dossier entier n'est ouvert. Les fragments explicites conservent leur propre inventaire.

La sélection code_paths complète cet inventaire technique ; [] retire les fichiers supplémentaires, pas les fichiers du SDK vérifié. Les chemins de données restent des autorisations séparées.

Activez la sandbox dans les décisions hôte, sans modifier le manifest à la main :

Terminal

touba prepare --mode plan --host-decisions-json '{"bindings":{"tool:orders.review/ReadOrder":{"sandbox":{"required":true}}}}'

Remplacez la référence par celle de votre tool, installez son SDK, relisez l'inventaire, puis utilisez --mode write et --mode check. Les arguments relatifs des fichiers handlers sont résolus avant le lancement isolé. Les données nécessitent toujours un grant et un chemin read_paths ou write_paths explicites. Un chemin de code n'accorde aucun droit d'écriture. Pour un échec au chargement, --handler-diagnostics <fichier.jsonl> en développement conserve uniquement la classe d'erreur et la position connue, sans message privé.