Conta de serviço ou OAuth para agentes de IA: qual usar

Use uma conta de serviço quando o agente executa uma tarefa da empresa que não deve ficar sob a responsabilidade de uma única pessoa, como trabalhar uma fila compartilhada ou gravar em um sistema de registro. Use tokens OAuth quando o agente age em nome de uma pessoa específica, dentro da caixa de e-mail, da agenda ou dos arquivos dela. Na maioria das implantações reais, os dois modelos convivem, escolhidos por integração, porque a resposta para conta de serviço ou OAuth para agentes de IA depende de quem é a ação, de como você precisa rastreá-la e da rapidez com que precisa cortar o acesso.

Principais pontos

• Conta de serviço é uma identidade da empresa que age como ela mesma. Token OAuth é uma permissão delegada que permite ao agente agir como uma pessoa, dentro dos escopos aprovados.
• Contas de serviço deixam a atividade automatizada fácil de identificar nos logs do provedor. A atividade via OAuth aparece com o nome de quem aprovou, então o agente precisa ter seu próprio registro nos dois casos.
• Revogar uma conta de serviço é um único interruptor com grande alcance. Revogar uma concessão OAuth é mais pontual, mas pode quebrar sem aviso quando a pessoa muda de função ou sai da empresa.
• O escopo é o maior risco prático. Contas de serviço compartilhadas acumulam permissões com o tempo, e os escopos OAuth costumam ser mais amplos do que a tarefa exige.
• Decida por integração, registre a escolha com um responsável e teste a revogação antes de o agente entrar em produção.

Qual é a diferença real entre os dois modelos?

Uma conta de serviço é uma identidade que pertence à empresa, não a uma pessoa. O agente se autentica com essa identidade usando uma credencial que a empresa controla, como uma chave, um certificado ou uma identidade de carga de trabalho emitida pela plataforma de hospedagem. Cada permissão é concedida à própria conta, e cada ação é executada em nome dela.

OAuth é um modelo de delegação. Uma pessoa (ou um administrador) aprova uma solicitação, o provedor emite um token limitado aos escopos aprovados e o agente age em nome dessa pessoa. A documentação do Google sobre OAuth 2.0 descreve o padrão: consentimento, escopos, um token de acesso de curta duração e, em muitos casos, um token de atualização mais duradouro, que permite ao agente continuar trabalhando até que a concessão seja revogada.

A pergunta que separa os dois é simples: de quem é esta ação? Se a ação pertence à empresa, como publicar em um canal compartilhado ou atualizar o registro de um serviço, a conta de serviço serve. Se a ação pertence a uma pessoa, como enviar da caixa de e-mail dela ou ler a agenda privada, o OAuth serve, porque o provedor vai aplicar o que aquela pessoa pode ver.

Existe um modelo híbrido que pede cautela. Alguns provedores permitem que um administrador autorize uma conta de serviço a se passar por qualquer usuário da organização. Isso junta o caráter permanente e sem supervisão da conta de serviço ao alcance de todos os usuários que ela pode representar. Trate como uma concessão de alto risco, com um responsável nomeado e uma lista curta de ações permitidas.

Como os dois se comparam em rastreabilidade?

A rastreabilidade tem duas camadas: o que o provedor registra e o que o seu próprio agente registra. O modelo de acesso muda a primeira camada. Ele nunca deve substituir a segunda.

Com uma conta de serviço, o log do provedor mostra a conta executando a ação. Isso ajuda: quem revisa percebe que a atividade foi automatizada. O que o log não mostra é qual solicitação disparou a ação nem qual colega a pediu. Se cinco fluxos compartilham uma conta, o log do provedor não consegue separá-los.

Com OAuth, o log do provedor normalmente mostra a pessoa que aprovou como autora. Uma edição errada feita pelo agente fica idêntica a uma edição errada feita por aquele colaborador. Alguns provedores também registram o aplicativo conectado, o que ajuda, mas não presuma que todo sistema faça isso.

Por isso, a regra de trabalho é que o agente mantenha seu próprio registro, qualquer que seja o modelo. Para cada ação, registre:

• A solicitação ou conversa que a disparou
• Quem pediu e quem aprovou, quando houve aprovação
• A ferramenta chamada, com as entradas e o resultado
• A identidade usada, ou seja, qual conta de serviço ou a concessão de qual pessoa
• Uma referência que você possa buscar no log do próprio provedor, como o identificador de um registro

