Contas de serviço para agentes de IA sem responsabilidade compartilhada

Agentes de IA precisam de contas de serviço, mas uma conta de serviço nunca deve virar o nome que você usa quando não sabe quem autorizou uma ação. Dê a cada fluxo duradouro sua própria identidade, coloque uma pessoa identificada por trás dela e remova-a quando o fluxo terminar. Qualquer coisa mais fraca cria responsabilidade compartilhada, outra forma de dizer que ninguém consegue dar uma resposta completa depois de uma decisão ruim.

Já vi isso falhar de uma maneira conhecida. Uma equipe cria uma conta chamada automation, dá a ela acesso suficiente para desbloquear vários trabalhos de programação e chama a configuração de temporária. Meses depois, um trabalho de implantação, um atualizador de dependências e um agente que edita a infraestrutura usam a mesma conta. Ela continua ativa porque desativá-la pode quebrar alguma coisa. Quando altera uma configuração de produção, os logs identificam automation perfeitamente e explicam quase nada.

A solução não é um grande programa de identidade. São alguns limites claros: uma identidade de fluxo para uma finalidade de permissão, uma pessoa responsável que possa aprovar ou interromper o trabalho, evidências que liguem cada uso a uma execução específica e um caminho de saída planejado antes que a conta receba acesso.

Uma conta de serviço identifica a autoridade, não o autor da ação

Uma conta de serviço informa qual conjunto de permissões uma API ou sistema aceitou; ela não prova qual agente, prompt, revisão de código ou pessoa causou a solicitação. As equipes costumam misturar essas duas funções e depois descobrem que seu histórico de auditoria não consegue explicar um incidente.

Suponha que release-publisher possa publicar artefatos de compilação. Uma solicitação bem-sucedida autenticada com essa conta informa que a autoridade de publicação foi usada. Ela não diz se uma rotina de lançamento aprovada fez a solicitação, se um desenvolvedor executou um script local ou se um agente repetiu uma tarefa antiga depois que seu responsável humano foi embora. O registro de autenticação responde «qual autoridade?». Ele não responde «por que esta chamada, nesta execução, agora?»

Mantenha as camadas separadas:

• A identidade do fluxo contém uma autoridade definida de forma restrita.
• A sessão do agente identifica uma execução específica do processo.
• A aprovação humana ou o gatilho de automação explica quem iniciou ou permitiu essa execução.
• O registro da ação captura o alvo, a operação solicitada, o resultado e o horário.

Essa distinção muda a forma de investigar. Se uma chamada de implantação parecer errada, primeiro desative a identidade do fluxo para interromper novas ações com aquela autoridade. Depois examine o registro da sessão para encontrar o processo que a usou, a revisão do código executada e a pessoa ou sistema que autorizou a sessão. Um único nome de conta não consegue carregar todo esse histórico sem virar um depósito compartilhado.

A RFC 6749 faz uma observação útil, mas limitada, ao descrever a concessão de credenciais de cliente do OAuth 2.0: um cliente pode usar suas credenciais como uma concessão de autorização quando age em seu próprio nome. Isso está correto para uma carga de trabalho de máquina bem delimitada. Não significa que todo processo capaz de apresentar a credencial tenha a mesma finalidade legítima. É quando as equipes tratam a concessão como responsabilidade completa que os problemas aparecem.

Um agente também tem um perfil de risco diferente de um trabalho convencional. Um trabalho convencional geralmente segue um caminho de código fixo. Um agente pode escolher comandos, montar solicitações, repetir ações com argumentos alterados ou ser influenciado pelo material que leu em um repositório. A conta de serviço ainda precisa ter uma finalidade estável, mesmo quando as escolhas do autor da chamada variam. Se você não consegue escrever essa finalidade em uma frase simples, a conta provavelmente acumulou tarefas sem relação.

Um fluxo precisa de uma identidade delimitada

Um fluxo merece sua própria identidade quando tem finalidade, limite de permissões, responsável, ambiente ou condição de encerramento diferentes. Não crie uma conta para cada prompt ou tarefa curta. Isso produz ruído sem melhorar o controle. Crie identidades no nível em que seja possível revogar uma unidade de autoridade sem interromper trabalhos sem relação.

«Atualizar manifestos de dependências em repositórios aprovados» e «publicar artefatos assinados em produção» não devem usar a mesma identidade. O primeiro fluxo altera arquivos-fonte e abre solicitações de revisão. O segundo altera um canal de lançamento. Mesmo que um agente possa iniciar ambos, as permissões são diferentes, a pessoa que deve aprová-los pode ser diferente e a resposta a uma ação suspeita certamente será diferente.

