Dar a um agente acesso a Drive, e-mail e GitHub cria um problema diferente de simplesmente conectar três ferramentas. A pergunta passa a ser: qual ação esse agente pode executar, sobre qual recurso, em nome de quem, durante quanto tempo e sob quais condições?
A resposta mais útil não é retirar tantas permissões que a automação deixe de funcionar. É criar uma fronteira de autorização em camadas. O conector define o teto máximo; uma política de execução reduz esse teto para cada tarefa; operações de maior impacto podem exigir aprovação; e todas as decisões relevantes ficam auditáveis.
Essa separação está alinhada com a direção recente do NIST. Em fevereiro de 2026, o NCCoE publicou um concept paper específico sobre identidade e autorização de agentes de software e IA e tratou identificação, autorização, auditoria e não repúdio como questões próprias. O documento é um rascunho conceitual, não uma norma final, mas deixa claro que dar ferramentas a um agente não resolve, por si só, a fronteira de confiança.
O relatório do NIST de maio de 2026 sobre respostas à consulta de segurança de agentes também registra ampla concordância entre participantes de que princípios tradicionais de cibersegurança continuam relevantes, porém precisam ser adaptados aos sistemas agentivos.
Para entender a camada anterior dessa discussão, vale conectar este desenho a o que o formato Agent Plugins padroniza. Um formato pode descrever ou integrar uma ferramenta; a autorização continua tendo de responder quem pode usá-la, sobre o quê e com quais consequências.
Menor privilégio não é apenas escolher um scope pequeno
OAuth scopes, permissões de aplicativo e tokens são controles importantes, mas não representam necessariamente a intenção completa de uma tarefa.
Imagine um agente encarregado de analisar um chamado recebido por e-mail, consultar um documento técnico no Drive e preparar uma correção em um repositório. A tarefa não implica automaticamente que ele deva ler toda a caixa postal, abrir todos os arquivos da organização, escrever em qualquer repositório ou enviar uma mensagem final sem confirmação.
A autorização precisa trabalhar em pelo menos dois níveis.
O primeiro é o teto estrutural: quais capacidades a integração pode receber do Google ou do GitHub. É aqui que entram scopes OAuth, permissões do GitHub App e seleção de repositórios.
O segundo é a autorização da tarefa: dentro daquele teto, quais recursos e ações estão liberados para esta execução específica. É essa camada que impede que uma credencial tecnicamente válida vire autorização irrestrita para o modelo.
O princípio de menor privilégio já aparece no catálogo de controles do NIST como AC-6. A mesma família de controles também separa registro de eventos, conteúdo dos registros e geração de auditoria em AU-2, AU-3 e AU-12. Essa divisão é útil para agentes: conceder acesso e conseguir reconstruir depois como ele foi usado são problemas relacionados, mas distintos.
Desenhe a fronteira de autorização em sete etapas
1. Dê uma identidade própria ao agente
Não trate o agente apenas como “o usuário que autorizou o OAuth”. Registre uma identidade de workload ou aplicação que permita distinguir o humano que delegou a tarefa do software que executou a ação.
O registro de uma operação deveria permitir responder, por exemplo: usuário A solicitou a tarefa, agente B executou, política C autorizou e credencial D foi utilizada.
Essa separação reduz uma ambiguidade perigosa: uma chamada feita “em nome do usuário” não significa que qualquer coisa permitida ao usuário esteja automaticamente autorizada para o agente.
2. Defina o menor teto possível no conector
No Google Drive, a documentação recomenda escolher o escopo mais restrito possível. Quando o fluxo permite que o usuário selecione ou compartilhe arquivos específicos com a aplicação, drive.file oferece acesso por arquivo, em vez de conceder acesso geral ao Drive. Já drive e drive.readonly alcançam todos os arquivos compatíveis com o respectivo nível de acesso.
No Gmail, escolha pela capacidade necessária. gmail.send serve para envio; gmail.readonly permite leitura; gmail.compose permite gerenciar rascunhos e enviar mensagens; e gmail.modify reúne leitura, escrita e envio. O scope mail.google.com é ainda mais amplo e inclui exclusão permanente.
No GitHub, GitHub Apps começam sem permissões explícitas e a própria documentação recomenda selecionar apenas as permissões mínimas necessárias. As permissões podem ser separadas por recursos de repositório, organização, empresa ou conta.
3. Reduza novamente por tarefa
Aqui está a camada que costuma faltar.
Mesmo que uma integração tenha autorização para acessar dez repositórios, a tarefa atual pode precisar de apenas um. Mesmo que o agente tenha gmail.readonly, talvez deva receber apenas as mensagens previamente selecionadas por uma busca ou regra. Mesmo com autorização de escrita no Drive, talvez a execução atual precise somente ler dois documentos.
Uma política de tarefa pode ser descrita como um pequeno envelope de autorização contendo:
- identidade do usuário que delegou;
- identidade do agente;
- ferramenta permitida;
- recursos permitidos, como IDs de arquivos, mensagens ou repositórios;
- operações permitidas, como ler, criar rascunho ou abrir uma alteração;
- prazo de validade;
- limites de volume ou quantidade;
- condição de aprovação, quando aplicável;
- identificador da tarefa para auditoria.
Esse envelope é uma recomendação arquitetural, não um formato exigido pelo NIST ou pelos provedores. O objetivo é transformar “o agente tem acesso ao Gmail” em algo operacionalmente verificável, como “esta tarefa pode ler estas mensagens durante esta execução”.
4. Não entregue credenciais duradouras ao contexto do modelo
Refresh tokens, chaves privadas e outros segredos de longa duração devem permanecer em uma camada de credenciais ou broker, não no prompt, na memória textual do agente ou em argumentos que ele possa reproduzir.
A documentação do Google recomenda armazenamento seguro para tokens e autorização incremental, solicitando novos scopes quando a funcionalidade realmente precisar deles, em vez de pedir tudo na autenticação inicial.
A autorização incremental melhora o consentimento e evita solicitar capacidades antecipadamente, mas não substitui o controle por tarefa. Depois que uma autorização mais ampla existe, a aplicação ainda precisa decidir quais operações o agente pode executar naquela ocasião.
No GitHub há um mecanismo adicional útil: o token de instalação de um GitHub App pode ser emitido para repositórios específicos e com um subconjunto das permissões concedidas ao aplicativo. Esses tokens de instalação expiram após uma hora.
5. Separe leitura, preparação e efeito externo
Nem todas as operações merecem a mesma autonomia.
Ler um documento selecionado é diferente de alterar seu conteúdo. Criar um rascunho é diferente de enviar uma mensagem. Preparar uma mudança de código é diferente de incorporá-la a uma branch protegida ou colocá-la em produção.
Uma política prática pode liberar automaticamente operações de baixo impacto e aumentar a exigência conforme o efeito fica mais difícil de reverter.
Isso evita dois extremos: um agente com poder permanente para qualquer operação ou um agente que pede confirmação humana depois de cada leitura e, por isso, perde boa parte da utilidade.
6. Coloque aprovação na ação de risco, não na conversa inteira
Aprovação humana funciona melhor quando está ligada à chamada concreta que produz o efeito.
Se a política exige confirmação antes de enviar um e-mail externo, o agente pode pesquisar contexto e preparar o rascunho sem interrupção. A aprovação aparece apenas antes da operação de envio.
O mesmo raciocínio pode ser aplicado a exclusões, alterações de compartilhamento, publicação, merge ou outras ações definidas pela organização como sensíveis.
Esse detalhe é especialmente importante no Gmail. O scope gmail.compose, por exemplo, cobre tanto gerenciamento de rascunhos quanto envio. Portanto, se a política da organização quiser “permitir rascunho, proibir envio automático”, o scope sozinho não representa essa fronteira: a aplicação precisa impedir a chamada de envio na sua própria camada de autorização.
7. Registre a decisão, não apenas o resultado final
Guardar apenas a resposta textual do agente é insuficiente para investigar uma ação.
O registro precisa permitir reconstruir o caminho de autorização: qual identidade executou, qual usuário delegou, qual ferramenta foi chamada, qual recurso foi afetado, qual operação foi solicitada, qual política decidiu, se houve aprovação e qual foi o resultado.
Os controles de auditoria do NIST distinguem registro de eventos, conteúdo dos registros e geração desses registros; o concept paper de agentes de 2026 também destaca auditoria entre as questões específicas a serem tratadas para agentes de software e IA.
O log não deve guardar o segredo utilizado na chamada. O que interessa é uma referência segura à credencial ou sessão, suficiente para rastrear o evento sem transformar o sistema de auditoria em outro repositório de credenciais.
Drive, e-mail e GitHub pedem controles diferentes
| Integração | Menor privilégio útil | Onde o controle nativo ajuda | Onde uma política adicional faz diferença |
|---|---|---|---|
| Google Drive | Preferir arquivos específicos quando o fluxo permitir | drive.file pode limitar o acesso aos arquivos usados ou compartilhados com a aplicação | Restringir IDs, pastas, operações de escrita, compartilhamento e exclusão por tarefa |
| Gmail | Escolher scope conforme leitura, envio ou composição | Há scopes diferentes para envio, leitura, composição, modificação e metadados | Limitar quais mensagens entram na tarefa e bloquear endpoints de efeito, como envio, quando necessário |
| GitHub | GitHub App com permissões mínimas e apenas repositórios necessários | Instalações e tokens podem ser restringidos por repositório e permissões | Limitar branch, operação, quantidade de alterações, workflow e ações que exigem aprovação |
No Drive, o ganho é conseguir aproximar o consentimento do próprio recurso. A documentação do Google recomenda drive.file para muitos casos em que o acesso amplo não é necessário e destaca que o usuário pode escolher os arquivos compartilhados com a aplicação.
No GitHub, a estrutura do GitHub App permite combinar permissões mínimas com seleção de repositórios e, na emissão do token de instalação, reduzir novamente repositórios e permissões.
No Gmail, a fronteira tende a exigir mais controle da aplicação. Os scopes documentados diferenciam capacidades, mas não oferecem, de forma geral, uma autorização OAuth do tipo “somente estas três mensagens desta execução”. Essa conclusão decorre do nível de granularidade dos scopes publicados; por isso, quando a tarefa precisa de uma seleção menor que o scope, essa seleção deve ser aplicada pelo broker ou camada de políticas do agente.
Um exemplo de fronteira que mantém o agente útil
Considere a tarefa: “Leia o chamado do cliente, consulte a especificação, prepare uma correção e deixe uma resposta pronta”.
Uma configuração funcional não precisa conceder tudo.
O broker pode liberar a leitura apenas das mensagens que pertencem ao chamado, disponibilizar ao agente o arquivo do Drive selecionado para aquele produto e emitir uma credencial GitHub válida somente para o repositório correspondente. O agente consulta o contexto, prepara sua alteração e cria a resposta.
Se a organização considera envio externo ou integração de código ações de maior impacto, essas operações ficam fora do envelope inicial. O agente apresenta o resultado para aprovação e recebe uma autorização adicional somente para a etapa confirmada.
A diferença é pequena para quem usa o sistema, mas grande para a segurança. O agente continua capaz de concluir quase todo o trabalho. O privilégio mais sensível aparece apenas na fronteira do efeito.
O que costuma quebrar o modelo de menor privilégio
- Um token amplo reutilizado para todas as tarefas. A conveniência elimina a separação entre o que a integração consegue fazer e o que a execução atual deveria fazer.
- Credencial disponível diretamente ao modelo. Uma instrução inesperada ou conteúdo malicioso passa a disputar controle sobre uma credencial real, em vez de solicitar ações a um intermediário que aplica política.
- Permissão de escrita concedida porque “talvez seja útil”. A autorização deve nascer da tarefa real, não de possibilidades futuras.
- Confiar no prompt como mecanismo de segurança. “Não envie”, “não delete” ou “acesse apenas esta pasta” são instruções comportamentais; a fronteira de autorização precisa ser aplicada fora do modelo.
- Aprovação para tudo. Quando cada passo inocente depende de confirmação, usuários tendem a buscar atalhos ou conceder privilégios permanentes para reduzir atrito.
- Log apenas da conversa. Sem registrar chamadas, recursos, decisões de política e aprovações, a auditoria não consegue reconstruir o efeito real do agente.
A arquitetura mais segura coloca um intermediário entre modelo e credencial
Em vez de permitir que o modelo chame diretamente Drive, Gmail ou GitHub com credenciais persistentes, a arquitetura pode usar um broker de ferramentas ou ponto de aplicação de política.
O agente solicita uma operação estruturada. O broker identifica a tarefa e o agente, verifica se recurso e ação estão autorizados, recupera ou obtém a credencial necessária, executa a chamada e devolve apenas o resultado apropriado.
Se a operação exceder a política da tarefa, o broker não “confia” que o agente vá se conter. Ele nega a chamada ou inicia o fluxo de aprovação.
Essa abordagem também deixa mais claro o papel do formato de integração. Saber o que o formato Agent Plugins padroniza ajuda na interoperabilidade das ferramentas; saber como limitar permissões decide até onde uma ferramenta conectada realmente pode chegar.
A regra de projeto é simples: conceda ao agente a menor autorização que ainda permita concluir uma tarefa útil de ponta a ponta e faça a elevação acontecer apenas na etapa que realmente exige mais privilégio. Isso preserva autonomia sem transformar uma integração conveniente em uma credencial universal.
