Comment concevoir des comptes de service LLM pour les charges de travail de production

Les charges de travail LLM de production ne doivent pas s'authentifier en tant que personnes. Une tâche CI, un service backend, un exécuteur d'agent, un processeur par lots ou une passerelle destinée aux partenaires ont besoin de leur propre identité non humaine avec un propriétaire clair, une portée, un budget, une piste d'audit et un chemin d'arrêt clairs. Sans ce modèle, une clé divulguée peut représenter trop de systèmes, la délocalisation ne supprime pas l'accès et les rapports d'utilisation ne peuvent pas expliquer quelle charge de travail a créé un coût ou un risque.

Ce guide donne aux équipes d'ingénierie et de plate-forme une conception pratique de la gouvernance des comptes de service LLM sur les API des fournisseurs et les passerelles internes. Il sépare les faits vérifiés sur le fournisseur des recommandations de mise en œuvre et présente des prédictions sur les domaines dans lesquels le modèle opérationnel est susceptible d'évoluer.

Qu'est-ce qu'un compte de service LLM ?

Fait : Les comptes de service sont des identités non humaines utilisées par les applications et les charges de travail plutôt que par les utilisateurs individuels. OpenAI API projets prennent en charge les comptes de service et API clés au niveau du projet. Anthropic décrit les comptes de service comme des identités non humaines nommées au sein d'une organisation. Google Cloud IAM décrit les comptes de service comme des utilisateurs non humains pour les applications et les charges de travail.

Pour les systèmes LLM, un compte de service doit représenter une limite de charge de travail : un service backend, une famille de workflows CI, un environnement d'exécution d'agent, un pipeline par lots ou un niveau d'intégration API partenaire. Il ne doit pas représenter une personne, une entreprise entière ou chaque application d'un environnement.

Un enregistrement de compte de service utile répond à cinq questions :

• Quelle application ou quel workflow possède cette identité ?
• Dans quel environnement peut-il fonctionner ?
• Quelle équipe est responsable des coûts, des accès et des incidents ?
• Quels modèles, points de terminaison, outils, politiques de données et régions sont autorisés ?
• Comment l'identifiant est-il alterné, révoqué ou remplacé par la fédération ?

Quand créer un compte de service

Créez un compte de service lorsque l'appelant est un logiciel opérationnel plutôt qu'un humain. Les exemples courants incluent les tâches CI/CD qui exécutent des évaluations, les services de production API, les agents de traitement de documents, les copilotes de support client, les files d'attente d'agents autonomes, les tâches d'enrichissement planifiées et les plates-formes de développement internes qui négocient l'accès LLM pour de nombreuses équipes.

Ne créez pas de nouveau compte de service pour chaque développeur, chaque expérience locale ou chaque invite. L’exploration humaine appartient à l’identité des utilisateurs et aux références de développement de courte durée. L'attribution au niveau des invites et des fonctionnalités peut être capturée sous forme de métadonnées de requête sous l'identité de la charge de travail.

Une règle de décision simple fonctionne bien :

• Si l'appelant peut s'exécuter sans surveillance, utilisez un compte de service.
• Si l'appelant diffuse du trafic de production, utilisez un compte de service par charge de travail et par environnement.
• Si l'appelant agit pour le compte d'un client ou d'un partenaire, séparez l'identité de la charge de travail de l'identité du locataire délégué.
• Si l'appelant est un humain utilisant une console ou un ordinateur portable, ne le cachez pas derrière un compte de service de production.

Commencez par un inventaire d'identité

La migration doit commencer par un inventaire, pas par une rotation des clés. Les équipes découvrent souvent qu'une clé de fournisseur est utilisée par les services de production, les tâches de préparation, les scripts locaux, les pipelines d'évaluation et les intégrations abandonnées. La rotation de cette clé en premier crée un risque sans améliorer la propriété.

Créez un inventaire avec ces catégories :

• Clés du fournisseur humain API.
• Comptes de service de charge de travail.
• Identités CI/CD.
• Clés internes émises par la passerelle.
• Clés déléguées du partenaire ou du client.
• Identifiants d'urgence pour briser les vitres.
• Clés inconnues qui génèrent encore de l'utilisation.

