Cómo diseñar cuentas de servicio LLM para cargas de trabajo de producción

Las cargas de trabajo de Production LLM no deben autenticarse como personas. Un trabajo de CI, un servicio backend, un agente ejecutor, un procesador por lotes o una puerta de enlace orientada a los socios necesitan su propia identidad no humana con un propietario claro, un alcance limitado, un presupuesto, un registro de auditoría y una ruta de cierre. Sin ese modelo, una clave filtrada puede representar demasiados sistemas, la eliminación no elimina el acceso y los informes de uso no pueden explicar qué carga de trabajo generó costos o riesgos.

Esta guía brinda a los equipos de ingeniería y plataforma un diseño práctico para la gestión de cuentas de servicio LLM en las API de proveedores y puertas de enlace internas. Separa los datos verificados del proveedor de las recomendaciones de implementación y ofrece predicciones sobre dónde es probable que evolucione el modelo operativo.

¿Qué es una cuenta de servicio LLM?

Hecho: Las cuentas de servicio son identidades no humanas utilizadas por aplicaciones y cargas de trabajo en lugar de usuarios individuales. OpenAI API proyectos admiten cuentas de servicio con alcance de proyecto y API claves. Anthropic describe las cuentas de servicio como identidades no humanas nombradas dentro de una organización. Google Cloud IAM describe las cuentas de servicio como usuarios no humanos para aplicaciones y cargas de trabajo.

Para los sistemas LLM, una cuenta de servicio debe representar un límite de carga de trabajo: un servicio backend, una familia de flujo de trabajo de CI, un tiempo de ejecución de agente, una canalización por lotes o un nivel de integración de socio API. No debe representar a una persona, a una empresa completa ni a todas las aplicaciones de un entorno.

Un útil registro de cuenta de servicio responde cinco preguntas:

• ¿A qué aplicación o flujo de trabajo pertenece esta identidad?
• ¿En qué entorno se puede ejecutar?
• ¿Qué equipo es responsable de los costos, el acceso y los incidentes?
• ¿Qué modelos, puntos finales, herramientas, políticas de datos y regiones están permitidos?
• ¿Cómo se rota, revoca o reemplaza la credencial con la federación?

Cuándo crear una cuenta de servicio

Cree una cuenta de servicio cuando la persona que llama sea un software operativo en lugar de un ser humano. Los ejemplos comunes incluyen trabajos de CI/CD que ejecutan evaluaciones, servicios de producción API, trabajadores de procesamiento de documentos, copilotos de atención al cliente, colas de agentes autónomos, trabajos de enriquecimiento programados y plataformas de desarrollo internas que intermedian el acceso a LLM para muchos equipos.

No cree una nueva cuenta de servicio para cada desarrollador, cada experimento local o cada mensaje. La exploración humana está detrás de la identidad del usuario y de las credenciales de desarrollo de corta duración. La atribución a nivel de solicitud y a nivel de característica se puede capturar como metadatos de solicitud bajo la identidad de la carga de trabajo.

Una regla de decisión simple funciona bien:

• Si la persona que llama puede funcionar sin supervisión, utilice una cuenta de servicio.
• Si la persona que llama atiende tráfico de producción, utilice una cuenta de servicio por carga de trabajo y entorno.
• Si la persona que llama actúa en nombre de un cliente o socio, separe la identidad de la carga de trabajo de la identidad del inquilino delegado.
• Si la persona que llama es un ser humano que utiliza una consola o una computadora portátil, no lo oculte detrás de una cuenta de servicio de producción.

Comience con un inventario de identidad

La migración debe comenzar con un inventario, no con una rotación de claves. Los equipos a menudo descubren que los servicios de producción, los trabajos de preparación, los scripts locales, los canales de evaluación y las integraciones abandonadas utilizan una clave de proveedor. Rotar esa clave primero genera riesgo sin mejorar la propiedad.

Cree un inventario con estas categorías:

• Proveedor de propiedad humana API claves.
• Cuentas de servicio de carga de trabajo.
• Identidades de CI/CD.
• Claves internas emitidas por la puerta de enlace.
• Claves delegadas de socio o cliente.
• Credenciales de emergencia contra cristales.
• Claves desconocidas que aún producen uso.

Para cada credencial, proveedor de registros, proyecto o espacio de trabajo, propietario de clave, aplicación consumidora, entorno de implementación, ubicación secreta, modelos permitidos, propietario del gasto, marca de tiempo vista por última vez y riesgo de revocación. Este inventario se convierte en la fuente de verdad para la LLM API administración de claves, pero las cuentas de servicio deben modelarse como identidades de carga de trabajo de primera clase en lugar de simplemente otra etiqueta de clave.

Usar una cuenta de servicio por límite de carga de trabajo

La principal opción de diseño es la granularidad. Muy pocas cuentas de servicio crean un radio de explosión compartido. Demasiados crean ruido operativo. La unidad correcta es el límite de carga de trabajo más pequeño que tiene distintas necesidades de propiedad, permisos, perfil de costos o respuesta a incidentes.

Utilice cuentas de servicio independientes para:

• Entornos de producción y no producción.
• Diferentes aplicaciones propiedad de diferentes equipos.
• Servicios de cara al cliente versus trabajos internos.
• Rutas de solicitud interactivas frente a procesadores por lotes asíncronos.
• Tiempos de ejecución de agentes que pueden llamar a herramientas o ejecutar bucles.
• Partner API superficies que exponen el acceso delegado.

Un patrón de nomenclatura práctico es:

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

Ejemplos:

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

No codifique secretos, nombres de clientes, nombres personales ni números de tickets temporales en el nombre de la cuenta. En su lugar, coloque detalles mutables en etiquetas o metadatos.

Asignar cuentas de proveedor a un modelo de identidad de puerta de enlace

Hecho: Las capacidades de los proveedores difieren. OpenAI admite cuentas de servicio dentro de API proyectos, y las cuentas de servicio del proyecto son exclusivas del proyecto donde se crean. Anthropic espacios de trabajo pueden contener miembros, cuentas de servicio, API claves y límites de recursos. Anthropic la federación de identidades de cargas de trabajo permite que las cargas de trabajo utilicen tokens de identidad firmados en lugar de Anthropic credenciales estáticas, con límites de atribución y tasa vinculados al espacio de trabajo cuando se configura.

Recomendación: Mantenga un modelo de cuenta de servicio a nivel de puerta de enlace incluso cuando existan cuentas de servicio nativas del proveedor. La identidad de la puerta de enlace debe ser el objeto interno estable al que se adjuntan las políticas, los informes, los presupuestos y la evidencia de auditoría. Las credenciales del proveedor son los detalles de implementación asignados debajo.

Por ejemplo:

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

Esta asignación es importante en una puerta de enlace de IA API multimodelo porque los proveedores ascendentes exponen diferentes estructuras de cuentas, campos de facturación, permisos de modelo y opciones de federación. Una única capa de identidad interna permite a los equipos aplicar un contrato de política y al mismo tiempo preservar el contexto específico del proveedor para la resolución de problemas.

Permisos de alcance limitado

El alcance de una cuenta de servicio debe basarse en lo que necesita la carga de trabajo, no en lo que permite la clave del proveedor. Como mínimo, defina el alcance en estas dimensiones:

• Límite del proveedor: qué proveedores y proyectos de proveedores o espacios de trabajo se pueden utilizar.
• Límite del modelo: familias de modelos, versiones, modelos de vista previa y modelos alternativos permitidos.
• Límite del punto final: chat, respuestas, incrustaciones, lotes, archivos, ajustes, asistentes, herramientas o API de administración.
• Límite del entorno: desarrollo, puesta en escena, producción, sandbox o socio.
• Límite de datos: política de retención, región, clase de datos confidenciales y funciones con estado permitidas.
• Límite presupuestario: alertas suaves, límites estrictos, límites por minuto y límites mensuales.
• Límite de red: redes de origen, identidades de carga de trabajo o plataformas de implementación aceptadas.