O erro oposto também custa tempo às equipes: dividir um único fluxo restrito em dezenas de nomes de conta porque cada execução do agente cria uma. Os identificadores de execução já descrevem execuções curtas. As identidades de contas de serviço devem descrever uma finalidade de autorização duradoura. Use registros de sessão para execuções individuais e contas para a autoridade que persiste entre execuções.

Um padrão de nomenclatura prático é:

<environment>.<product-or-repository>.<workflow-purpose>

prod.payments.release-publisher
dev.docs.dependency-updater
prod.data.backfill-reader

Os nomes ajudam as pessoas, mas não impõem o escopo. Vincule cada identidade apenas às ações de que seu fluxo precisa. Dê ao atualizador de dependências permissão para criar uma ramificação e enviar uma solicitação de revisão se isso for tudo o que ele faz. Não conceda permissões de lançamento porque talvez um dia ele precise delas. O «talvez» criou mais acessos permanentes do que qualquer requisito real.

Use identidades separadas para ambientes separados. Um agente de desenvolvimento pode executar experimentos, repetir ações agressivamente e trabalhar com dados descartáveis. Esse comportamento não pertence a uma identidade de produção. Copiar uma credencial de produção para uma configuração de desenvolvimento inverte o limite: o ambiente menos controlado passa a ter a autoridade mais forte.

Há uma exceção legítima à separação rigorosa: duas invocações podem compartilhar uma identidade quando são o mesmo fluxo documentado, têm o mesmo responsável, usam o mesmo conjunto de permissões e terminam sob a mesma condição de encerramento. O teste é prático. Se desativar a conta faria você perguntar «qual desses trabalhos sem relação acabou de quebrar?», a conta cobre coisas demais.

O responsável deve ser uma pessoa capaz de interromper o trabalho

Toda identidade de fluxo precisa de uma pessoa responsável identificada, com autoridade e obrigação de responder por ela. Um contato técnico pode ajudar a operar o fluxo, e uma equipe pode garantir continuidade, mas nenhum dos dois substitui um responsável específico.

O responsável faz quatro coisas concretas. Confirma que o fluxo ainda tem uma finalidade, aprova mudanças em seu acesso, responde quando surge uma chamada suspeita e encerra a identidade quando o trabalho termina. Se a pessoa indicada não consegue executar essas tarefas, o registro é apenas decorativo.

A NIST SP 800-53 Revision 5, no controle AC-2 sobre gerenciamento de contas, exige que as organizações definam tipos de conta, estabeleçam condições para participação em grupos e funções e desativem contas quando elas deixam de estar associadas a um usuário ou não são mais necessárias. O controle se aplica bem a contas não humanas, embora muitas pessoas o leiam apenas como orientação para contas de funcionários. Uma identidade de máquina sem um responsável comprometido não tem ninguém para estabelecer essas condições ou decidir que a conta deixou de ser necessária.

Coloque o registro da conta em um repositório ou cadastro usado pelo processo de revisão de acesso. Não o esconda em uma página de wiki que se afasta da vinculação real. Este registro mínimo tem campos suficientes para uma revisão séria:

identity: prod.payments.release-publisher
owner: "Morgan Lee"
technical_contact: "Release engineering on-call"
purpose: "Publish approved signed payment service artifacts to production"
allowed_actions:
  - "upload signed artifact to production release repository"
  - "read release metadata for the payment service"
environments:
  - production
permission_bindings:
  - "artifact-repository/publish-payments-prod"
credential_method: "short lived workload token"
source_repository: "payments-service"
review_after: "2026-06-30"
retire_when: "The payment service stops using this release workflow"
incident_contact: "Release engineering on-call"

O registro torna a ambiguidade visível. Se allowed_actions virar um parágrafo contendo vários sistemas e verbos vagos como «gerenciar» ou «administrar», divida o fluxo. Se retire_when disser «never» ou não tiver uma condição, a conta entrou na pilha de acessos permanentes. Se o campo do responsável indicar uma lista de distribuição, atribua uma pessoa antes de conceder o acesso.

Mudanças de responsabilidade precisam de seu próprio controle. Uma pessoa que está saindo não deve continuar como responsável nominal porque transferir o registro parece trabalhoso. Exija que o novo responsável aceite a conta, leia sua finalidade e seus vínculos e defina a próxima data de revisão. Se ninguém aceitar, desative a conta. Sistemas não recebem uma exceção à responsabilidade só porque continuam funcionando.