Pour chaque identifiant, fournisseur d'enregistrement, projet ou espace de travail, propriétaire de clé, application consommatrice, environnement de déploiement, emplacement secret, modèles autorisés, propriétaire de la dépense, horodatage de dernière consultation et risque de révocation. Cet inventaire devient la source de vérité pour le LLM APIgestion des clés, mais les comptes de service doivent être modélisés comme des identités de charge de travail de premier ordre plutôt que comme une simple étiquette de clé.

Utiliser un compte de service par limite de charge de travail

Le principal choix de conception est la granularité. Trop peu de comptes de service créent un rayon d'explosion partagé. Un trop grand nombre crée du bruit de fonctionnement. La bonne unité est la plus petite limite de charge de travail qui a des besoins distincts en matière de propriété, d'autorisations, de profil de coûts ou de réponse aux incidents.

Utilisez des comptes de service distincts pour :

• Environnements de production et hors production.
• Différentes applications appartenant à différentes équipes.
• Services orientés client versus emplois internes.
• Chemins de requêtes interactifs par rapport aux processeurs par lots asynchrones.
• Environnements d'exécution d'agent pouvant appeler des outils ou exécuter des boucles.
• Partenaire API surfaces qui exposent l'accès délégué.

Un modèle de dénomination pratique est :

llm-sa-{app}-{env}-{team}-{purpose}

Exemples :

llm-sa-supportbot-prod-cx-chat
llm-sa-contracts-stg-legal-extract
llm-sa-evals-ci-platform-regression
llm-sa-agentrunner-prod-eng-tools

Ne codez pas de secrets, de noms de clients, de noms de personnes ou de numéros de ticket temporaires dans le nom du compte. Mettez plutôt les détails modifiables dans les balises ou les métadonnées.

Mapper les comptes de fournisseur à un modèle d'identité de passerelle

Fait : Les capacités des fournisseurs diffèrent. OpenAI prend en charge les comptes de service dans API projets, et les comptes de service de projet sont uniques au projet dans lequel ils sont créés. Anthropic espaces de travail peuvent contenir des membres, des comptes de service, API clés et des limites de ressources. Anthropic La fédération d'identité de charge de travail permet aux charges de travail d'utiliser des jetons d'identité signés au lieu d'identifiants Anthropic statiques, avec des limites d'attribution et de débit liées à l'espace de travail une fois configurées.

Recommandation : Conservez un modèle de compte de service au niveau de la passerelle même lorsque des comptes de service natifs du fournisseur existent. L’identité de la passerelle doit être l’objet interne stable auquel sont attachés la politique, les rapports, les budgets et les éléments probants. Les informations d'identification du fournisseur sont ensuite les détails de mise en œuvre mappés en dessous.

Par exemple :

internal_service_account:
  id: sa_01h_supportbot_prod
  name: llm-sa-supportbot-prod-cx-chat
  owner_team: customer_experience
  environment: production
  app: supportbot
  allowed_models:
    - provider: openai
      model_family: gpt-4.1
    - provider: anthropic
      model_family: claude-sonnet
  data_policy: no_training_required
  monthly_budget_usd: 2500
  provider_bindings:
    openai_project: proj_supportbot_prod
    anthropic_workspace: ws_supportbot_prod

Ce mappage est important dans une passerelle d'IA multimodèle API car les fournisseurs en amont exposent différentes structures de compte, champs de facturation, autorisations de modèle et options de fédération. Une seule couche d'identité interne permet aux équipes d'appliquer un contrat de stratégie tout en préservant le contexte spécifique au fournisseur pour le dépannage.

Autorisations de portée étroite

Un compte de service doit être limité aux besoins de la charge de travail, et non à ce que la clé du fournisseur autorise. Au minimum, définissez la portée sur ces dimensions :

• Limite du fournisseur : quels fournisseurs et projets ou espaces de travail du fournisseur peuvent être utilisés.
• Limite du modèle : familles de modèles autorisées, versions, modèles d'aperçu et modèles de secours.
• Limite du point de terminaison : chat, réponses, intégrations, lots, fichiers, réglages fins, assistants, outils ou API d'administration.
• Limite de l'environnement : développement, préproduction, production, sandbox ou partenaire.
• Limite des données : stratégie de rétention, région, classe de données sensibles et fonctionnalités avec état autorisées.
• Limite budgétaire : alertes logicielles, plafonds stricts, limites par minute et limites mensuelles.
• Limite du réseau : réseaux sources, identités de charge de travail ou plates-formes de déploiement acceptés.