Los permisos administrativos API casi nunca deberían estar disponibles para las cuentas de servicio de tiempo de ejecución. Separe la automatización del aprovisionamiento de las cargas de trabajo de inferencia. Un servicio backend que envía mensajes no debería poder crear nuevas claves de proveedor, cambiar presupuestos ni otorgar acceso al modelo.

Prefiera la federación a las claves estáticas cuando sea práctico

Hecho: Anthropic documenta la federación de identidades de cargas de trabajo como una forma para que las cargas de trabajo utilicen tokens de identidad firmados en lugar de Anthropic credenciales estáticas. Google Cloud advierte que las claves de cuentas de servicio administradas por el usuario representan riesgos para la seguridad si no se administran con cuidado y recomienda alternativas más seguras siempre que sea posible. OWASP recomienda el almacenamiento secreto centralizado, la auditoría de las solicitudes y el uso secreto, la rotación, la revocación y el vencimiento cuando sea posible.

Recomendación: Prefiera la federación de identidades de cargas de trabajo o el intercambio de tokens de corta duración para servicios alojados en la nube y sistemas CI/CD donde exista soporte del proveedor. Utilice claves estáticas API solo cuando la federación no esté disponible, no sea compatible con la ruta del proveedor que necesita o no esté operativamente justificada para una carga de trabajo de bajo riesgo.

Un flujo de federación normalmente tiene este aspecto:

1. La carga de trabajo se ejecuta bajo una nube, CI o proveedor de identidad principal.
2. La carga de trabajo obtiene un token de identidad firmado de ese proveedor de identidad ascendente.
3. El proveedor de LLM o el portal interno valida el emisor, la audiencia, el tema y las reclamaciones.
4. La puerta de enlace asigna el token a una cuenta de servicio interna.
5. La puerta de enlace emite una sesión de corta duración o autoriza directamente la solicitud de LLM.

Validar más que el emisor. Verifique la audiencia, el tema, el repositorio o la ruta de la carga de trabajo, el entorno, la rama o las reclamaciones de implementación cuando estén disponibles y la vida útil del token. La federación traslada el riesgo de la filtración estática de secretos a la configuración del proveedor de identidad. Las afirmaciones débiles, las políticas de confianza amplias o los entornos de CI permisivos aún pueden otorgar acceso no deseado.

Requerir metadatos de atribución en cada solicitud

Las cuentas de servicio identifican la carga de trabajo, pero no deben ser el único campo de atribución. Las solicitudes de LLM de producción necesitan suficientes metadatos para responder preguntas operativas rápidamente.

Requerir estos campos en la puerta de enlace:

• service_account_id
• app
• environment
• owner_team
• deployment_id o versión de lanzamiento
• request_purpose, como chat, extracción, clasificación, evaluación o agent_tool_use
• tenant_id o identificador de cliente cuando corresponda
• workflow_id o identificador de trabajo para trabajo asincrónico

Estos campos admiten LLM API atribución de costos, respuesta a incidentes, decisiones de límite de tarifas y conciliación de facturas de proveedores. También evitan el modo de error común en el que cada solicitud de una clave compartida se etiqueta solo como "backend".

Adjuntar presupuestos y alertas a identidades de carga de trabajo

Las cuentas de servicio a menudo se ejecutan desatendidas. Eso hace que los controles de costos sean más importantes, no menos. Un usuario puede notar una sesión de chat fuera de control. Un agente programado o un reintento de un trabajo por lotes pueden agotar el presupuesto de la noche a la mañana.

Establecer presupuestos en varias capas:

• Presupuesto del proyecto o espacio de trabajo del proveedor donde sea compatible.
• Presupuesto mensual a nivel de puerta de enlace por cuenta de servicio.
• Detección de anomalías en ventanas cortas para picos repentinos.
• Costo máximo estimado por solicitud o por trabajo.
• Límites separados para cargas de trabajo de producción, preparación, CI y evaluación.

