O erro do dia zero: dar ao agente a conta da Marta
Quase todos os agentes que vimos entrar em produção começaram da mesma forma: alguém precisava que a coisa lesse o correio e escrevesse no CRM, e a via rápida era usar as credenciais de quem já tinha acesso. Marta, das operações. No primeiro dia funciona. O problema aparece no segundo, e não é técnico: a partir daí ninguém na empresa consegue responder a duas perguntas elementares. Quem fez esta alteração, a Marta ou o agente. E ao que é que esta coisa pode mexer exactamente.
A resposta à segunda é sempre a mesma e sempre incómoda: a tudo aquilo a que a Marta pode mexer. Dez anos de casa, três mudanças de departamento e as permissões acumuladas de cada uma. O agente não herdou uma tarefa; herdou uma carreira inteira. E, ao contrário da Marta, não tem critério que lhe diga que a pasta dos salários não se abre, mesmo que algo no contexto lho peça com muita educação.
A OWASP deu nome a isto em dezembro de 2025, quando publicou o seu Top 10 para aplicações agênticas. A categoria ASI03 chama-se Identity & Privilege Abuse e descreve-a exactamente assim: credenciais herdadas ou fugidas que deixam o agente operar muito para além do âmbito previsto. Não é uma hipótese de laboratório — a lista foi construída sobre incidentes reais da primeira geração de adoptantes.
A matriz de quatro colunas que se preenche antes de ligar seja o que for
O desenho de permissões de um agente cabe numa tabela que se preenche numa reunião de quarenta minutos, e que tem de estar preenchida antes de existir a primeira credencial. Não depois: depois já há algo a funcionar e ninguém quer ser quem o parte. Quatro colunas de permissão, um sistema por linha.
| Sistema | O que LÊ | O que ESCREVE | O que EXECUTA | Aquilo em que nunca mexe |
|---|---|---|---|---|
| CRM | Oportunidades abertas da sua carteira | Notas e passo seguinte | Nada | Valor, fase de fecho, eliminação de registos |
| Correio | Caixa de um alias próprio | Rascunhos numa pasta de revisão | Nada | Enviar sem revisão, reencaminhar para fora do domínio |
| ERP / facturação | Estado das encomendas | Nada | Nada | Tudo o resto |
| Armazenamento | Pasta do projecto | Subpasta de saídas | Nada | Salários, jurídico, pastas da direcção |
A coluna que toda a gente discute é a terceira, executar, e é a que mais importa. Ler é reversível. Escrever costuma ser, com um histórico decente. Executar — lançar um pagamento, mandar um email a um cliente, fechar um ticket, apagar — quase nunca é. Regra prática: uma acção entra na coluna executar só se alguém souber descrever numa frase como se desfaz. Se a frase não existe, a acção fica em «propõe e espera».
E a quarta coluna, aquilo em que nunca mexe, não é decorativa. É a única escrita em positivo desde o início e a única que sobrevive às mudanças de âmbito: daqui a seis meses, quando alguém quiser «alargar-lhe um pouco as permissões para também fazer isto», é ela que obriga a ter a conversa em vez de a despachar com um clique na consola.
Identidade própria: o agente não é o plugin de ninguém
Uma credencial de serviço não é burocracia de segurança. É o que torna possíveis as três coisas seguintes, e sem ela nenhuma o é.
- Auditoria. O log diz «agente-vendas-01» e não «marta.g». Quando algo sai estranho, a investigação dura dez minutos em vez de uma tarde a perguntar às pessoas se foram elas.
- Revogação limpa. Corta-se o acesso do agente sem deixar uma pessoa sem trabalhar, e desactiva-se uma pessoa sem cortar o agente. Óbvio, até partilhar a credencial e descobrir que não consegue fazer nem uma coisa nem outra.
- Âmbito real. Só lhe pode dar menos permissões do que a um humano se tiver uma conta distinta da do humano. Com credencial partilhada, «privilégio mínimo» é uma intenção, não uma configuração.
A objecção habitual é o custo: em muitas ferramentas SaaS uma conta a mais são trinta ou cinquenta euros por mês. É legítima e tem boa resposta em quase todas: contas de serviço, de integração ou de API, que não são facturadas como lugar de utilizador. A resposta má — a que se toma por omissão quando ninguém pergunta — é partilhar a conta da Marta para poupar quarenta euros e ficar sem auditoria, sem revogação e sem âmbito. Quando liga um agente a um CRM concreto a conversa fica muito específica: ligar um agente de IA ao seu CRM desce ao detalhe de objectos, campos e sincronização.
Âmbito por tarefa, não por pessoa
O modelo mental que trazemos do IAM é o papel: «comercial», «suporte», «administração». Funciona com humanos porque um humano faz muitas coisas e o seu critério preenche os buracos. Com um agente o papel é demasiado grande, porque o agente faz uma coisa e não tem critério para preencher nada.
Por isso a permissão recorta-se à tarefa. Não «acesso ao suporte», mas «ler os tickets abertos da fila de facturação e escrever uma resposta em rascunho». Tudo o que sobra dessa frase sobra da credencial. É mais trabalho de configuração inicial, e em troca a pergunta «o que é que isto pode fazer?» tem resposta escrita em vez de uma investigação.
Há um efeito secundário que compensa o trabalho: quando o âmbito é uma tarefa e não um papel, alargar o agente obriga a uma alteração explícita de permissões, e essa alteração deixa rasto. O agente que cresce sem ninguém dar por isso é o que começou com um papel amplo. E quando já tem vários agentes a crescer por conta própria, o problema deixa de ser de desenho e passa a ser de resgate: isso trata-se em travar os agentes de IA descontrolados.
Contra a injecção de prompts, a permissão que não deu
A injecção de prompts é a via pela qual um conteúdo que o agente lê — uma página, um email, um documento, um ticket — lhe enfia instruções que não vêm de si. E o estado da arte, dito por quem constrói os modelos, é que não está resolvido. Em novembro de 2025 a Anthropic publicou os seus resultados de robustez em navegação com o Claude Opus 4.5, acompanhados de uma frase que convém ler devagar: uma taxa de sucesso de 1 % perante um atacante adaptativo continua a ser risco real, nenhum agente de navegador é imune, e os dados publicam-se para mostrar progresso, não para dar o problema por encerrado.
Daí sai a única conclusão prática que aguenta: não pode evitar que manipulem o agente; pode decidir do que é capaz um agente manipulado. A defesa não vive no prompt de sistema — é exactamente aquilo que o atacante está a atacar. Vive na credencial, à qual o atacante não chega a partir do conteúdo.
Traduzido para a matriz acima: cada permissão da coluna «executa» é uma capacidade que um atacante herda se conseguir enfiar uma instrução. Um agente que só lê e propõe, injectado, produz uma proposta estranha que alguém descarta. O mesmo agente com permissão de envio produz um email que já saiu. A diferença não a fez o modelo. Fê-la uma caixa que alguém decidiu não assinalar.
O botão de revogação que se testa ANTES de arrancar
Toda a gente assume que consegue cortar o acesso ao seu agente. Muito pouca gente o comprovou. E o momento de comprovar não é quando o agente está a fazer algo estranho numa sexta-feira à tarde: é antes da primeira execução real, a frio, com tempo e sem nervos.
O teste é curto. Executa-se uma tarefa normal, revoga-se a credencial a meio, e olha-se para três coisas: quanto tempo demora mesmo a deixar de ter efeito — os tokens em curso e as sessões abertas nem sempre morrem com o botão —, em que estado fica o trabalho a meio, e se alguém dá por isso. Depois volta-se a conceder e verifica-se que arranca. Meia hora.
- Quem o pode carregar. Pelo menos duas pessoas, e uma delas não pode ser quem construiu o agente. Se o botão depende de uma só pessoa, não há botão: há um telefonema.
- Onde está. Escrito, com o link exacto para a consola e o nome exacto da credencial. Procurá-lo a quente é metade do tempo de reacção.
- O que acontece a seguir. Com o que se substitui o trabalho do agente enquanto está cortado. Se a resposta é «nada», cortar tem um custo que alguém vai hesitar em pagar, e essa hesitação é o que alonga os incidentes.
Este mesmo aparato — quem responde, onde está escrito, com o que se substitui — sustenta qualquer automatização em produção, não só os agentes; está desenvolvido em quem responde quando uma automatização cai. E se o que quer é o mapa completo de riscos antes de decidir seja o que for, o catálogo está em os riscos dos agentes de IA que não se vêem na demo.
O que faz esta semana
- Preencha a matriz de quatro colunas para o agente que tem mais perto de produção. Um sistema por linha. Quarenta minutos com quem conhece o processo, não com quem conhece a ferramenta.
- Crie a credencial própria do agente antes de o ligar a seja o que for. Se a sua ferramenta cobra por lugar, pergunte por conta de serviço ou de API antes de se resignar a partilhar.
- Recorte o âmbito de papel para tarefa: leia a descrição do agente em voz alta e retire da credencial tudo o que não apareça nessa frase.
- Aplique o teste da caixa a cada permissão de escrita e de execução. O que o incomodar desce para «propõe e um humano confirma».
- Teste a revogação a frio, com duas pessoas que a saibam carregar, e deixe escrito onde está o botão e com o que se substitui o trabalho.
Nenhum dos cinco passos exige escolher plataforma, modelo ou fornecedor. Fazem-se antes, e fazem-se uma vez. O que decide aqui é o que vai limitar o dano de tudo o que vier a seguir — e o que lhe vai permitir dizer que sim, mais à frente, a coisas que hoje lhe dariam vertigens. Porque as permissões definem no que o agente pode mexer; quanta liberdade tem para as usar é a decisão seguinte, e essa não se dá de uma só vez: os cinco degraus da autonomia sobem-se com as provas na mão — casos vistos, taxa de correcção humana e reversibilidade da acção.
Nós montamos a parte que ninguém quer montar: identidades de serviço, âmbitos por tarefa, revogação testada e o registo de quem fez o quê. É a infra-estrutura de IA empresarial sobre a qual depois assenta qualquer agente que trabalhe a sério. Não vendemos a permissão. Cobramos por ela ser a correcta.