Quand plusieurs clients partagent un modèle Bedrock, le modèle ne vous offre aucune isolation et n'était jamais censé le faire. C'est une fonction sans état : même entrée, même comportement, aucune mémoire de qui l'a appelé. Chaque frontière entre tenants doit être construite dans les couches autour du modèle, pas attendue de lui. Les équipes s'y prennent à l'envers, supposent que le service géré gère la séparation, et livrent une application où les données, le coût et la charge d'un tenant contaminent ceux d'un autre. Le modèle partagé va bien. Le reste partagé est le problème.

Le rassurant, c'est que le fait que le modèle soit sans état est aussi ce qui rend le multi-tenant gérable. Il n'y a aucun état par tenant à l'intérieur du modèle qui pourrait fuiter, car il n'y a aucun état du tout. L'isolation se réduit à trois frontières concrètes que vous savez déjà construire : quelles données une requête de tenant peut atteindre, combien de la capacité partagée elle peut consommer, et sous quelle identité elle s'exécute.

Isolation des données : scoper la récupération, pas le modèle

Le vrai risque de fuite dans une application RAG ou d'agent n'est pas les poids, c'est le contexte que vous placez devant eux. Si la question du tenant A récupère les documents du tenant B, vous avez une violation de données déguisée en réponse utile. La couche de récupération est donc là où vit la séparation des tenants.

Deux formes viables, selon la rigueur requise de la frontière :

  • Une Knowledge Base par tenant. La frontière dure. Chaque tenant obtient sa propre Bedrock Knowledge Base, si bien qu'une requête ne peut jamais récupérer que dans le corpus de ce tenant. Le plus simple à raisonner, avec plus de pièces mobiles à gérer à mesure que le nombre de tenants croît.
  • Magasin partagé, filtré par tenant. Un magasin vectoriel unique avec un filtre d'ID de tenant obligatoire sur chaque requête, si bien que les résultats sont scopés par métadonnée. Moins cher à exploiter, mais le filtre devient désormais une sécurité porteuse. Il doit être appliqué côté serveur depuis une identité authentifiée, jamais depuis une valeur que le client peut définir.

L'échec à éviter est de filtrer sur un ID de tenant arrivé dans le corps de la requête. Si le client peut nommer son propre tenant, il peut nommer celui de quelqu'un d'autre. Dérivez le tenant du principal authentifié et appliquez la portée là où le client ne peut pas l'atteindre.

Le voisin bruyant : un quota partagé est un échec partagé

Bedrock throttle sur les tokens par minute au niveau du compte et du modèle. Ce nombre est partagé entre tous les tenants qui frappent ce modèle dans votre compte. Donc un tenant qui exécute un gros job batch dépense le budget de tokens partagé, et tous les autres tenants commencent à collecter des erreurs de throttling pour une charge qu'ils n'ont pas générée. Le modèle est isolé logiquement et couplé opérationnellement.

L'isolation ici signifie mesurer et plafonner par tenant avant que le plafond partagé ne le fasse à votre place :

  • Budgets de tokens par tenant. Suivez les tokens consommés par tenant et par fenêtre, et rejetez ou mettez en file un tenant qui dépasse sa propre allocation, pour que son pic ne puisse pas vider le pool partagé.
  • File d'attente équitable. Un pool de workers borné par tenant devant le modèle transforme le pic d'un tenant en ralentissement de ce tenant, pas en panne pour tout le monde.
  • Niveaux de priorité. Si les tenants paient pour différents niveaux de service, faites-le respecter au contrôle d'admission. Un batch de niveau gratuit ne devrait pas pouvoir affamer le trafic interactif d'un tenant payant.

Identité : la frontière du tenant doit atteindre les outils

L'isolation ne peut pas s'arrêter à la récupération. Dès qu'un agent appelle un outil, lit dans une base de données ou écrit dans un stockage, la frontière du tenant doit voyager avec la requête. Cela signifie que la requête s'exécute sous une identité scopée au tenant, si bien que même si le modèle est convaincu de demander la mauvaise donnée, les identifiants derrière l'outil ne peuvent pas la récupérer. La couche modèle ne fait confiance à rien ; la couche IAM applique tout. C'est le moindre privilège appliqué par tenant, et c'est ce qui empêche une tentative d'injection de prompt de se transformer en lecture inter-tenants.

À retenir

Un modèle partagé n'est pas une application tout-partagé. Le modèle est sans état, il ne fournit donc aucune isolation et n'a besoin d'aucune protection propre. Votre travail, ce sont les trois frontières autour de lui : scoper la récupération pour qu'un tenant ne voie que ses propres données, mesurer et plafonner la capacité pour qu'aucun tenant n'affame les autres sur le quota de tokens partagé, et porter une identité par tenant jusqu'aux outils pour qu'une identification scopée soit la dernière ligne quand la couche prompt est trompée. Construisez ces trois éléments et un seul modèle sert de nombreux clients en toute sécurité. Sautez-en un et le modèle servira joyeusement les données du mauvais client au mauvais client.

À lire ensuite

Pour le côté plateforme et isolation multi-comptes du même problème, les notes de terrain cloud se trouvent sur ercan.cloud, et le hub est sur ercanermis.com.