Integrar agente de IA ao Google Workspace ou Microsoft 365: acesso mínimo

Para integrar um agente de IA ao Google Workspace ou Microsoft 365, dê a ele uma identidade própria, escolha o tipo de permissão mais restrito que o pacote oferece e peça a um administrador que aprove apenas o acesso que a função exige. O Google trabalha principalmente com escopos OAuth e controles de administrador sobre aplicativos de terceiros. A Microsoft trabalha com registros de aplicativo no Entra, permissões do Microsoft Graph e consentimento do administrador. Nos dois pacotes, o trabalho real acontece antes de alguém clicar em Permitir: definir qual é a função do agente e no que ele não pode tocar.

Principais pontos

• Os dois pacotes permitem restringir bem um agente, mas usam vocabulários diferentes. O Google fala em escopos OAuth e controles de aplicativos no console de administração. A Microsoft fala em registros de aplicativo, permissões do Graph e consentimento do administrador.
• Antes de escolher qualquer escopo, decida entre acesso delegado (o agente age dentro do alcance de uma conta) e acesso de aplicativo (o agente age como ele mesmo em toda a organização). O delegado é o padrão mais seguro.
• Trate leitura, rascunho e envio como concessões separadas. A maioria das primeiras funções precisa só das duas primeiras.
• Dê ao agente uma conta própria e limite-a às pastas, agendas, sites ou caixas de e-mail que a função realmente usa.
• Registre o que foi concedido e por quê, e revise em intervalos definidos, porque o acesso costuma crescer sem ninguém perceber.

Como os modelos de acesso do Google Workspace e do Microsoft 365 se diferenciam?

Os dois pacotes resolvem o mesmo problema com peças diferentes. Conhecer essas peças ajuda você a fazer as perguntas certas ao administrador e a quem constrói a integração.

O Google Workspace se organiza em torno do OAuth 2.0. Um aplicativo pede escopos, que são permissões nomeadas, como ler e-mails, criar rascunhos, enviar mensagens, ler eventos da agenda ou acessar arquivos. O usuário, ou um administrador em nome dele, consente com esses escopos. O console de administração acrescenta uma camada de controle: o administrador decide quais aplicativos de terceiros e internos podem acessar quais serviços do Google, e pode bloquear ou restringir aplicativos que pedem escopos amplos. Para entender como consentimento e escopos se encaixam, consulte a documentação de OAuth 2.0 do Google. O Google também oferece contas de serviço, e com delegação em todo o domínio uma conta de serviço pode agir como qualquer usuário do domínio. Isso é poderoso e deve ser tratado como uma concessão de alto risco.

O Microsoft 365 se organiza em torno do Microsoft Entra ID e do Microsoft Graph. O aplicativo é registrado no Entra e pede permissões do Graph que são do tipo delegado ou do tipo aplicativo. Algumas exigem consentimento do administrador. Políticas de acesso condicional podem acrescentar condições, como estado do dispositivo ou localização. O Exchange Online e o SharePoint trazem ferramentas próprias de restrição: é possível limitar uma identidade de aplicativo a caixas de e-mail ou sites selecionados, em vez de liberar o tenant inteiro. Menus e nomes exatos de permissões mudam com o tempo, então confirme na documentação atual da Microsoft na hora de configurar.

Uma forma útil de comparar:

• Unidade de permissão: o Google usa escopos, a Microsoft usa permissões do Graph. Ambos são agrupados por serviço (e-mail, agenda, arquivos).
• Quem aprova: o Google aceita consentimento do usuário, a menos que o administrador restrinja. A Microsoft aceita consentimento do usuário apenas em casos de baixo risco, e o administrador controla o restante.
• Onde mora o atalho perigoso: no Google, a delegação em todo o domínio. Na Microsoft, as permissões de aplicativo que cobrem todas as caixas de e-mail ou todos os sites do tenant.
• Onde a restrição acontece: no Google, principalmente por escopos estreitos, acesso por arquivo no Drive e regras de compartilhamento. Na Microsoft, por permissões de recursos selecionados e políticas do Exchange ou do SharePoint.

Nenhum dos dois é mais seguro por padrão. Cada um é tão seguro quanto a concessão que você faz.

O agente deve usar acesso delegado ou acesso de aplicativo?

Essa é a escolha mais importante, e ela vem antes dos escopos.

Acesso delegado significa que o agente age por meio de uma conta. Ele só alcança o que essa conta alcança. Se a conta não tem acesso à pasta do financeiro, o agente também não tem, não importa o que o software peça. É o modelo mais fácil de raciocinar, porque a conta é um limite visível que seu administrador já sabe gerenciar.

