A adoção acelerada de agentes de inteligência artificial nas empresas está a criar uma nova categoria de risco que muitas organizações ainda não conseguem sequer inventariar: as chamadas identidades não-humanas (NHIs) — contas de serviço, chaves de API e tokens de autenticação — que os agentes usam para agir sobre sistemas sensíveis. O problema central não é um ataque sofisticado de dia-zero, mas algo bem mais banal: agentes autónomos que operam com permissões excessivas e que, quando manipulados ou mal configurados, não precisam de invadir nada — limitam-se a usar os acessos que já lhes foram concedidos. À velocidade da máquina, uma pequena falha de autorização transforma-se rapidamente num incidente de grande escala.
Resposta rápida: Agentes de IA sobre-privilegiados são hoje um dos maiores riscos de segurança nas empresas, porque agem com identidades próprias e permissões amplas que persistem sem revisão. Se um agente for comprometido ou manipulado por injeção de prompt, o atacante herda instantaneamente todos esses acessos. A mitigação passa por inventariar todas as identidades não-humanas, aplicar o princípio do menor privilégio e criar processos de governação e ciclo de vida específicos para agentes — não os modelos pensados só para humanos.
Porque é que os agentes “adivinham à escala”
Um agente de IA é um sistema autónomo desenhado para executar tarefas que tradicionalmente eram feitas por pessoas, mas a uma velocidade e escala muito superiores. Estes agentes podem invocar milhares de APIs por segundo, executar lógica complexa de vários passos e operar em sistemas distribuídos em simultâneo, muitas vezes com um mínimo de atrito. A diferença de escala face a um utilizador humano é enorme: um trabalhador humano pode aceder a cinco registos num minuto, enquanto um agente de IA consegue consultar 5.000 endpoints de API no mesmo período para executar uma cadeia lógica de vários passos.
Para garantir que estes agentes funcionam sem interrupções, o padrão de desenvolvimento tende a ser generoso com as permissões. Os programadores concedem-lhes frequentemente permissões amplas e estáticas, resultando muitas vezes em acessos sobre-privilegiados; o que se pretendia ser uma forma de evitar falhas na tarefa acaba por criar um enorme raio de destruição desprotegido. O risco não é a automação em si. É a automação combinada com a velocidade da máquina e a confiança implícita — as características que definem a chamada “Grande Aceleração do Risco”.
É aqui que entra a ideia de “adivinhar à escala”: o agente toma decisões contextuais e, quando o faz sobre permissões demasiado latas, o resultado pode ser catastrófico. Se for manipulado por injeção de prompt — ou se estiver mal configurado — um agente não precisa de forçar a entrada em lado nenhum; limita-se a usar as permissões que já lhe foram concedidas.
A identidade do agente conta, não a do humano
Um detalhe técnico frequentemente ignorado agrava o problema. Cada agente de IA implementado em AWS, GCP ou Azure torna-se uma identidade cloud no momento em que entra em funcionamento; recebe um papel IAM, e esse papel carrega permissões, por vezes muito privilegiadas. A autorização é avaliada contra a identidade do agente, e não contra quem o acionou. Um programador com acesso só de leitura a um bucket S3 pode acionar um agente cujo papel permite escrever e apagar no mesmo bucket — ou seja, independentemente da autorização ou da intenção do humano, o sobre-privilégio amplo do agente pode introduzir risco.
O que torna esta acumulação de acessos tão insidiosa é a ausência de mecanismos de revisão. As revisões de acesso humanas estão ligadas a eventos como a integração ou a saída de colaboradores, sinais que os agentes de IA nunca geram, pelo que novas permissões e integrações podem ser adicionadas sem despoletar qualquer revisão formal. Pior ainda: as identidades de agentes carecem frequentemente de controlos de ciclo de vida equivalentes, deixando credenciais, tokens e contas de serviço ativas depois de um agente ser substituído, reconfigurado ou desativado — estas identidades obsoletas alargam a superfície de ataque e criam caminhos de acesso que as equipas de segurança podem já nem saber que existem.
A remediação manual, por sua vez, esbarra num obstáculo humano muito concreto. Uma equipa de operações cloud de cinco a dez engenheiros a rever permissões em centenas de contas e milhares de identidades não é um modelo sustentável, e o bloqueio prático vai além da consciencialização e da escala — inclui o medo, porque uma única alteração errada numa política IAM sobre uma carga de trabalho em execução pode provocar uma interrupção.
A dimensão do problema em números
A escala das identidades não-humanas já ultrapassou largamente a das identidades humanas. Segundo dados apresentados pela Cloud Security Alliance, existem hoje 45 identidades não-humanas por cada identidade humana — um número que se espera que aumente com a crescente adoção de agentes de IA. A falta de governação é generalizada: uma análise do Fórum Económico Mundial de 2025 concluiu que 51% das organizações não reportam qualquer propriedade clara das identidades de IA.
Os custos deste vazio de governação são mensuráveis. O relatório Cost of a Data Breach 2025 da IBM/Ponemon é claro: uma em cada cinco organizações estudadas (20%) sofreu violações ligadas a “shadow AI” — ferramentas de IA não sancionadas adotadas por colaboradores sem supervisão de TI ou segurança — e estes incidentes acrescentaram até 670 mil dólares ao custo médio de uma violação, expondo de forma desproporcionada dados pessoais de clientes e propriedade intelectual. A dimensão do descontrolo fica evidente noutros dois números do mesmo relatório: 97% das violações relacionadas com IA ocorreram em empresas sem controlos de acesso adequados, e 63% não tinham quaisquer políticas formais de governação de IA.
Olhando para o futuro, as projeções apontam para uma pressão crescente. A Gartner prevê que, até 2028, 25% das aplicações empresariais de IA generativa venham a sofrer pelo menos cinco incidentes de segurança menores por ano, face a 9% em 2025. E a autonomia vai aumentar: a Gartner prevê que, até 2028, pelo menos 15% das decisões de trabalho do dia-a-dia sejam tomadas de forma autónoma através de IA agêntica.
Um risco que os controlos tradicionais não apanham
As defesas de segurança clássicas partem de um pressuposto que os agentes de IA quebram. Assumem que a atividade autenticada é legítima, o que torna os controlos legados em potenciais pontos de falha. Nem todos os riscos vêm de atacantes maliciosos: pode ocorrer dano significativo a partir de um agente que comete pequenos erros repetidos de forma autónoma — é o conceito de “falha à escala” — e é comum que os agentes recebam permissões muito além do que precisam para desempenhar as suas funções, violando o princípio de menor privilégio.
A consequência é direta: se um atacante comprometer um agente, ganha instantaneamente acesso a todos os sistemas e conjuntos de dados que o agente consegue ver, transformando-o num poderoso ameaça interna. Além da injeção de prompt, o vetor identitário é dos que mais preocupam os investigadores. Ao contrário do software tradicional que segue caminhos lógicos predeterminados, os agentes de IA tomam decisões contextuais, acedem a múltiplas fontes de dados e operam frequentemente com privilégios elevados em plataformas SaaS e ambientes cloud.
Como reduzir o raio de destruição
As recomendações dos investigadores convergem em torno de alguns princípios práticos:
- Inventário primeiro. Completar o inventário e a classificação antes de qualquer outra coisa, e identificar e remediar de imediato todos os agentes órfãos com credenciais de nível de administração.
- Políticas ligadas à ação, não só ao papel. Definir o que cada identidade não-humana pode fazer, que ferramentas pode usar e sob que condições essas ações são permitidas.
- Governação separada por tipo de identidade. Não forçar uma única revisão de acesso, um único processo de saída ou uma única cadência de certificação a todos os tipos de identidade — humana, NHI e autónoma.
- Aprovação humana para ações de alto risco. Ações de alto risco, como apagar dados, alterar permissões ou aceder a informação sensível, devem exigir sempre aprovação humana.
- Segurança com rede de recuo. Construir procedimentos de reversão antes de apertar permissões: documentar o que foi alterado, quem aprovou e qual o caminho de restauro caso um fluxo de trabalho parta.
Porque é que isto importa em Portugal
Para cidadãos, PME e organizações em Portugal, este tema deixou de ser teórico. A ENISA sublinha que 2025 foi o ano em que a IA reconfigurou o panorama de ameaças europeu, com técnicas como a injeção de prompt e o envenenamento de contexto a ganharem relevo — precisamente os vetores que exploram agentes sobre-privilegiados. Ao mesmo tempo, o novo Regime Jurídico da Cibersegurança (Decreto-Lei n.º 125/2025, que transpõe a diretiva NIS2) impõe às entidades abrangidas obrigações reforçadas de gestão de risco e de controlo de acessos — obrigações que abrangem também as identidades máquina e os agentes autónomos que operam sobre dados críticos. O CNCS e o CERT.PT recomendam de forma consistente a aplicação do menor privilégio e a autenticação multifator como higiene de base.
Há ainda uma dimensão de proteção de dados: quando um agente sobre-privilegiado acede ou expõe dados pessoais, as consequências recaem sobre o responsável pelo tratamento à luz do RGPD, com potencial obrigação de notificação à CNPD e aos titulares. Governar as identidades dos agentes de IA não é, portanto, apenas uma boa prática técnica — é uma peça de conformidade legal que as organizações portuguesas terão de assumir à medida que a IA agêntica entra nos seus processos.
Perguntas frequentes
O que é uma identidade não-humana (NHI)?
É uma credencial usada por sistemas em vez de pessoas — contas de serviço, chaves de API, tokens de autenticação, papéis IAM e segredos. Os agentes de IA dependem destas identidades para aceder a sistemas e dados, e elas já ultrapassam largamente em número as identidades humanas nas organizações.
Porque é que um agente de IA sobre-privilegiado é perigoso?
Porque, se for manipulado ou comprometido, não precisa de invadir nada: usa as permissões amplas que já lhe foram concedidas. Como opera à velocidade da máquina e em múltiplos sistemas, um único agente comprometido pode ter um raio de destruição enorme, expondo dados sensíveis de toda a organização.
O que é injeção de prompt e como se relaciona com as permissões?
É uma técnica em que um atacante manipula as instruções que o agente recebe para o levar a executar ações indevidas. O dano depende das permissões do agente: com menor privilégio, o impacto de uma injeção bem-sucedida é limitado; com acessos amplos, pode ser devastador.
Como pode uma PME começar a controlar isto?
Começar pelo inventário: saber que agentes e identidades máquina existem e a que têm acesso. A seguir, remover agentes órfãos com credenciais de administrador, aplicar o menor privilégio, exigir aprovação humana para ações de alto risco e definir um processo de ciclo de vida que desative credenciais quando o agente deixa de ser usado.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente por investigadores de segurança, pela IBM/Ponemon (Cost of a Data Breach 2025), pela Cloud Security Alliance, pelo Fórum Económico Mundial, pela Gartner e pela ENISA.