Seu agente de IA precisa de um processo de onboarding. Aqui te explico por quê.
Você não daria acesso root à produção a um funcionário novo no seu primeiro dia. Sem credenciais de administrador, sem acesso irrestrito a todos os sistemas internos, sem capacidade de enviar e-mails em nome da empresa sem que alguém os revise primeiro.
No entanto, é exatamente isso que a maioria dos devs faz quando levanta um agente de IA.
Esta semana, tanto Microsoft quanto IBM publicaram análises sobre agentes de IA entrando no local de trabalho como “companheiros digitais”. Ambos chegaram à mesma conclusão incômoda: o modelo de segurança para agentes de IA, na maioria dos times, basicamente não existe.
O framing de “coworker digital” não é metáfora — é política
Vasu Jakkal, VP de Segurança da Microsoft, foi direto ao ponto: cada agente deveria ter as mesmas proteções de segurança que um funcionário humano. Isso implica uma identidade clara, acesso limitado (apenas ao que realmente precisa), um registro de tudo o que cria ou toca, e proteção contra atacantes externos que tentem manipulá-lo.
Esse último ponto merece atenção. Os agentes de IA que operam em codebases, leem arquivos, executam comandos no terminal e chamam APIs externas são alvos cada vez mais atraentes para ataques de prompt injection — onde conteúdo malicioso em arquivos ou páginas web tenta sequestrar o comportamento do agente. Se seu agente consegue ler um README e executar código, um README cuidadosamente construído pode fazê-lo fazer coisas que você nunca autorizou.
A análise da IBM vai ainda mais longe. Shlomi Yanai, da AuthMind, a enquadra como uma crise de governança em câmera lenta: em poucos anos, as identidades não humanas (agentes de IA, workflows automatizados, contas de serviço) vão superar em número os usuários humanos dentro da maioria das organizações. A pergunta não é se você tem agentes de IA rodando — provavelmente já tem. A pergunta é se alguém consegue responder três coisas sobre cada um:
- Você sabe que existe? Está catalogado em algum lugar?
- Você sabe a que está acessando? Arquivos, APIs, bancos de dados?
- Você confia no que faz quando chega lá? O que pode ler, escrever, deletar ou chamar?
Se você não consegue responder as três, você não está rodando um agente — está rodando um ponto cego.
Isso não é apenas um problema enterprise
É fácil ler “Microsoft e IBM falando sobre governança em IA” e mentalmente arquivar isso sob “preocupações de TI empresarial que não me aplicam”. Isso seria um erro.
Se você usa Claude Code, Cursor, ou qualquer ferramenta de codificação agêntica, já está tomando decisões de política implícitas:
- Quais arquivos o agente pode ler? (Em geral: tudo no seu repo, incluindo arquivos
.env) - Pode executar comandos no terminal? (Em geral: sim, com confirmação mínima)
- Pode fazer requisições externas ou chamar APIs? (Depende da configuração dos servidores MCP)
- Há algum registro do que fez durante a sessão? (Geralmente: apenas no histórico do seu terminal)
A analogia do funcionário novo funciona bem aqui. Quando você faz o onboarding de um dev humano, dá acesso ao que ele precisa para o trabalho — não a todo o filesystem da empresa. Você configura SSO para poder revogar acesso de um único lugar. Você mantém logs de auditoria para entender o que aconteceu se algo der errado.
Seus agentes de IA merecem — e francamente requerem — a mesma disciplina.
O checklist prático
Isso é o que aplicar esse princípio significa na prática dentro de um workflow de desenvolvimento:
Limite o acesso do seu agente. Não o aponte para todo o seu diretório home ou para um monorepo inteiro por padrão. Trabalhe em contextos delimitados quando possível.
Audite as permissões dos seus servidores MCP. Cada servidor MCP que você adiciona é uma nova superfície de capacidades. Revise o que cada um realmente pode fazer — não os instale às cegas.
Leia o que seu agente está fazendo. Os logs de sessão do Claude Code e o histórico de commits são seu registro de auditoria. Use-os. Se um agente fez uma mudança que você não esperava, você quer saber antes que chegue à produção.
Trate .env e credenciais como zonas proibidas. Configure explicitamente seus agentes para excluir padrões de arquivos sensíveis. Não se apoie na suposição de que “não vão olhar lá”.
Pense na confiança entre múltiplos agentes. Se um agente consegue chamar outro agente (ou disparar workflows via webhooks), essa cadeia de confiança se multiplica. Cada salto é uma superfície de ataque potencial adicional.
O panorama mais amplo: a orquestração é a nova fronteira
Gabe Goodhart da IBM fez um ponto que reencadra toda a conversa: “É um mercado de compradores para os modelos. O modelo em si não vai ser o diferenciador principal. O que importa agora é a orquestração — combinar modelos, ferramentas e workflows.”
Em 2026, todo mundo tem acesso a bons modelos. A vantagem competitiva a têm os times que constroem sistemas em torno desses modelos — e os sistemas requerem governança, não apenas capacidade.
Os devs que vão tirar mais proveito dos agentes de IA não são os que lhes dão mais acesso. São os que lhes dão exatamente o acesso correto, junto com a visibilidade para saber o que está realmente acontecendo.
Isso não é uma limitação do que os agentes podem fazer. É o que os torna confiáveis o suficiente para fazer mais.