Acesso de aplicativo significa que o agente age como ele mesmo, sem usuário conectado. Serve para trabalho em segundo plano, como uma rotina noturna que lê uma caixa compartilhada. O custo é a amplitude: na Microsoft, as permissões de aplicativo normalmente valem para o tenant inteiro até serem restringidas, e no Google o padrão equivalente é uma conta de serviço com delegação. Os dois exigem restrição deliberada.

Uma regra prática: comece com acesso delegado por meio de uma conta dedicada ao agente. Passe para acesso de aplicativo só quando a função realmente precisar rodar sem conta e quando for possível restringi-lo a recursos nomeados. O raciocínio para uma conta separada está em por que o agente de IA da empresa precisa de identidade e contas próprias. Resumindo: uma conta dedicada torna cada ação atribuível, permite revogar o acesso sem atrapalhar uma pessoa e impede que o agente herde as permissões amplas de um funcionário.

Evite conectar o agente pelo login pessoal de alguém da equipe. Ele herda tudo o que essa pessoa enxerga, deixa de funcionar quando ela sai da empresa e o histórico de auditoria mistura ações do agente com ações humanas.

O que a função realmente precisa acessar?

As permissões devem seguir o trabalho, não o menu do pacote. Escreva primeiro a função em frases simples e depois traduza cada frase na menor concessão possível. O princípio geral está em menor privilégio para agentes de IA, e a separação entre ler, preparar e enviar aparece em ler, preparar e enviar como permissões diferentes de IA.

Use este guia de decisão para cada tarefa da função:

• Precisa encontrar informações em documentos: conceda leitura apenas às pastas, drives compartilhados ou sites nomeados. Não libere o drive ou o tenant inteiro.
• Precisa ler mensagens recebidas: conceda leitura a uma única caixa de e-mail, de preferência compartilhada ou dedicada, e não a todas as caixas.
• Precisa preparar respostas: conceda criação de rascunhos sem envio. Uma pessoa revisa e envia.
• Precisa enviar mensagens: conceda envio só depois que a etapa de rascunho se mostrar confiável, e mantenha uma aprovação para destinatários externos.
• Precisa ler a agenda: comece com disponibilidade (livre ou ocupado) ou leitura. Acrescente criação de eventos apenas se a função marcar reuniões.
• Precisa criar ou editar arquivos: conceda escrita a uma única pasta ou site designado. Prefira concessão por arquivo ou por local a direitos amplos de edição.
• Precisa excluir ou compartilhar externamente: a resposta padrão é não. Se surgir uma necessidade real, passe por aprovação humana.

Duas verificações extras pertencem a esse guia. Primeiro, pergunte se o agente lê conteúdo escrito por pessoas de fora, como e-mails recebidos ou documentos compartilhados. Esse conteúdo pode trazer instruções dirigidas ao agente, e por isso o limite de permissão importa ainda mais (veja prompt injection em documentos: o que proteger). Segundo, aplique o princípio geral das boas práticas de autorização da OWASP: imponha o acesso no lado do servidor, negue por padrão e verifique as permissões a cada requisição, em vez de confiar no julgamento do próprio agente.

Qual é um passo a passo sensato para conectar o agente?

Essa sequência vale para os dois pacotes. Ela é lenta de propósito no começo e rápida no final.

• Escreva a função em um parágrafo: o que o agente faz, para quem e o que ele nunca deve fazer.
• Liste os recursos exatos envolvidos: qual caixa de e-mail, qual agenda, quais pastas ou sites.
• Crie uma conta dedicada ao agente, com nome claro, um responsável humano identificado e sem direitos de administrador.
• Compartilhe com essa conta apenas os recursos listados, usando os controles normais de compartilhamento do pacote.
• Registre a integração (um cliente OAuth no Google, um registro de aplicativo no Entra) com os menores escopos ou permissões que correspondam ao guia acima.
• Peça a um administrador que revise e aprove o consentimento. Quem solicita não deve aprovar a própria solicitação.
• Teste antes em um ambiente de testes ou em uma cópia dos dados. Confirme que o agente faz o que deve e falha de forma limpa no que não deve.
• Ative o registro de logs para toda leitura, rascunho e envio, para depois poder responder quem fez o quê e quando.
• Defina uma data de expiração ou revisão da concessão e nomeie quem fará a revisão.
• Planeje a falha: decida o que o agente faz quando um token expira ou o consentimento é retirado. Esse comportamento está descrito em o que um agente de IA deve fazer quando uma conexão expira.

