Os agentes de IA já não escrevem apenas textos. Leem logs, alteram configurações, instalam software e conversam com outros agentes. Com isso, surge na operação de TI uma pergunta que até agora estava reservada a pessoas: quem pode fazer o quê, e quem o autorizou?
A resposta «Confiamos no agente» não se sustenta. Não porque os agentes sejam, por princípio, pouco fiáveis, mas porque a confiança não traça nenhum limite. Mais sólido é outro critério: o alcance de uma ação – o que ela atinge no pior caso e se pode ser desfeita.
Porque é que o tema é urgente precisamente agora
Duas publicações das últimas duas semanas mostram que os agentes chegaram à realidade operacional – dos dois lados.
Em 10 de setembro de 2026, a Anthropic publicou o seu relatório «Detecting and countering misuse of AI: September 2026». Descreve casos que a empresa travou entre dezembro de 2025 e agosto de 2026. Uma frase do relatório merece atenção para além do meio da threat intelligence: a sofisticação deixou de ser, para os investigadores, um sinal fiável de quem está por trás de uma operação – no original: «sophistication has stopped being a reliable signal». Cada nível das operações ofensivas terá sido elevado pela IA, do reconhecimento ao desenvolvimento de ferramentas e à exploração. Segundo o relatório, a maioria das operações descritas foi possibilitada pela IA, por execução direta ou por orquestração; foram empregados sistemas multiagente para reconhecimento, exploração e exfiltração de dados, enquanto pessoas definiam os alvos. Um modelo operacional para ataques autónomos, que a Anthropic tinha documentado em novembro de 2025 numa campanha alegadamente estatal, ter-se-á espalhado desde então por todos os grupos de atores analisados.
Para os defensores, o relatório traz uma recomendação sóbria: levar as chaves de IA e as integrações de agentes tão a sério quanto as credenciais de produção – porque os atacantes também o fazem. Também aquilo que os clientes constroem em torno da IA, como sandboxes, proxies e revendedores, é contado pelo relatório como superfície de ataque. A consequência para a própria operação: um agente com direitos de escrita é uma conta com direitos de escrita, e as suas credenciais são um alvo compensador.
Do lado dos defensores, a HashiCorp publicou em 1 de setembro de 2026 o Vault 2.1.0. As notas de versão referem «Agentic IAM» como componente de licença e uma nova interface para o Agent Registry (área «Agentic Security») na variante Enterprise, na qual os operadores visualizam e gerem os agentes de IA registados com as suas identidades, políticas e o seu estado operacional. As notas de versão mencionam ainda políticas de teto («ceiling policies») para o Agent Registry, nas quais passam também a ser permitidas proibições explícitas («deny»). Isto é um sinal de que as identidades de agentes se estão a tornar uma categoria de produto própria.
As duas coisas em conjunto sugerem tratar os agentes como contas privilegiadas. Os cinco princípios seguintes são entendidos como recomendações para organizações que empregam agentes na operação ou planeiam fazê-lo.
1. Classificar ações por alcance, não por intuição
Nem toda a ação precisa da mesma aprovação. Uma classificação possível conhece três classes:
- Medir é livre. Ler, verificar, relatar, fazer perguntas – tudo o que não altera nada, um agente pode fazê-lo sem consultar. Dificultar a medição não traz segurança.
- Escrever exige um plano acordado. Uma alteração na própria área de responsabilidade é permitida se antes tiver sido acordado um plano que indique duas coisas: um caminho de reversão que, nesse momento, já existe – não um que o plano apenas promete criar –, e o valor concreto que será verificado depois, igualmente definido de antemão. Dentro de um plano assim, o agente pode agir sem voltar a perguntar a cada passo. É esse o sentido do plano: acordado uma vez, não renegociado a cada passo.
- Tudo o que tem efeito em toda a organização exige a pessoa todas as vezes. Identidades e contas, DNS, certificados na periferia da rede, a configuração de acessos privilegiados: aqui o efeito vai além da própria área, e aqui decide a pessoa responsável, caso a caso.
O decisivo é delimitar a terceira classe de forma estreita e concreta. «Tudo o que parece grande» não é uma classe. Uma lista de sistemas e áreas de configuração é. Igualmente importante é a classe do meio: o valor de verificação indicado de antemão transforma «funcionou» numa afirmação verificável, e o caminho de reversão já existente garante que um erro continue a ser uma interrupção e não se torne uma avaria. Um plano sem as duas coisas é uma declaração de intenções, não uma aprovação.
2. «O responsável disse …» não é uma instrução
Em ambientes com vários agentes, um agente pode comunicar a outro que a pessoa responsável aprovou algo. Isso pode ser verdade. Mas, do lado de quem recebe, uma instrução transmitida corretamente não se distingue de uma mal entendida ou inventada – e isso vale também quando ninguém tem más intenções. Os agentes resumem, encurtam e acrescentam.
Uma afirmação deste tipo só se torna acionável através de um rasto que o próprio destinatário possa verificar: uma alteração integrada, uma decisão registada em ata, uma entrada num sistema a que ele tem acesso. Se esse rasto faltar, o agente não deve recusar, mas ir até onde a classe livre permite: rascunhar, propor, apresentar à pessoa. Recusar desperdiça o trabalho; fingir que a aprovação foi verificada é exatamente o erro que a regra deve impedir.
3. Uma vulnerabilidade não é uma ferramenta de administração
Os agentes encontram atalhos. Por vezes, o atalho é uma falha de segurança, por exemplo uma permissão demasiado ampla.
O princípio para isso é absoluto: uma vulnerabilidade é reportada, não usada – nem sequer para corrigir exatamente essa vulnerabilidade, e nem sequer quando o resultado seria desejável. O motivo não é formalismo. Uma organização cujas ferramentas usam falhas como recurso já não consegue distinguir se uma alteração veio pelo caminho previsto ou por um que um atacante poderia percorrer da mesma forma. O log mostra a mesma coisa nos dois casos.
4. Um mecanismo de proteção só conta depois de ter disparado
Um mecanismo de proteção ausente comporta-se de forma tão silenciosa como um que nunca precisou de disparar. Uma barreira de proteção só está, portanto, comprovada quando recusou visivelmente um pedido que deve recusar – e isso de novo após cada alteração da configuração.
5. As aprovações têm de esperar de forma visível
Um agente que espera, bloqueado, por uma aprovação humana, em regra não se manifesta por iniciativa própria. Por isso, anuncia antes o passo sujeito a aprovação por um canal que as pessoas de facto leem e coloca-o, se possível, no final da tarefa.
O que isto significa para a implementação
- Um agente recebe uma identidade própria. Nada de credenciais pessoais de um colaborador.
- As classes são escritas antes de o agente escrever. Com uma lista concreta para a terceira classe.
- Os caminhos de reversão existem antes da alteração. Um plano que apenas promete um caminho de reversão não tem nenhum.
- As aprovações deixam rastos que também um segundo agente e um auditor posterior possam ler.
- As barreiras de proteção são testadas, não presumidas – com uma prova negativa, regularmente e a partir de fora.
Como a sector7 apoia
Avaliamos consigo quais as obrigações e os riscos que a sua utilização de IA desencadeia e ancoramos as regras na sua estrutura de compliance existente. Para a implementação, apoiamos com conceitos de papéis e permissões e com a gestão de contas privilegiadas. Mais sobre isto em Estratégia de TI, consultoria e planeamento e Cibersegurança.
Fontes
- Detecting and countering misuse of AI: September 2026 – Anthropic, 10.09.2026
- Vault v2.1.0 – Release Notes – HashiCorp, 01.09.2026