Sécurité

La sécurité de Touba repose d’abord sur des contrats observables : source .tb, AIR, manifest, scopes, secrets opaques, budgets, locks et traces.

Contrôles disponibles

Contrôle	Ce qu’il fait
AIR	porte les requirements compilés
manifest explicite	accorde handler, grants, secrets, limites et mémoires
handles de secrets	évitent les valeurs sensibles dans .tb, AIR, manifest et traces
scopes de secrets agent	limitent les handles utilisables par agent actif
cycle de vie secrets	refuse un handle révoqué ou expiré avant handler
callable_by	refuse les invocations agent non autorisées
uses agent	borne les ressources sélectionnables par décision agentique
entrée modèle structurée	sépare instructions, données utilisateur, ressources et observations
maxAgentSteps	limite la boucle séquentielle d’un agent piloté par provider
scopes mémoire	refusent les accès mémoire hors périmètre
validation payload tools	refuse input/output invalides avant ou après handler
arrêt contrôlé	trace cancel, timeout global et kill switch dans touba run
budgets d’autonomie	refuse dépassement de durée, étapes, appels tools, invocations agents et appels provider
isolation de handler requise	enveloppe le process avec le mécanisme sandbox de la plateforme, sans fallback direct
supply chain des handlers	vérifie la cohérence AIR, manifest, handlers, metadata SDK, handler_package, fichiers de paquet, artefacts de dépendances, provenance et revue déclarées par lock explicite
traces	rendent autorisations, pauses et refus observables

Touba distingue l’entrée modèle structurée pour les décisions agentiques : instruction développeur, données utilisateur, ressources disponibles et observations runtime. Cette séparation constitue une frontière structurelle de sécurité ; la détection de prompt injection reste une couche d’analyse séparée.

Un autre durcissement disponible est l’arrêt contrôlé : distinguer pause, annulation demandée, annulation effective, échec et succès. Touba expose un cancel coopératif, un timeout global et un kill switch via touba run.

Les budgets d’autonomie couvrent max_run_ms, max_steps, max_tool_calls, max_agent_invocations, max_provider_calls et les quotas de trigger. Ils refusent une exécution qui sort de ces limites et produisent des traces budget.

La provenance et l’intégrité des mémoires sont définies comme métadonnées observables : origine, writer, run, digest reporté et evidence d’intégrité. Ce cadre aide l’audit des accès mémoire ; la vérité et la confiance du contenu restent gouvernées par le backend et le processus de revue environnants.

L’audit des traces relie trace, AIR, source, digests d’artefacts, rétention déclarative et politique de redaction. Il sert à rendre un run explicable et vérifiable par artefacts.

Voir aussi : Audit des traces.

La supply chain des handlers (SC-1 / SC-2 / SC-3) couvre : digests sha256 des handlers, du manifest et de l’AIR, metadata de commande, metadata SDK descriptive, identité déclarée handler_package, fichiers de paquet handler, artefacts de dépendances déclarés, provenance, revue déclarée, validation CLI explicite et inspection des locks ou rapports.

Voir aussi : Supply chain des handlers.

Lorsque sandbox.required: true, macOS utilise sandbox-exec ; Linux x64 combine bubblewrap, seccomp et Landlock. Ces backends refusent par défaut les données hors périmètre, les écritures, les processus enfants et le réseau. Un backend absent ou une politique non applicable provoque un refus, jamais un lancement direct de secours. Les prérequis et l'état de qualification sont détaillés dans le profil d'exécution durci. Sans sandbox obligatoire, les handlers restent du code hôte de confiance. Voir Référence manifest.

Ce que Touba refuse avant handler

• binding absent ;
• grant manquant ;
• secret non accordé ou non résolu ;
• secret révoqué ou expiré ;
• secret non accordé à l’agent actif ;
• scope mémoire absent ;
• payload d’entrée invalide ;
• caller agent non autorisé ;
• capacité agentique hors uses ;
• sous-agent non autorisé par callable_by ;
• boucle agentique dépassant la limite de pas configurée ;
• budget d’autonomie dépassé ou manifest qui tente d’élargir une limite AIR.

Frontières de sécurité

• Les grants Touba sont des frontières de contrat déclarées. La sandbox de handler est un contrôle de plateforme distinct et explicitement requis par binding.
• Les traces et exports d’audit sont des preuves d’ingénierie ; la certification réglementaire est un processus séparé.
• Les locks supply chain rendent le drift des handlers observable ; la sûreté d’un handler reste un sujet de revue de code hôte.
• La séparation données/instructions réduit une confusion structurelle ; la détection de prompt injection relève d’une couche d’analyse sécurité.
• Verified / Unverified est réservé à une chaîne garantie complète.

Posture recommandée

• Utiliser des clés à faible privilège pour les essais live.
• Ne jamais committer de valeur secrète.
• Lire les traces après un refus.
• Garder les handlers petits et testables.
• Considérer un handler comme du code hôte à auditer.
• Utiliser des types distincts pour les contenus externes et les instructions envoyées à un modèle.