Modèles de permissions pour copilotes IA multi-tenant

L'accès chat n'est pas l'accès données

Les utilisateurs qui peuvent ouvrir un panneau copilote ne doivent pas lire automatiquement chaque document que le modèle peut récupérer. Séparez l'appartenance à la conversation des entitlements de ressource. Le modèle ne voit que ce qu'une politique côté serveur autorise pour ce principal dans ce tenant—jamais ce qu'un prompt prétend que l'utilisateur a besoin.

Les fuites cross-tenant commencent souvent dans le retrieval : embeddings indexés sans prédicats tenant, ou collections vectorielles partagées interrogées par similarité seule. Mettez l'id tenant dans chaque partition d'index et chaque validation d'argument d'outil.

Autoriser les outils comme des API publiques

Chaque invocation d'outil doit passer par le même middleware authz que vos handlers REST ou gRPC : authentifier l'utilisateur (ou l'identité service), résoudre le contexte tenant, vérifier RBAC/ABAC, puis exécuter en least privilege. Les agents ne doivent pas détenir de tokens dieux longue durée qui contournent les contrôles row-level.

Préférez des credentials courts et scoped émis par session ou par appel d'outil. Quand les agents fan-out, propagez claims subject et tenant—n'élargissez pas le scope parce qu'une étape planner 'a besoin de plus de contexte.'

• Imposer des prédicats tenant sur indexes de retrieval et arguments d'outils
• Réutiliser le middleware authz API pour chaque appel d'outil ; pas de chemin d'permission fantôme
• Émettre des credentials courts scoped au lieu de dieux de service partagés
• Auditer principal, tenant, outil, ressource et décision pour chaque appel

Modéliser le principal pour lequel l'agent agit

Décidez si le copilote agit comme l'utilisateur final, comme un rôle assistant contraint, ou comme un opérateur break-glass avec approbation séparée. Documentez la différence pour support et conformité. L'impersonation sans audit est un incident de sécurité en attente.

L'injection de prompt peut tenter d'élever les outils. La défense est l'application de politiques hors du modèle : deny lists, allow lists d'outils par rôle et filtres de sortie qui ne peuvent pas accorder de nouvelles permissions.

Prouver l'isolation en continu

Ajoutez des tests automatisés qui tentent retrieval et appels d'outils cross-tenant avec des conversation ids volés. Surveillez les taux de refus et les pics d'allow inattendus après changements de prompt ou d'index. Les copilotes multi-tenant échouent bruyamment en démo et silencieusement en production—instrumentez pour les échecs silencieux.

Les permissions sont une surface produit. Concevez-les avec le même soin que le modèle qui parle derrière.

• OWASP — LLM Top 10
• OpenAI — Safety best practices
• Auth0 — Authorization patterns