Contas compartilhadas transformam um pequeno incidente em um exercício de adivinhação

Uma conta compartilhada falha de forma mais evidente durante um incidente de aparência rotineira, não em uma violação dramática. Considere uma equipe que usa prod.agent-ops para três fluxos: um agente de lançamentos, um agente de resumos de incidentes e um agente de reparo de infraestrutura. A conta pode ler o estado da implantação, alterar uma variável de ambiente e iniciar uma reversão.

Às 16h20, alguém percebe que uma variável de ambiente mudou para um valor inválido. O log da API diz que prod.agent-ops fez a solicitação. A equipe de lançamentos afirma que sua execução havia terminado antes. A equipe de incidentes diz que seu agente estava lendo o status, mas não acredita que ele escreva configurações. O responsável pela infraestrutura diz que um prompt de reparo foi testado naquela tarde, mas ninguém guardou a sessão exata. As três afirmações podem ser verdadeiras, e o log da conta não consegue resolver o conflito.

A resposta habitual é procurar mensagens de chat, histórico do repositório, históricos do shell e transcrições do modelo. Isso pode encontrar uma resposta, mas é lento e incompleto. Pior, a mesma conta continua ativa porque desativá-la pode interromper a recuperação de lançamentos. O incidente agora conectou detecção, contenção e operações de produção sem relação.

Identidades separadas mudam a sequência. Se prod.payments.release-publisher fizer uma chamada inesperada, desative essa identidade. A conta de resumo de incidentes e a conta de reparo mantêm suas próprias autoridades. O registro da ação deve incluir uma identidade de fluxo e uma referência à execução, para que os investigadores encontrem a sessão exata sem discutir com base na memória. É por isso que «uma conta por equipe» não é um compromisso. É uma decisão de combinar domínios de falha.

Algumas equipes defendem contas compartilhadas dizendo que a centralização facilita a rotação. Isso parece verdade porque há apenas uma credencial para substituir. A economia operacional é pequena, enquanto o custo aparece quando você precisa de revogação direcionada, revisão de permissões ou uma explicação. Automatize a emissão de credenciais e o gerenciamento de vínculos em vez de tornar o limite da conta amplo apenas por conveniência.

Não confunda uma conta compartilhada com uma função de permissões compartilhada. Várias identidades podem receber a mesma função bem definida se executarem a mesma operação permitida. As identidades continuam distintas, então os logs e a revogação continuam funcionando. Reutilizar uma função preserva a capacidade de gerenciamento; reutilizar uma identidade destrói a atribuição.

O escopo das permissões deve seguir as ações, não as ambições do agente

Conceda acesso ao caminho exato de ação que pretende permitir e faça o agente provar que precisa de qualquer outra coisa. A capacidade geral de um agente não justifica uma autoridade geral.

Comece pelos verbos e objetos do fluxo. «Ler as questões abertas no repositório A e criar uma ramificação no repositório A» é uma descrição de ação. «Manter o repositório A» não é. A primeira frase permite que um administrador encontre um escopo de leitura e outro para criação de ramificações. A segunda geralmente termina em acesso amplo de gravação porque ninguém consegue mapeá-la para uma permissão precisa.

A mesma disciplina se aplica às permissões de API. Se um fluxo lê um relatório e publica um comentário, não dê a ele acesso ao gerenciamento de contas só porque a API agrupa esses endpoints em uma função ampla e conveniente. Crie um conjunto menor de permissões se o provedor permitir. Se não permitir, coloque um intermediário específico para a ação diante da credencial ampla ou reconsidere se o agente deve executar essa ação sem supervisão.

É aqui que muitas implantações de agentes cometem um erro sutil. Elas concedem acesso amplo porque o agente precisa examinar o contexto antes de agir. Ler o contexto e alterar um alvo são autoridades diferentes. Dê acesso de leitura quando possível e exija uma identidade ou caminho de aprovação separado para mudanças de estado. Um modelo que pode ler uma configuração de produção não precisa automaticamente de permissão para editá-la.

Teste o limite com solicitações deliberadamente erradas antes de colocar o fluxo em uso regular. Para um publicador de lançamentos, tente publicar um artefato de outro produto, excluir um lançamento e alterar as configurações do repositório. Cada solicitação deve falhar na camada de autorização. Um teste bem-sucedido prova apenas que você concedeu acesso suficiente. Ações adjacentes rejeitadas provam que você não concedeu acesso demais.

Mantenha o resultado do teste junto ao registro de responsabilidade. Pode ser uma tabela simples:

Não deixe um agente escolher uma identidade em um menu de contas poderosas. O executor do fluxo deve anexar a identidade pertencente ao trabalho. Um agente capaz de escolher entre autoridades sem relação frequentemente consegue contornar o limite que você projetou.

As credenciais devem expirar antes que os fluxos esquecidos

Credenciais duradouras dificultam o encerramento porque uma cópia esquecida pode continuar funcionando depois que você desativa um trabalho visível. Prefira credenciais de carga de trabalho de curta duração emitidas para um ambiente de execução verificado ou faça com que um componente controlado execute a ação autenticada enquanto o agente recebe apenas o resultado.

Essa é uma questão separada do desenho da identidade. Você pode ter uma conta de serviço com bom nome e responsável e ainda perder o controle se a credencial ficar em um repositório, arquivo de ambiente local, transcrição do agente ou log de compilação. O registro da conta diz quem pode usar a autoridade. O tratamento da credencial decide quem pode realmente apresentá-la.

A sequência preferida é simples:

1. Verifique o ambiente de chamada ou a sessão do agente.
2. Emita uma credencial com expiração curta e escopo limitado ao fluxo ou execute a ação solicitada em nome dele.
3. Registre a ação solicitada e a decisão de autorização.
4. Encerre a sessão e invalide a autoridade que pertence apenas a essa sessão.

Não entregue um segredo em texto simples ao agente apenas porque ele precisa chamar uma API. Isso transforma cada prompt, saída de ferramenta, rastreamento e log acidental em um possível caminho de distribuição da credencial. Ocultar valores secretos na saída do console ajuda depois da exposição, mas não impede que o agente os receba e reutilize.

O Sallyport segue o segundo caminho para seus canais HTTP e SSH compatíveis: o agente solicita uma ação por sua conexão MCP, enquanto o app mantém as credenciais de API e SSH em seu cofre criptografado e executa a ação sozinho. Essa configuração pode manter as credenciais fora do contexto do agente, mas não elimina a necessidade de projetar identidades e responsáveis separados para os fluxos.

Para sistemas que precisam usar uma credencial diretamente, registre onde ela é emitida, como é entregue, sua duração máxima e quem pode revogá-la. A rotação não deve depender de alguém se lembrar de uma data no calendário. Faça da emissão e da substituição parte do processo de implantação do fluxo e teste uma rotação antes que a conta se torne importante.

Uma credencial com expiração curta não é motivo para ignorar os logs. Um agente pode causar danos reais durante uma sessão breve. A expiração limita a persistência depois do uso indevido; o escopo, a aprovação e o registro das ações limitam o que acontece durante a sessão.

Os registros de auditoria precisam ligar a autoridade a uma execução específica

Um histórico de auditoria útil permite reconstruir uma ação sem tratar a conta de serviço como a história completa. Armazene a identidade do fluxo, o identificador da execução do agente, o gatilho inicial, a decisão de autorização, o alvo, a operação, o resultado e o horário em registros que os investigadores possam correlacionar.

Use um formato consistente de evento. O JSON a seguir não depende de um provedor, mas reúne os campos que as pessoas normalmente gostariam de ter depois do fato:

{
  "event_id": "act_01J8Q7M6K4",
  "time": "2026-04-14T16:20:31Z",
  "workflow_identity": "prod.payments.release-publisher",
  "run_id": "run_8f3c1d",
  "trigger": {
    "type": "approved_ci_job",
    "initiator": "morgan.lee",
    "source_revision": "a1b2c3d4"
  },
  "authorization": {
    "decision": "approved",
    "approved_by": "morgan.lee",
    "approval_ref": "apr_31fa"
  },
  "action": {
    "target": "production artifact repository",
    "operation": "publish",
    "resource": "payments-service/2.4.1"
  },
  "result": "success"
}

Não coloque credenciais, prompts completos com material sensível ou cargas irrestritas em um registro de auditoria apenas porque quer detalhes forenses. Registre contexto estável suficiente para estabelecer a causalidade e aplique as mesmas regras de tratamento de dados usadas para qualquer log operacional. Um sistema de auditoria que vira um segundo repositório de segredos cria seu próprio caminho para incidentes.

A integridade também importa. Logs que um agente ou fluxo comprometido pode alterar não resolvem disputas. Use armazenamento somente para acréscimo, separe as permissões de gravação das permissões de leitura e administração e verifique a integridade regularmente. Mantenha as evidências disponíveis depois que uma conta for encerrada. O encerramento remove autoridade futura; não deve apagar o histórico necessário para explicar ações passadas.