Utilice diferentes acciones para diferentes umbrales. Al 50 por ciento, notifique al equipo propietario. Al 80 por ciento, requiere reconocimiento. Al 100 por ciento, bloquee las solicitudes no críticas, cambie a modelos aprobados más baratos o solicite una anulación explícita. El comportamiento correcto depende de si la carga de trabajo está orientada al cliente, es interna, por lotes o es crítica para la seguridad.

Diseñar el flujo de trabajo del ciclo de vida

Una cuenta de servicio sin controles de ciclo de vida se convierte en otro secreto no administrado. Defina el flujo de trabajo antes de una adopción generalizada.

Solicitud

El solicitante debe proporcionar el nombre de la aplicación, el entorno, el equipo propietario, el propósito comercial, el gasto mensual esperado, la clasificación de datos, los requisitos del modelo, los requisitos del punto final y si es posible la federación.

Aprobación

La aprobación debe provenir del equipo propietario y de la plataforma o de la política de seguridad. Las cargas de trabajo de alto presupuesto, datos confidenciales, de cara a socios o que utilizan herramientas deberían requerir una revisión más estricta que los trabajos de resumen interno de bajo riesgo.

Aprovisionamiento

Cree la cuenta de servicio interna, el enlace del proveedor, el presupuesto, la política modelo, el receptor de auditoría y el secreto o la confianza de federación. Aprovisionamiento mediante automatización en lugar de trabajo manual de consola cuando sea posible.

Entrega secreta

Si se requiere una clave estática, entréguela únicamente a un administrador secreto centralizado o a una plataforma de implementación. No envíe claves a través de chat, tickets, archivos locales o páginas de documentación.

Revisión

Revisar cuentas de servicio con una cadencia fija. Confirme el equipo propietario, el último uso, los permisos, el presupuesto, el acceso al modelo, la política de datos y si las claves estáticas se pueden reemplazar con la federación.

Desactivar y eliminar

Deshabilite las cuentas de servicio no utilizadas antes de eliminarlas. Esto crea una ventana de recuperación si se omitió una dependencia de la carga de trabajo. Después del período de cuarentena, elimine la cuenta y revoque todos los secretos y vinculaciones del proveedor.

Registrar los eventos que necesitan los auditores y el personal de respuesta

Los registros de auditoría deben cubrir tanto la actividad del plano de control como la del plano de datos. Como mínimo, registre:

• Creación, actualización, desactivación y eliminación de cuentas de servicio.
• Creación, lectura, rotación y revocación de credenciales.
• Creación de confianza de federación y cambios en la política de reclamos.
• Cambios en permisos, acceso a modelos, acceso a puntos finales y políticas de datos.
• Cada solicitud de LLM con cuenta de servicio, inquilino, modelo, proveedor, uso de token, costo estimado, estado y propósito de la solicitud.
• Eventos de umbral presupuestario, bloqueos de límite estricto y anulaciones manuales.
• Administrador API llamadas que afectan proyectos de proveedores, espacios de trabajo, cuentas de servicio o claves.

Envíe estos eventos a un flujo de auditoría inmutable o resistente a manipulaciones. Mantenga la telemetría de solicitud de alta cardinalidad separada de la evidencia de auditoría de retención prolongada si eso ayuda a controlar el costo de almacenamiento, pero conserve las claves de unión necesarias para las investigaciones.

Plan de migración desde claves compartidas

La sustitución de claves compartidas se puede realizar de forma incremental. Evite una migración importante a menos que la clave ya esté comprometida.

1. Identifique las claves compartidas más ocupadas. Clasifique por gasto, tráfico, acceso al modelo y propiedad desconocida.
2. Agrupe a las personas que llaman en límites de carga de trabajo. Utilice registros, repositorios de origen, variables de implementación, agentes de usuario y datos de origen de red.
3. Cree cuentas de servicio con ámbito. Comience con cargas de trabajo de producción que tengan propietarios claros y un alto gasto o alto riesgo.
4. Enrutar a través de la puerta de enlace. Conserve temporalmente la clave de proveedor anterior detrás de la puerta de enlace si la migración directa del proveedor tardaría más.
5. Atribución de doble ejecución. Compare el tráfico, el costo, los errores, la latencia y la facturación del proveedor antes de realizar el corte por completo.
6. Rotar a las personas que llaman. Actualice los secretos de implementación, las variables de CI y la configuración de la aplicación, una carga de trabajo a la vez.
7. Revocar la clave compartida. Poner en cuarentena primero si el radio de la explosión no está claro, luego revocar después de la ventana de observación.

