Le problème
Les agents multi-tenant échouent de manière prévisible :
- les données d’un tenant fuient dans le contexte d’un autre,
- un tool call s’exécute avec les mauvais credentials,
- les retries multiplient les writes car l’idempotency manque,
- les logs ne suffisent pas pour prouver ce qui s’est passé.
Ce n’est généralement pas un problème de modèle. C’est une isolation runtime manquante.
Non-négociable
1) Lier le contexte tenant avant que l’agent tourne
L’identité tenant doit venir de l’auth et du routing — pas du modèle.
2) Scoper chaque tool call au tenant
Les tools doivent recevoir des credentials et des IDs de ressources scoppés au tenant.
3) Séparer l’état (et les caches) par tenant
Memory, artifacts et caches doivent être keyés par tenant (et souvent par environnement).
4) Budgets et rate limits par tenant
Les budgets et rate limits doivent être par tenant pour éviter qu’un tenant brûle le budget du système entier.
Diagramme (tool gateway scoppé par tenant)
Failure modes fréquents
- Credential bleed : clés/API partagées ou clients globaux réutilisés entre tenants.
- Cache bleed : caches de retrieval keyés seulement par URL/query, pas par tenant.
- Write duplication : retries sans idempotency keys.
- Silent partial writes : step N écrit ok, step N+1 échoue → état incohérent.
Minimum controls pour shipper
- Allowlists default-deny, scoppées par tenant et environnement.
- Idempotency keys pour tous les writes.
- Budgets par tenant (steps/seconds/$) + rate limits par tenant.
- Traces complètes avec tenant_id + stop_reason pour chaque run.