Como projetar contas de serviço LLM para cargas de trabalho de produção

As cargas de trabalho do Production LLM não devem ser autenticadas como pessoas. Um trabalho de CI, serviço de back-end, executor de agente, processador em lote ou gateway voltado para parceiro precisa de sua própria identidade não humana com um proprietário claro, escopo restrito, orçamento, trilha de auditoria e caminho de encerramento. Sem esse modelo, uma chave vazada pode representar muitos sistemas, a exclusão não remove o acesso e os relatórios de uso não podem explicar qual carga de trabalho criou custo ou risco.

Este guia oferece às equipes de engenharia e plataforma um design prático para governança de contas de serviço LLM em APIs de provedores e gateways internos. Ele separa os fatos verificados do fornecedor das recomendações de implementação e faz previsões sobre onde o modelo operacional provavelmente evoluirá.

O que é uma conta de serviço LLM?

Fato: contas de serviço são identidades não humanas usadas por aplicativos e cargas de trabalho, em vez de usuários individuais. OpenAI API projetos oferecem suporte a contas de serviço com escopo de projeto e API chaves. Anthropic descreve contas de serviço como identidades não humanas nomeadas dentro de uma organização. Google O Cloud IAM descreve as contas de serviço como usuários não humanos para aplicativos e cargas de trabalho.

Para sistemas LLM, uma conta de serviço deve representar um limite de carga de trabalho: um serviço de back-end, uma família de fluxo de trabalho de CI, um tempo de execução de agente, um pipeline em lote ou um nível de integração de parceiro API. Ele não deve representar uma pessoa, uma empresa inteira ou todos os aplicativos em um ambiente.

Um registro de conta de serviço útil responde a cinco perguntas:

• Qual aplicativo ou fluxo de trabalho possui esta identidade?
• Em qual ambiente ele pode ser executado?
• Qual equipe é responsável pelos custos, acesso e incidentes?
• Quais modelos, endpoints, ferramentas, políticas de dados e regiões são permitidos?
• Como a credencial é alternada, revogada ou substituída pela federação?

Quando criar uma conta de serviço

Crie uma conta de serviço quando o chamador for um software operacional e não um ser humano. Exemplos comuns incluem trabalhos de CI/CD que executam avaliações, serviços de produção API, trabalhadores de processamento de documentos, copilotos de suporte ao cliente, filas de agentes autônomos, trabalhos de enriquecimento programados e plataformas internas de desenvolvedores que intermediam o acesso LLM para muitas equipes.

Não crie uma nova conta de serviço para cada desenvolvedor, cada experimento local ou cada solicitação. A exploração humana está por trás da identidade do usuário e das credenciais de desenvolvimento de curta duração. A atribuição em nível de prompt e em nível de recurso pode ser capturada como metadados de solicitação na identidade da carga de trabalho.

Uma regra de decisão simples funciona bem:

• Se o chamador puder funcionar sem supervisão, use uma conta de serviço.
• Se o chamador atender tráfego de produção, use uma conta de serviço por carga de trabalho e ambiente.
• Se o chamador atuar em nome de um cliente ou parceiro, separe a identidade da carga de trabalho da identidade delegada do locatário.
• Se o chamador for um ser humano usando um console ou notebook, não esconda isso atrás de uma conta de serviço de produção.

Comece com um inventário de identidade

A migração deve começar com um inventário, não com a rotação de chaves. As equipes geralmente descobrem que uma chave de provedor é usada por serviços de produção, trabalhos de preparo, scripts locais, pipelines de avaliação e integrações abandonadas. A rotação dessa chave primeiro cria riscos sem melhorar a propriedade.

Crie um inventário com estas categorias:

• Provedor de propriedade humana API chaves.
• Contas de serviço de carga de trabalho.
• Identidades CI/CD.
• Chaves internas emitidas pelo gateway.
• Chaves delegadas por parceiros ou clientes.
• Credenciais de emergência.
• Chaves desconhecidas que ainda produzem uso.

Para cada credencial, provedor de registros, projeto ou espaço de trabalho, proprietário da chave, aplicativo consumidor, ambiente de implantação, local secreto, modelos permitidos, proprietário do gasto, carimbo de data/hora da última visualização e risco de revogação. Esse inventário se torna a fonte da verdade para LLM API gerenciamento de chaves, mas as contas de serviço devem ser modeladas como identidades de carga de trabalho de primeira classe, em vez de apenas outro rótulo de chave.

Use uma conta de serviço por limite de carga de trabalho

A principal escolha de design é a granularidade. Poucas contas de serviço criam um raio de explosão compartilhado. Muitos criam ruído operacional. A unidade certa é o menor limite de carga de trabalho que tem propriedade, permissões, perfil de custo ou necessidades de resposta a incidentes distintos.