Os diários de sessões e atividades do Sallyport são projetados a partir de um log de auditoria criptografado, encadeado por hashes e protegido contra escrita, e o comando sp audit verify verifica essa cadeia offline sem precisar de uma credencial do cofre. Isso é uma evidência útil para ações intermediadas por ele, mas os sistemas ao redor ainda precisam preservar o responsável pelo fluxo, o gatilho e o contexto da aprovação de negócio.

Estruture a revisão em torno de perguntas que alguém possa responder em minutos: qual fluxo tinha essa autoridade? Quem era o responsável naquele momento? Qual execução a usou? O que aprovou essa execução? Qual operação exata teve sucesso ou falhou? Se alguma resposta exigir reconstruir uma história a partir do histórico de conversas, seus registros estão incompletos.

O encerramento é um fluxo, não uma tarefa anual de limpeza

Encerre uma conta de serviço quando seu fluxo terminar, quando seu responsável não puder ser substituído ou quando uma mudança relevante tornar falsa a finalidade original. Revisões anuais encontram contas obsoletas, mas são lentas demais para eventos que você já conhece.

Inclua as condições de encerramento no registro original da conta. Um fluxo de migração pode ser encerrado quando a migração terminar. Uma automação de repositório pode ser encerrada quando o repositório for arquivado. Uma integração com fornecedor pode ser encerrada quando o contrato acabar. Essas condições facilitam a decisão porque a conta já tem um fim acordado.

Use esta sequência ao encerrar uma identidade:

1. Desative novos usos da conta e revogue credenciais ou vínculos ativos.
2. Monitore as falhas esperadas durante uma janela de observação definida e identifique qualquer dependência não documentada.
3. Restaure apenas o acesso mínimo necessário para uma dependência verificada, com um novo responsável e um novo registro se o fluxo ainda for legítimo.
4. Preserve o registro de responsabilidade, o histórico de acesso e os logs de ações conforme suas regras de retenção.
5. Remova a identidade e as credenciais restantes quando a janela de observação terminar.

Não comece excluindo a conta. A exclusão pode remover configurações úteis e dificultar o diagnóstico de falhas. Desativar oferece contenção e permite que o monitoramento comum revele chamadas ocultas. Também força uma conversa útil: se um fluxo quebrar, quem se responsabiliza por ele e por que estava ausente do cadastro?

A saída do responsável pela conta merece atenção imediata. Antes do último dia dessa pessoa, transfira a responsabilidade somente depois que o substituto aceitar o compromisso. Se não houver substituto, desative a conta. Uma equipe pode decidir reativá-la depois para uma necessidade operacional documentada, mas uma conta órfã não deve manter autoridade porque alguém talvez precise dela.

O encerramento também se aplica quando um fluxo cresce. Se um atualizador de dependências começar a implantar código, não edite sua finalidade até que ela descreva dois trabalhos sem relação. Encerre ou reduza a identidade antiga e crie uma identidade de implantação com seu próprio responsável, escopo, testes e registro de revisão. Assim, o significado de auditoria das duas contas permanece claro.

A responsabilidade só sobrevive se as revisões puderem revogar o acesso

Uma revisão de conta de serviço só tem valor quando os revisores conseguem ver os vínculos reais, identificar o responsável atual e desativar o acesso sem uma semana de negociações. Dê essa autoridade ao processo operacional antes que ela seja necessária.

Revise os fluxos de maior risco com mais frequência, mas não transforme toda revisão em um ritual burocrático. Pergunte se a finalidade declarada ainda existe, se o responsável listado ainda tem autoridade, se as ações recentes correspondem à finalidade e se o escopo ainda coincide com o uso observado. Se a resposta não estiver clara, reduza ou desative a conta enquanto o responsável esclarece a situação.

Meça a saúde com fatos que revelem autoridade negligenciada: contas sem responsável, datas de revisão vencidas, ausência de histórico de ações por um período significativo, credenciais próximas ou além da duração pretendida e fluxos cujas operações recentes fogem da finalidade documentada. Essas são filas de revisão, não métricas de vaidade.

A primeira ação prática é exportar as identidades existentes dos agentes e escrever uma frase ao lado de cada uma: «Este fluxo pode fazer X para Y, é responsabilidade de Z e permanece ativo até a condição W». As contas que resistirem a essa frase são as que carregam responsabilidade compartilhada oculta. Desative-as ou divida-as antes de adicionar mais capacidade aos agentes.