El objetivo no es simplemente rotar una clave. El objetivo es reemplazar el acceso ambiguo con identidades, políticas, presupuestos y pruebas de propiedad de la carga de trabajo.

Compensaciones que se deben hacer explícitas

Más cuentas de servicio mejoran el control pero aumentan la administración. Las convenciones de nomenclatura, los metadatos de propiedad, los trabajos de limpieza y los flujos de trabajo de revisión son los que mantienen el modelo utilizable.

La federación reduce el riesgo de secreto estático pero agrega dependencia del proveedor de identidad. El intercambio de tokens puede fallar debido a cambios de emisor, deriva de reclamos, desfase del reloj o cambios en la configuración de CI. Diseñe alertas y modos de fallo claros.

Los controles nativos del proveedor son valiosos pero inconsistentes. Algunos proveedores exponen proyectos, espacios de trabajo, cuentas de servicio, presupuestos o federaciones de manera diferente. Una capa de identidad a nivel de puerta de enlace proporciona políticas e informes coherentes, pero debe conservar el contexto ascendente para las investigaciones de cuotas, facturación y soporte.

Las credenciales de corta duración mejoran la seguridad, pero añaden complejidad al tiempo de ejecución. Almacene en caché los tokens con cuidado, respete la caducidad y evite que cada solicitud de LLM dependa de una llamada lenta al plano de control.

La aplicación centralizada mejora la gobernanza pero aumenta la responsabilidad de la plataforma. Si la puerta de enlace posee políticas, presupuestos y atribuciones, debe ser altamente observable y operativamente madura.

Lista de verificación de implementación

• Cree un inventario de claves humanas, identidades de cargas de trabajo, identidades de CI, claves de socios y credenciales de emergencia.
• Defina una convención de nomenclatura con aplicación, entorno, equipo propietario y propósito.
• Utilice una cuenta de servicio por límite de carga de trabajo de producción.
• Vincular cada identidad a espacios de trabajo o proyectos de proveedores limitados.
• Restringir familias de modelos, puntos finales, regiones, políticas de datos y presupuestos.
• Prefiere la federación o el intercambio de tokens de corta duración cuando sea compatible.
• Almacena claves estáticas solo en la gestión secreta centralizada.
• Requerir metadatos de atribución en cada solicitud.
• Establecer presupuestos de cuentas de servicio y alertas de anomalías.
• Registrar eventos de credenciales, permisos, solicitudes, presupuestos y revocaciones.
• Deshabilite las cuentas no utilizadas antes de eliminarlas.
• Migrar claves compartidas por carga de trabajo y luego revocar la credencial anterior.

Conclusión

La gobernanza de cuentas de servicio LLM es el modelo operativo para el acceso a la IA de producción. Trate a cada persona que llama desatendida como una identidad de carga de trabajo con un propietario, propósito, límite de permiso, presupuesto y ciclo de vida. Utilice cuentas de servicios nativas del proveedor cuando sean útiles, prefiera la federación cuando sea práctico y normalice la identidad en la puerta de enlace para que OpenAI, Anthropic, Gemini y los sistemas internos puedan gobernarse de manera consistente.

Predicción: Las plataformas LLM seguirán alejándose de claves estáticas amplias hacia modelos de cuenta de servicio y de identidad de carga de trabajo. Los equipos que establezcan una propiedad limpia de la carga de trabajo ahora tendrán un camino más fácil hacia la federación de proveedores, la preparación para auditorías, la gobernanza del socio API y controles de costos confiables en el futuro.

Lecturas relacionadas

• API gobernanza clave para los equipos