Com esses campos, quem revisa pode partir dos dois lados: de uma entrada estranha no log do provedor de volta ao raciocínio do agente, ou de uma decisão do agente até a mudança que ela causou. Sem eles, a conta de serviço dá um autor claro e nenhuma história, e o OAuth dá uma história ligada ao nome errado.

Como os dois se comparam em revogação?

Revogação é a pergunta que mais importa em um dia ruim. Os dois modelos podem ser cortados, mas as consequências são diferentes.

A conta de serviço oferece um único interruptor. Desative a conta ou troque a credencial e o acesso para. O custo é a amplitude: se vários fluxos compartilham a conta, todos param juntos, e trocar uma chave exige encontrar todos os lugares onde ela está guardada. A solução está no desenho, não na ferramenta. Dê a cada integração sua própria conta de serviço e mantenha identidades de teste e de produção separadas, para que revogar uma nunca derrube um trabalho que não tem relação com ela.

Uma concessão OAuth é revogada por pessoa e por aplicativo. O próprio usuário muitas vezes consegue fazer isso, e o administrador também. É uma vantagem para conter um problema, porque a concessão de uma pessoa pode ser removida sem tocar na de ninguém mais. É também uma fragilidade para a continuidade. Os tokens deixam de funcionar quando a pessoa troca a senha, sai da empresa, perde uma licença ou quando um administrador endurece uma política. O agente então falha num momento que ninguém planejou. O jeito de lidar com isso com tranquilidade está em o que um agente deve fazer quando uma conexão expira.

A falha oposta é pior: a concessão de um ex-colaborador que ninguém revogou e que continua funcionando. O processo de desligamento deve incluir uma etapa que liste todas as conexões de agentes ligadas àquela pessoa e as remova ou as transfira para uma identidade da empresa.

Qualquer que seja o modelo, ensaie o corte. Revogue uma credencial de teste, observe o que o agente faz e confirme que ele para, relata a falha e não tenta de novo em loop. Uma revogação que você nunca testou é uma suposição, não um controle.

Como os dois se comparam em escopo?

O escopo é onde começa a maioria dos incidentes, porque o acesso é fácil de conceder e raramente é revisado.

Uma conta de serviço pode ser tão restrita quanto você quiser: uma pasta, uma tabela, uma fila, um projeto. O risco é a deriva. Como a conta é compartilhada e roda sem supervisão, é tentador acrescentar mais uma permissão quando algo falha, e depois ninguém a remove. Com o tempo, a conta passa a alcançar muito mais do que a tarefa original exigia.

Os escopos OAuth são definidos pelo provedor e muitas vezes são mais amplos do que a tarefa. Um escopo que permite ao agente ler e-mails pode liberar a caixa inteira, quando você queria apenas as mensagens com um marcador específico. Além disso, o alcance efetivo é o escopo cruzado com o que a pessoa que aprovou já consegue acessar. Um token concedido por um gerente sênior alcança mais do que o mesmo token concedido por um coordenador recém-chegado, embora a tela de consentimento seja idêntica.

O guia de autorização do OWASP aponta os hábitos que valem aqui: negar por padrão, conceder o menor privilégio necessário e verificar as permissões a cada requisição, não só na configuração. O OWASP Top 10 para aplicações com LLM lista a agência excessiva como um risco à parte, que é a versão para agentes da mesma ideia. Um agente que pode fazer mais do que seu trabalho exige acabará fazendo mais do que você pretendia, seja por erro, seja por uma entrada manipulada.

Na prática, separe ler, preparar rascunho e enviar, e conceda apenas o primeiro até o agente merecer os outros. O raciocínio está em menor privilégio para agentes de IA, e os detalhes para e-mail e agenda em acesso mínimo ao integrar um agente de IA ao Google Workspace ou Microsoft 365.

Como escolher por integração?

Trate a escolha como uma decisão curta para cada sistema que o agente toca. Comece por estas regras:

• Escolha conta de serviço quando o trabalho pertence à empresa e deve continuar independentemente de quem estiver de licença, por exemplo uma fila de suporte compartilhada, um quadro de projeto ou um repositório de documentos.
• Escolha OAuth quando os dados são pessoais de um usuário e o provedor deve aplicar as permissões da própria pessoa, por exemplo uma agenda privada ou uma caixa de e-mail individual.
• Escolha conta de serviço quando o provedor oferece perfis de acesso detalhados, para limitar o acesso a um recurso em vez de uma conta inteira.
• Escolha OAuth quando o provedor só oferece perfis de serviço amplos, mas aceita escopos de usuário restritos, e garanta que quem aprova seja alguém cujo próprio alcance é limitado.
• Evite a personificação em toda a organização, a menos que não exista outro caminho, e então documente o responsável, as ações permitidas e a data de revisão.
• Evite logins pessoais por completo. Compartilhar a senha de uma pessoa com um agente elimina a rastreabilidade e a revogação limpa.