A etapa de teste é onde o excesso de permissão escondido aparece. Peça ao agente que abra algo fora do escopo dele. Se ele conseguir, a concessão está ampla demais, e a correção está no pacote, não nas instruções do agente. Instruções são orientação. Permissões são imposição.

Como isso fica na prática? Um cenário ilustrativo

O que segue é um cenário ilustrativo, não a descrição de um projeto real.

Uma pequena consultoria quer um agente que prepare rascunhos de resposta aos contatos que chegam em uma caixa compartilhada e proponha horários de reunião. A descrição da função diz: ler a caixa de contatos, preparar rascunhos de resposta, consultar a disponibilidade de dois sócios nomeados e nunca enviar nada sem a aprovação de uma pessoa.

No Google Workspace, a consultoria cria um usuário dedicado ao agente e compartilha com ele o acesso à caixa de contatos. A integração pede escopos de leitura e de criação de rascunhos para e-mail e de leitura de disponibilidade (livre ou ocupado) para a agenda. Ela não pede envio. Os sócios compartilham suas agendas com a conta do agente no nível que mostra apenas disponibilidade. Um administrador aprova o aplicativo no console de administração e o restringe à unidade organizacional da conta do agente.

No Microsoft 365, a consultoria cria o mesmo usuário dedicado e registra um aplicativo com permissões delegadas de leitura e escrita de e-mail (necessárias para criar rascunhos) e de leitura de agenda. Como a permissão de escrita em e-mail é mais ampla que apenas rascunhar, o administrador confirma que a conta do agente só tem acesso à caixa compartilhada de contatos e adiciona uma política para impedir envios por ela até que a etapa de aprovação esteja pronta. O acesso à agenda fica limitado aos dois sócios.

Nos dois casos o resultado é o mesmo: o agente enxerga uma caixa de entrada e duas visões de disponibilidade, consegue deixar rascunhos, e uma pessoa aperta o botão de enviar. Meses depois, se a consultoria quiser que o agente envie confirmações de rotina, isso será uma concessão nova e explícita, com revisão própria, e não uma ampliação silenciosa.

Como a Be Human cuida das conexões com Workspace e Microsoft 365?

A Be Human projeta, implanta e opera essa conexão como parte de uma infraestrutura de IA gerenciada. Um primeiro projeto define uma função útil, as ferramentas e a memória de que ela precisa, os limites de aprovação e um critério de sucesso observável, e depois associa cada tarefa à concessão mais estreita no seu pacote. O agente recebe identidade própria, o acesso é limitado a recursos nomeados e o seu administrador mantém os controles de aprovação e revogação. A operação gerenciada inclui revisão de permissões, manutenção da integração, monitoramento e tratamento de conexões expiradas ou revogadas, para que o acesso continue tão pequeno quanto a função. Quando um protocolo padrão como o MCP é útil para expor ferramentas ao agente (veja o que é MCP e por que importa para agentes de negócio), o limite de permissão continua no seu pacote, sob o seu controle.

Perguntas frequentes

Um mesmo agente pode atuar no Google Workspace e no Microsoft 365? Pode, mas ele precisa de uma identidade separada e de uma concessão separada em cada pacote. Trate como duas integrações que compartilham a mesma descrição de função e revise cada uma no seu próprio calendário. Não reaproveite as decisões de acesso de um pacote no outro, porque os nomes das permissões e as ferramentas de restrição são diferentes.

Devemos usar conta de serviço ou acesso só de aplicativo em vez de uma conta de usuário? Apenas quando a função realmente precisar rodar sem conta e depois que você conseguir restringi-la a recursos nomeados. Uma conta de serviço com delegação em todo o domínio no Google, ou uma permissão de aplicativo em todo o tenant na Microsoft, pode alcançar muito mais do que a função precisa. Para a maioria das primeiras funções, uma conta delegada dedicada é mais fácil de entender, auditar e revogar.

O que acontece se um administrador revogar o consentimento ou um token expirar? O agente deve interromper a ação afetada, dizer com clareza o que falhou e pedir a reconexão, em vez de tentar de novo às cegas ou contornar o bloqueio. Planeje esse comportamento antes do lançamento, incluindo quem é avisado e como o trabalho inacabado é retomado. A revogação é um controle normal, não um incidente, e o agente deve tratá-la assim.

O agente precisa de MCP para se conectar a esses pacotes? Não. O MCP é uma forma de descrever e expor ferramentas a um agente e pode ajudar a manter consistência entre elas. Os limites reais de acesso são definidos pelos escopos OAuth, pelas permissões do Graph, pelas configurações de compartilhamento e pelas políticas de administrador no Google Workspace ou no Microsoft 365, qualquer que seja o método que o agente use para chamá-los.

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