Les autorisations administratives API ne devraient presque jamais être disponibles pour les comptes de service d'exécution. Séparez l’automatisation du provisionnement des charges de travail d’inférence. Un service backend qui envoie des invites ne devrait pas non plus être en mesure de créer de nouvelles clés de fournisseur, de modifier les budgets ou d'accorder l'accès au modèle.

Préférez la fédération aux clés statiques lorsque cela est pratique

Fait : Anthropic documente la fédération d'identité de charge de travail comme un moyen pour les charges de travail d'utiliser des jetons d'identité signés plutôt que des informations d'identification Anthropic statiques. Google Cloud avertit que les clés de compte de service gérées par l'utilisateur constituent des risques de sécurité si elles ne sont pas gérées avec soin et recommande des alternatives plus sécurisées lorsque cela est possible. L'OWASP recommande le stockage centralisé des secrets, l'audit des demandes et de l'utilisation des secrets, la rotation, la révocation et l'expiration lorsque cela est possible.

Recommandation : Préférez la fédération d'identité de charge de travail ou l'échange de jetons de courte durée pour les services hébergés dans le cloud et les systèmes CI/CD où le support du fournisseur existe. Utilisez les clés statiques API uniquement lorsque la fédération n'est pas disponible, n'est pas prise en charge par le chemin du fournisseur dont vous avez besoin ou est injustifiée sur le plan opérationnel pour une charge de travail à faible risque.

Un flux de fédération ressemble généralement à ceci :

1. La charge de travail s'exécute sous un principal cloud, CI ou fournisseur d'identité.
2. La charge de travail obtient un jeton d'identité signé de ce fournisseur d'identité en amont.
3. Le fournisseur LLM ou la passerelle interne valide l'émetteur, l'audience, le sujet et les revendications.
4. La passerelle mappe le jeton à un compte de service interne.
5. La passerelle émet une session de courte durée ou autorise directement la requête LLM.

Valider plus que l'émetteur. Vérifiez l'audience, le sujet, le chemin du référentiel ou de la charge de travail, les revendications d'environnement, de branche ou de déploiement le cas échéant, ainsi que la durée de vie du jeton. La fédération déplace le risque de fuite de secrets statiques vers la configuration du fournisseur d'identité. Des revendications faibles, des politiques de confiance étendues ou des environnements CI permissifs peuvent toujours accorder un accès involontaire.

Exiger des métadonnées d'attribution pour chaque requête

Les comptes de service identifient la charge de travail, mais ils ne doivent pas constituer le seul champ d'attribution. Les requêtes LLM de production nécessitent suffisamment de métadonnées pour répondre rapidement aux questions opérationnelles.

Exiger ces champs au niveau de la passerelle :

• service_account_id
• app
• environment
• owner_team
• deployment_id ou version finale
• request_purpose, comme le chat, l'extraction, la classification, l'évaluation ou agent_tool_use
• tenant_id ou identifiant client le cas échéant
• workflow_id ou identifiant de travail pour le travail asynchrone

Ces champs prennent en charge le LLM API attribution des coûts, la réponse aux incidents, les décisions de limite de débit et le rapprochement des factures des fournisseurs. Ils empêchent également le mode de défaillance courant dans lequel chaque requête provenant d'une clé partagée est uniquement étiquetée comme « backend ».

Joindre des budgets et des alertes aux identités de charge de travail

Les comptes de service s'exécutent souvent sans surveillance. Cela rend le contrôle des coûts plus important, pas moins. Un utilisateur peut remarquer une session de discussion incontrôlée. Un agent planifié ou une nouvelle tentative de travail par lots peut épuiser le budget du jour au lendemain.

Définissez des budgets sur plusieurs niveaux :

• Budget du projet ou de l'espace de travail du fournisseur lorsque cela est pris en charge.
• Budget mensuel au niveau de la passerelle par compte de service.
• Détection d'anomalies sur une courte période pour les pics soudains.
• Coût estimé maximum par demande ou par tâche.
• Limites distinctes pour les charges de travail de production, de préparation, de CI et d'évaluation.