Depois, aplique a escolha nesta ordem:

• Liste todos os sistemas que o agente vai tocar e as ações específicas de que precisa em cada um.
• Para cada ação, decida se ela pertence à empresa ou a uma pessoa.
• Escolha o tipo de identidade e crie uma identidade separada por integração e por ambiente.
• Conceda o menor escopo que sustente a primeira versão da tarefa, somente leitura sempre que possível.
• Registre o responsável, o motivo, a data de revisão e os passos de revogação junto da integração.
• Teste o corte em um ambiente de homologação e confirme que o agente registra a falha e para.
• Revise as concessões periodicamente e remova o que não foi usado.

Como isso fica na prática?

Este é um cenário ilustrativo, não um caso real. Uma pequena empresa de serviços para imóveis quer que um agente faça a triagem da caixa de suporte compartilhada, prepare rascunhos de resposta para uma coordenadora, atualize um controle de serviços e consulte a agenda da coordenadora antes de propor visitas técnicas.

A caixa compartilhada e o controle de serviços pertencem à empresa, então cada um recebe sua própria conta de serviço. A conta da caixa de entrada pode ler e preparar rascunhos, mas não enviar. A conta do controle de serviços pode gravar em um único projeto. Nenhuma das duas enxerga mais nada.

A agenda da coordenadora é pessoal, então usa OAuth com o escopo de agenda mais restrito que o provedor oferece, aprovado pela própria coordenadora. Quando ela entra em licença prolongada, a concessão da agenda é pausada e o agente avisa o responsável de operações de que as propostas de visita precisam ser agendadas manualmente. O trabalho da caixa de entrada e do controle de serviços segue sem impacto, porque nunca dependeu do login de uma pessoa.

No registro do próprio agente, cada rascunho e cada atualização do controle guardam a solicitação que os disparou, a identidade usada e uma referência ao registro. Quando alguém pergunta por que um serviço mudou de status, a resposta leva minutos, não uma tarde comparando horários.

Como a Be Human trata o acesso dos agentes?

Em um primeiro projeto, a Be Human define um papel para o agente e, para cada integração que esse papel exige, decide o modelo de acesso, o escopo, o responsável e o limite de aprovação. As credenciais ficam em armazenamento gerenciado, fora dos prompts e da memória do agente, e cada integração e cada ambiente tem sua própria identidade, para que uma possa ser revogada sem afetar as outras. A operação gerenciada inclui monitoramento de conexões expiradas ou com falha, revisão de permissões, manutenção das integrações e testes de revogação, sempre sob o controle do cliente.

Perguntas frequentes

Um agente de IA pode simplesmente usar o login de um colaborador? Tecnicamente pode, mas é a pior opção. O log do provedor não distingue a pessoa do agente, a senha precisa ficar guardada em algum lugar ao alcance do agente, e revogar o agente significa trocar as credenciais do colaborador. Use uma conta de serviço ou uma concessão OAuth adequada.

OAuth é mais seguro do que conta de serviço? Nenhum dos dois é mais seguro por natureza. O OAuth liga o acesso a uma pessoa e a um registro de consentimento, e os tokens têm vida curta, o que ajuda na contenção. Uma conta de serviço bem delimitada, com identidade própria e um responsável nomeado, pode ser mais fácil de auditar e menos frágil. A escolha mais segura é a que permite conceder o menor escopo e revogá-lo sem efeitos colaterais naquela integração.

O que acontece quando um token OAuth expira ou é revogado? O agente perde o acesso àquele sistema até que alguém autorize de novo. Um agente bem construído interrompe a tarefa afetada, registra a falha, avisa uma pessoa definida e não tenta indefinidamente nem troca de credencial por conta própria. Defina antes do lançamento quem recebe esse alerta.

Os ambientes de teste e de produção devem compartilhar credenciais? Não. Use identidades separadas para cada um, com credenciais de teste que alcancem apenas dados de teste. Assim um experimento não altera registros reais, e você pode revogar um ambiente sem interromper o outro.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.