Use contas de serviço separadas para:

• Ambientes de produção e não produção.
• Aplicativos diferentes pertencentes a equipes diferentes.
• Serviços voltados para o cliente versus trabalhos internos.
• Caminhos de solicitação interativos versus processadores em lote assíncronos.
• Tempos de execução do agente que podem chamar ferramentas ou executar loops.
• Parceiro API superfícies que expõem o acesso delegado.

Um padrão de nomenclatura prático é:

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

Exemplos:

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

Não codifique segredos, nomes de clientes, nomes pessoais ou números de tickets temporários no nome da conta. Em vez disso, coloque detalhes mutáveis em tags ou metadados.

Mapear contas de provedor para um modelo de identidade de gateway

Fato: As capacidades do provedor são diferentes. OpenAI oferece suporte a contas de serviço em API projetos, e as contas de serviço do projeto são exclusivas do projeto onde foram criadas. Anthropic espaços de trabalho podem conter membros, contas de serviço, API chaves e limites de recursos. Anthropic a federação de identidade de carga de trabalho permite que cargas de trabalho usem tokens de identidade assinados em vez de Anthropic credenciais estáticas, com limites de atribuição e taxa vinculados ao espaço de trabalho quando configurado.

Recomendação: Mantenha um modelo de conta de serviço no nível do gateway mesmo quando existirem contas de serviço nativas do provedor. A identidade do gateway deve ser o objeto interno estável ao qual estão associadas políticas, relatórios, orçamentos e evidências de auditoria. As credenciais do provedor são detalhes de implementação mapeados abaixo delas.

Por exemplo:

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

Esse mapeamento é importante em uma IA multimodelo API gateway porque os provedores upstream expõem diferentes estruturas de conta, campos de cobrança, permissões de modelo e opções de federação. Uma única camada de identidade interna permite que as equipes apliquem um contrato de política enquanto preservam o contexto específico do provedor para solução de problemas.

Escopo restrito das permissões

Uma conta de serviço deve ter como escopo o que a carga de trabalho precisa, e não o que a chave do provedor permite. No mínimo, defina o escopo nessas dimensões:

• Limite do provedor: quais provedores e projetos de provedores ou espaços de trabalho podem ser usados.
• Limite do modelo: famílias de modelos, versões, modelos de visualização e modelos substitutos permitidos.
• Limite do endpoint: bate-papo, respostas, incorporações, lote, arquivos, ajuste fino, assistentes, ferramentas ou APIs administrativas.
• Limite do ambiente: desenvolvimento, preparação, produção, sandbox ou parceiro.
• Limite de dados: política de retenção, região, classe de dados confidenciais e recursos com estado permitidos.
• Limite do orçamento: alertas flexíveis, limites rígidos, limites por minuto e limites mensais.
• Limite da rede: redes de origem, identidades de carga de trabalho ou plataformas de implantação aceitas.

Administrativas API quase nunca devem estar disponíveis para contas de serviço de tempo de execução. Separe a automação de provisionamento das cargas de trabalho de inferência. Um serviço de back-end que envia prompts também não deve ser capaz de criar novas chaves de provedor, alterar orçamentos ou conceder acesso a modelos.

Prefira a federação em vez de chaves estáticas quando for prático

Fato: Anthropic documenta a federação de identidade da carga de trabalho como uma forma de as cargas de trabalho usarem tokens de identidade assinados em vez de Anthropic credenciais estáticas. Google Cloud alerta que chaves de contas de serviço gerenciadas pelo usuário são riscos de segurança se não forem gerenciadas com cuidado e recomenda alternativas mais seguras sempre que possível. A OWASP recomenda armazenamento centralizado de segredos, auditoria de solicitações e uso de segredos, rotação, revogação e expiração sempre que possível.

Recomendação: Prefira federação de identidade de carga de trabalho ou troca de token de curta duração para serviços hospedados em nuvem e sistemas CI/CD onde existe suporte do provedor. Use chaves estáticas API somente quando a federação não estiver disponível, não for suportada pelo caminho do provedor necessário ou operacionalmente injustificada para uma carga de trabalho de baixo risco.

Um fluxo de federação geralmente se parece com isto:

1. A carga de trabalho é executada em uma nuvem, CI ou entidade principal do provedor de identidade.
2. A carga de trabalho obtém um token de identidade assinado desse provedor de identidade upstream.
3. O provedor LLM ou gateway interno valida o emissor, o público, o assunto e as declarações.
4. O gateway mapeia o token para uma conta de serviço interna.
5. O gateway emite uma sessão de curta duração ou autoriza diretamente a solicitação LLM.

