MCP no Google Workspace: seu agente usa o mesmo cliente OAuth do app?

Seu app já lê arquivos do Drive por uma API REST. Agora você quer que um agente consulte o Drive por MCP. Reaproveitar o cliente OAuth do app parece o caminho mais curto, até chegar a hora de explicar quais chamadas foram feitas pelo agente e quais pertenciam ao fluxo normal do produto.

Há também um prazo concreto: nas notas de lançamento do Google Workspace, o Google informa que, a partir de 11 de novembro de 2026, chamadas aos servidores MCP do Workspace vão exigir um cliente OAuth marcado como agente de IA. Se o aplicativo mistura chamadas de agente e chamadas REST comuns, a orientação é criar um cliente separado para o agente e manter o atual para o restante. Isso não significa que a API REST vai parar de funcionar. Os servidores MCP citados ainda estão em prévia para desenvolvedores (Developer Preview); vale conferir o acesso disponível para o seu projeto antes de planejar uma migração.

Separar os clientes ajuda a identificar a origem da chamada. Não resolve, sozinho, o que o agente pode fazer com cada arquivo.

Comece pela identidade, depois reduza as operações

Antes de conectar o agente, eu faria um inventário pequeno: qual cliente OAuth o app usa hoje, quais APIs REST dependem dele e quais operações o agente realmente precisa executar. Um agente que só precisa consultar metadados não deveria receber, por conveniência, um conjunto de ferramentas que também altera ou apaga arquivos.

Depois, olharia os escopos e as autorizações exigidas no ambiente em que a integração vai rodar. Marcar o cliente como agente atende a uma exigência de identificação para as chamadas MCP; isso não concede acesso automático a recursos do usuário, nem substitui as verificações do servidor. É fácil confundir essas duas camadas quando uma chamada de teste funciona.

Uma lista explícita de operações permitidas ajuda a deixar o limite revisável. O suporte a MCP no Apigee hybrid, por exemplo, permite expor operações por ferramenta em um produto de API e reaproveitar políticas de autenticação e controle já usadas em proxies. É um exemplo de desenho para quem opera Apigee, não uma política que os servidores MCP do Workspace passam a oferecer por conta própria. O suporte no Apigee é opcional, não vem habilitado por padrão.

Teste também o que deve ser negado

Imagine um ambiente de teste com uma conta e um arquivo fictícios. A regra da integração permite ao agente consultar metadados daquele arquivo, mas não alterar seu conteúdo. Faça a chamada permitida e registre se ela funcionou. Em seguida, tente uma operação fora da lista e confira se o servidor a recusou. Se tudo passa, o teste de autorização ainda não passou.

Guarde só o necessário para investigar: identificação do cliente usado, ferramenta solicitada, resultado e decisão de autorização. Não grave tokens, conteúdo do arquivo ou dados pessoais na trilha. E não confunda um log de execução com prova de que a política estava certa: a negativa precisa aparecer no comportamento do servidor.

Se a lista de ferramentas ou a política de acesso estiver versionada, vale comparar duas versões da configuração antes de liberar a mudança. Use apenas exemplos sintéticos ou arquivos previamente saneados; não cole credenciais nem dados privados em uma ferramenta externa. Comece pelo diff de linhas sem ignorar espaços, já que recuo pode mudar o sentido de uma configuração. O diff mostra o que mudou no texto, não valida a sintaxe, a autorização efetiva nem a segurança da mudança. Essa parte ainda pede revisão e um teste negativo.

O lugar onde o agente roda é outra decisão

Se ele precisa alcançar uma rede interna ou cumprir uma restrição específica de dados ou hardware, executar o agente na infraestrutura da equipe pode fazer sentido. Os Self-Hosted Orbs da Amp ilustram esse caso, mas a equipe passa a cuidar das máquinas e da rapidez com que o ambiente fica pronto para executar tarefas. Isso não muda a regra de OAuth do Workspace nem dispensa a lista de operações permitidas. Sem uma restrição concreta, eu não colocaria a hospedagem própria na frente do teste de acesso.

O primeiro passo, portanto, cabe em uma revisão curta: desenhe os fluxos REST e MCP lado a lado, atribua um cliente a cada um, limite as operações do agente e tente deliberadamente uma chamada proibida com dados fictícios. Se você consegue explicar por que ela foi negada, já tem uma base melhor para conectar dados reais.

Fontes para conferir os limites de cada produto

• Notas de lançamento do Google Workspace — identificação do cliente OAuth e status de Developer Preview dos servidores MCP.
• Suporte a MCP no Apigee hybrid — controles por operação em proxies, separados da integração do Workspace.
• Self-Hosted Orbs da Amp — execução em infraestrutura própria e custos operacionais.