Utilisez différentes actions pour différents seuils. À 50 pour cent, informez l’équipe propriétaire. À 80 pour cent, exigez un accusé de réception. À 100 %, bloquez les demandes non critiques, rétrogradez vers des modèles approuvés moins chers ou exigez un remplacement explicite. Le comportement correct dépend du fait que la charge de travail soit destinée au client, interne, par lots ou critique pour la sécurité.

Concevoir le workflow du cycle de vie

Un compte de service sans contrôles de cycle de vie devient un autre secret non géré. Définissez le flux de travail avant une adoption généralisée.

Demande

Le demandeur doit fournir le nom de l'application, l'environnement, l'équipe propriétaire, l'objectif commercial, les dépenses mensuelles prévues, la classification des données, les exigences du modèle, les exigences du point de terminaison et si la fédération est possible.

Approbation

L'approbation doit provenir de l'équipe propriétaire et de la plate-forme ou de la politique de sécurité. Les charges de travail à budget élevé, contenant des données sensibles, destinées aux partenaires ou utilisant des outils devraient nécessiter un examen plus strict que les tâches de synthèse interne à faible risque.

Approvisionnement

Créez le compte de service interne, la liaison du fournisseur, le budget, la stratégie de modèle, le récepteur d'audit et l'approbation secrète ou de fédération. Provisionnement via l'automatisation plutôt que le travail manuel sur la console lorsque cela est possible.

Livraison secrète

Si une clé statique est requise, fournissez-la uniquement à un gestionnaire de secrets centralisé ou à une plate-forme de déploiement. N'envoyez pas de clés via le chat, les tickets, les fichiers locaux ou les pages de documentation.

Avis

Examinez les comptes de service à une cadence fixe. Confirmez l'équipe propriétaire, la dernière utilisation, les autorisations, le budget, l'accès au modèle, la politique de données et si les clés statiques peuvent être remplacées par la fédération.

Désactiver et supprimer

Désactivez les comptes de service inutilisés avant la suppression. Cela crée une fenêtre de récupération si une dépendance de charge de travail a été manquée. Après la période de quarantaine, supprimez le compte et révoquez toutes les liaisons et tous les secrets du fournisseur.

Enregistrer les événements dont les auditeurs et les intervenants ont besoin

Les journaux d'audit doivent couvrir à la fois l'activité du plan de contrôle et celle du plan de données. Au minimum, connectez-vous :

• Création, mise à jour, désactivation et suppression d'un compte de service.
• Création, lecture, rotation et révocation des identifiants.
• Création d'une approbation de fédération et modifications de la politique de revendication.
• Modifications des autorisations, de l'accès au modèle, de l'accès aux points de terminaison et de la stratégie de données.
• Chaque requête LLM avec compte de service, locataire, modèle, fournisseur, utilisation du jeton, coût estimé, statut et objectif de la requête.
• Événements de seuil budgétaire, blocages de limites strictes et remplacements manuels.
• Admin API appels qui affectent les projets du fournisseur, les espaces de travail, les comptes de service ou les clés.

Envoyez ces événements à un flux d'audit immuable ou inviolable. Séparez la télémétrie des demandes à cardinalité élevée des preuves d'audit à longue conservation si cela permet de contrôler les coûts de stockage, mais conservez les clés de jointure nécessaires aux enquêtes.

Plan de migration à partir de clés partagées

Le remplacement des clés partagées peut être effectué de manière incrémentielle. Évitez une migration big-bang à moins que la clé ne soit déjà compromise.