Valida mais do que o emissor. Verifique o público, o assunto, o repositório ou o caminho da carga de trabalho, o ambiente, as declarações de ramificação ou de implantação, quando disponíveis, e a vida útil do token. A federação transfere o risco do vazamento estático de segredos para a configuração do provedor de identidade. Declarações fracas, políticas de confiança amplas ou ambientes de CI permissivos ainda podem conceder acesso não intencional.

Exigir metadados de atribuição em cada solicitação

As contas de serviço identificam a carga de trabalho, mas não devem ser o único campo de atribuição. As solicitações de LLM de produção precisam de metadados suficientes para responder rapidamente a perguntas operacionais.

Exigir estes campos no gateway:

• service_account_id
• app
• environment
• owner_team
• deployment_id ou versão de lançamento
• request_purpose, como bate-papo, extração, classificação, avaliação ou agent_tool_use
• tenant_id ou identificador do cliente quando aplicável
• workflow_id ou identificador de trabalho para trabalho assíncrono

Esses campos suportam LLM API atribuição de custos, resposta a incidentes, decisões de limite de taxa e reconciliação de faturas do fornecedor. Eles também evitam o modo de falha comum em que cada solicitação de uma chave compartilhada é rotulada apenas como “backend”.

Anexar orçamentos e alertas a identidades de carga de trabalho

As contas de serviço geralmente são executadas sem supervisão. Isso torna os controles de custos mais importantes, e não menos. Um usuário pode perceber uma sessão de bate-papo descontrolada. Um agente agendado ou uma nova tentativa de trabalho em lote podem esgotar o orçamento durante a noite.

Definir orçamentos em várias camadas:

• Orçamento do projeto do provedor ou do espaço de trabalho quando houver suporte.
• Orçamento mensal no nível do gateway por conta de serviço.
• Detecção de anomalias em janela curta para picos repentinos.
• Custo máximo estimado por solicitação ou por trabalho.
• Limites separados para cargas de trabalho de produção, preparação, CI e avaliação.

Use ações diferentes para limites diferentes. Com 50 por cento, notifique a equipe proprietária. Em 80 por cento, exija reconhecimento. Em 100%, bloqueie solicitações não críticas, faça downgrade para modelos aprovados mais baratos ou exija substituição explícita. O comportamento correto depende se a carga de trabalho é voltada para o cliente, interna, em lote ou crítica para a segurança.

Projetar o fluxo de trabalho do ciclo de vida

Uma conta de serviço sem controles de ciclo de vida se torna outro segredo não gerenciado. Defina o fluxo de trabalho antes da ampla adoção.

Solicitação

O solicitante deve fornecer o nome do aplicativo, ambiente, equipe proprietária, finalidade comercial, gasto mensal esperado, classificação de dados, requisitos de modelo, requisitos de endpoint e se a federação é possível.

Aprovação

A aprovação deve vir da equipe proprietária e da plataforma ou política de segurança. Cargas de trabalho de alto orçamento, dados confidenciais, voltadas para parceiros ou que usam ferramentas devem exigir uma revisão mais rigorosa do que trabalhos de resumo interno de baixo risco.

Provisionamento

Crie a conta de serviço interna, a vinculação do provedor, o orçamento, a política de modelo, o coletor de auditoria e o segredo ou confiança de federação. Provisão por meio de automação em vez de trabalho manual no console sempre que possível.

Entrega secreta

Se uma chave estática for necessária, entregue-a somente a um gerenciador de segredos centralizado ou plataforma de implantação. Não envie chaves por chat, tickets, arquivos locais ou páginas de documentação.

Revisão

Revisar contas de serviço em uma cadência fixa. Confirme a equipe proprietária, último uso, permissões, orçamento, acesso ao modelo, política de dados e se as chaves estáticas podem ser substituídas pela federação.

Desativar e excluir

Desative contas de serviço não utilizadas antes da exclusão. Isto cria uma janela de recuperação se uma dependência de carga de trabalho for perdida. Após o período de quarentena, exclua a conta e revogue todas as vinculações e segredos do provedor.

Registre os eventos que os auditores e respondentes precisam

Os registros de auditoria devem abranger as atividades do plano de controle e do plano de dados. No mínimo, registre:

• Criação, atualização, desativação e exclusão de contas de serviço.
• Criação, leitura, rotação e revogação de credenciais.
• Criação de confiança da federação e alterações na política de reivindicação.
• Alterações de permissão, acesso de modelo, acesso de endpoint e política de dados.
• Cada solicitação LLM com conta de serviço, locatário, modelo, provedor, uso de token, custo estimado, status e finalidade da solicitação.
• Eventos de limite de orçamento, bloqueios de limite rígido e substituições manuais.
• Chamadas de administrador API que afetam projetos de provedores, espaços de trabalho, contas de serviço ou chaves.

