A NIS2 nasceu num mundo em que a conversa pública sobre risco gira sobretudo em torno da indisponibilidade: ransomware, DDoS, falhas de fornecedores. A própria diretiva, porém, é mais ampla e agnóstica: exige gestão de risco, controlo de acessos e segurança da cadeia de abastecimento, entre outros aspetos
|
E eis que, no início de 2026, os agentes de IA começam a ser usados de forma alargada, ao princípio, pelo menos, em desenvolvimento de software, e mudam o eixo da conversa. Quando uma aplicação, tenha ela a forma que tiver, deixa de ser ferramenta e passa a ser um “colega” que decide, escreve código, abre tickets, transfere ficheiros, envia emails e negocia com API, a superfície de ataque deixa de ser perímetro e passa a ser comportamento. Os agentes introduzem brechas novas e ainda mal enquadradas na prática regulatória e operacional: identidade delegada (tokens persistentes, chaves partilhadas, service accounts sem dono), permissões acumulativas (cada integração acrescenta um caminho de exfiltração de dados), prompt injection e envenenamento de dados (o atacante persuade em vez de explorar portas), cadeias de ferramentas e plugins com dependências opacas, e atualizações de modelo que alteram decisões em produção sem controlo de alteração. Há também um problema de prova: como demonstrar, num incidente, o que o agente “viu”, que contexto recebeu, que ferramentas acionou e por que executou uma ação concreta? Isto já não é hipotético. Há organizações a dar a agentes privilégios de escrita em repositórios, sistemas de CRM e de faturação, bases de dados e fluxos de aprovação. Um erro ou manipulação passa a ter a escala e a velocidade de um utilizador super-privilegiado, mas sem o instinto humano de cautela. E quando o agente falha, a tentação é atribuir o evento à imprevisibilidade do modelo, como se isso fosse justificação plausível, ignorando que a responsabilidade emerge da cadeia inteira: modelo base, fornecedor, integrador e entidade que delega credenciais. É aqui que se começa a desenhar uma NIS3, ou equivalente, que torne explícitos os cuidados a ter neste novo mundo. Não por falta de regras, mas por falta de encaixe entre governação da entidade e segurança do sistema de IA. Terá de tratar agentes como infra-estruturas operacionais autónomas: inventário obrigatório (o que existe, onde atua, com que credenciais), limites de autonomia por classe de risco, segregação e rotação de credenciais, privilégio mínimo com elevação controlada, registos auditáveis que permitam reconstruir a sequência factual (inputs, contexto entregue, ferramentas invocadas e outputs), testes de segurança específicos para interação (red teaming de prompts e de cadeias de ferramentas), e deveres claros para fornecedores e integradores sobre actualizações, deriva de comportamento e vulnerabilidades conhecidas. E na notificação de incidentes, “foi o agente” não pode funcionar como biombo: tem de haver responsabilidade técnica e organizacional, distribuída com critério ao longo da cadeia. No novo mundo dos agentes, um pedido, ainda que bem formulado, pode tornar-se a vulnerabilidade dominante. A regulação tem de acompanhar esta mudança antes que a autonomia se transforme em ataque por procuração. |
Receba todas as novidades na sua caixa de correio!