1. Identifiez les clés partagées les plus utilisées. Classez-les par dépenses, trafic, accès au modèle et propriété inconnue.
2. Regroupez les appelants selon les limites de la charge de travail. Utilisez les journaux, les référentiels sources, les variables de déploiement, les agents utilisateurs et les données sources du réseau.
3. Créez des comptes de service limités. Commencez par des charges de travail de production qui ont des propriétaires clairs et des dépenses ou des risques élevés.
4. Acheminer via la passerelle. Conservez temporairement l'ancienne clé du fournisseur derrière la passerelle si la migration directe du fournisseur prend plus de temps.
5. Attribution à double exécution. Comparez le trafic, les coûts, les erreurs, la latence et la facturation du fournisseur avant de procéder à un transfert complet.
6. Alternez les appelants. Mettez à jour les secrets de déploiement, les variables CI et la configuration des applications, une charge de travail à la fois.
7. Révoquer la clé partagée. Mettez d'abord en quarantaine si le rayon de l'explosion n'est pas clair, puis révoquez après la fenêtre d'observation.

L'objectif n'est pas simplement de faire tourner une clé. L'objectif est de remplacer l'accès ambigu par une identité, une politique, un budget et des preuves appartenant à la charge de travail.

Compromis à rendre explicites

Plus de comptes de service améliorent le contrôle mais augmentent l'administration. Les conventions de dénomination, les métadonnées de propriété, les tâches de nettoyage et les workflows de révision sont ce qui maintient le modèle utilisable.

La fédération réduit le risque de secret statique mais ajoute une dépendance au fournisseur d'identité. L'échange de jetons peut échouer en raison de modifications de l'émetteur, d'une dérive des revendications, d'un décalage d'horloge ou de modifications de la configuration du CI. Concevez des modes de défaillance et des alertes claires.

Les contrôles natifs des fournisseurs sont utiles mais incohérents. Certains fournisseurs exposent les projets, les espaces de travail, les comptes de service, les budgets ou la fédération différemment. Une couche d'identité au niveau de la passerelle fournit des politiques et des rapports cohérents, mais elle doit conserver le contexte en amont pour les enquêtes sur les quotas, la facturation et l'assistance.

Les informations d'identification de courte durée améliorent la sécurité mais ajoutent de la complexité à l'exécution. Mettez soigneusement en cache les jetons, respectez l'expiration et évitez que chaque requête LLM ne dépende d'un appel lent du plan de contrôle.

L'application centralisée améliore la gouvernance mais augmente la responsabilité de la plate-forme. Si la passerelle possède la politique, les budgets et l'attribution, elle doit être hautement observable et mature sur le plan opérationnel.

Liste de contrôle de mise en œuvre

• Créez un inventaire des clés humaines, des identités de charge de travail, des identités CI, des clés de partenaire et des identifiants de sécurité.
• Définissez une convention de dénomination avec l'application, l'environnement, l'équipe propriétaire et l'objectif.
• Utilisez un compte de service par limite de charge de travail de production.
• Liez chaque identité à des projets ou des espaces de travail de fournisseur restreints.
• Restreindre les familles de modèles, les points de terminaison, les régions, les politiques de données et les budgets.
• Préférez la fédération ou l'échange de jetons de courte durée lorsque cela est pris en charge.
• Stockez les clés statiques uniquement dans la gestion centralisée des secrets.
• Exiger des métadonnées d'attribution pour chaque requête.
• Définissez les budgets des comptes de service et les alertes d'anomalie.
• Enregistrer les événements d'identification, d'autorisation, de demande, de budget et de révocation.
• Désactivez les comptes inutilisés avant de les supprimer.
• Migrez les clés partagées par charge de travail, puis révoquez l'ancien identifiant.

Conclusion

La gouvernance des comptes de service LLM est le modèle opérationnel pour l'accès à l'IA en production. Traitez chaque appelant sans surveillance comme une identité de charge de travail avec un propriétaire, un objectif, une limite d'autorisation, un budget et un cycle de vie. Utilisez des comptes de service natifs du fournisseur là où ils sont utiles, préférez la fédération lorsque cela est pratique et normalisez l'identité au niveau de la passerelle afin que OpenAI, Anthropic, Gemini et les systèmes internes puissent être gouvernés de manière cohérente.

Prédiction : Les plates-formes LLM continueront de s'éloigner des clés statiques générales vers des modèles de compte de service et d'identité de charge de travail. Les équipes qui établissent désormais une propriété propre des charges de travail bénéficieront plus tard d'un chemin plus facile vers la fédération des fournisseurs, la préparation aux audits, la gouvernance des partenaires API et des contrôles de coûts fiables.

Lecture connexe

• API gouvernance clé pour les équipes