Envie esses eventos para um fluxo de auditoria imutável ou resistente a violações. Mantenha a telemetria de solicitação de alta cardinalidade separada das evidências de auditoria de longa retenção, se isso ajudar a controlar o custo de armazenamento, mas preserve as chaves de junção necessárias para as investigações.

Plano de migração de chaves compartilhadas

A substituição de chaves compartilhadas pode ser feita de forma incremental. Evite uma migração big bang, a menos que a chave já esteja comprometida.

1. Identifique as chaves compartilhadas mais ocupadas. Classifique por gasto, tráfego, acesso ao modelo e propriedade desconhecida.
2. Agrupe os chamadores em limites de carga de trabalho. Use registros, repositórios de origem, variáveis de implantação, agentes de usuário e dados de origem de rede.
3. Crie contas de serviço com escopo definido. Comece com cargas de trabalho de produção que tenham proprietários claros e alto gasto ou alto risco.
4. Rota através do gateway. Preservar temporariamente a chave do provedor antigo atrás do gateway se a migração direta do provedor levar mais tempo.
5. Atribuição de execução dupla. Compare tráfego, custo, erros, latência e faturamento do provedor antes de cortar totalmente.
6. Alterne os chamadores. Atualize os segredos de implantação, as variáveis de CI e a configuração do aplicativo, uma carga de trabalho por vez.
7. Revogue a chave compartilhada. Coloque a quarentena primeiro se o raio da explosão não estiver claro e, em seguida, revogue após a janela de observação.

O objetivo não é apenas girar uma chave. O objetivo é substituir o acesso ambíguo por identidade, política, orçamento e evidências de propriedade da carga de trabalho.

Compensações a serem explícitas

Mais contas de serviço melhoram o controle, mas aumentam a administração. Convenções de nomenclatura, metadados de propriedade, trabalhos de limpeza e fluxos de trabalho de revisão são o que mantém o modelo utilizável.

A federação reduz o risco de segredo estático, mas adiciona dependência do provedor de identidade. A troca de token pode falhar devido a alterações no emissor, desvio de declaração, distorção de relógio ou alterações na configuração do CI. Projete alertas e modos de falha claros.

Os controles nativos do provedor são valiosos, mas inconsistentes. Alguns provedores expõem projetos, espaços de trabalho, contas de serviço, orçamentos ou federação de maneira diferente. Uma camada de identidade no nível do gateway fornece políticas e relatórios consistentes, mas deve reter o contexto upstream para cotas, faturamento e investigações de suporte.

Credenciais de curta duração melhoram a segurança, mas aumentam a complexidade do tempo de execução. Armazene os tokens em cache com cuidado, respeite a expiração e evite fazer com que cada solicitação LLM dependa de uma chamada lenta do plano de controle.

A aplicação centralizada melhora a governança, mas aumenta a responsabilidade da plataforma. Se o gateway possuir políticas, orçamentos e atribuições, ele deverá ser altamente observável e operacionalmente maduro.

Lista de verificação de implementação

• Crie um inventário de chaves humanas, identidades de carga de trabalho, identidades de CI, chaves de parceiros e credenciais de segurança.
• Defina uma convenção de nomenclatura com aplicativo, ambiente, equipe proprietária e finalidade.
• Use uma conta de serviço por limite de carga de trabalho de produção.
• Vincule cada identidade a projetos ou espaços de trabalho restritos do provedor.
• Restringir famílias de modelos, endpoints, regiões, políticas de dados e orçamentos.
• Prefira federação ou troca de tokens de curta duração quando houver suporte.
• Armazene chaves estáticas somente no gerenciamento centralizado de segredos.
• Exigir metadados de atribuição em cada solicitação.
• Definir orçamentos de contas de serviço e alertas de anomalias.
• Registre eventos de credencial, permissão, solicitação, orçamento e revogação.
• Desative contas não utilizadas antes de excluí-las.
• Migre chaves compartilhadas por carga de trabalho e revogue a credencial antiga.

Conclusão

A governança da conta de serviço LLM é o modelo operacional para acesso à IA de produção. Trate cada chamador não atendido como uma identidade de carga de trabalho com proprietário, finalidade, limite de permissão, orçamento e ciclo de vida. Use contas de serviço nativas do provedor onde elas ajudarem, prefira a federação onde for prático e normalize a identidade no gateway para que OpenAI, Anthropic, Gemini e sistemas internos possam ser governados de forma consistente.

Previsão: As plataformas LLM continuarão se afastando de chaves estáticas amplas em direção a modelos de contas de serviço e de identidade de carga de trabalho. As equipes que estabelecerem propriedade limpa da carga de trabalho agora terão um caminho mais fácil para a federação de provedores, preparação para auditoria, governança de parceiros API e controles de custos confiáveis ​​posteriormente.

Leitura relacionada

• API governança principal para equipes