Thiago R. de Souza (*)
Há muito tempo, empresas têm investido milhões para responder a uma pergunta aparentemente simples: quem pode acessar o quê? Criamos políticas de identidade, autenticação multifator, segregação de funções, princípio do menor privilégio e mecanismos de auditoria. Porém, agora, a inteligência artificial está obrigando as organizações a fazerem a mesma pergunta para um novo tipo de usuário: a máquina. Afinal, agentes já podem consultar bancos de dados, acessar documentos, executar códigos, interagir com APIs, movimentar informações entre sistemas e iniciar ações sem que uma pessoa acompanhe cada etapa.
Nesse novo cenário, o Gartner colocou as chamadas AI Security Platforms entre as dez principais tendências estratégicas de tecnologia para 2026. Ou seja, plataformas voltadas a centralizar controles e ampliar a visibilidade sobre o uso de aplicações de inteligência artificial, tanto desenvolvidas internamente quanto fornecidas por terceiros. A preocupação faz sentido: o Cloud Security Report 2025, da Check Point, mostrou que 68% das organizações pesquisadas classificavam a adoção de IA como uma prioridade de cibersegurança. Ao mesmo tempo, apenas 25% afirmavam estar preparadas para lidar com ataques conduzidos por máquinas.
Uma das questões que considero mais críticas está na identidade dos agentes de IA. Em uma arquitetura tradicional, um funcionário recebe uma identidade, pertence a determinados grupos e possui permissões compatíveis com sua função. Há processos para conceder, revisar e retirar esses acessos. Com agentes de IA, essa lógica precisa ser ainda mais rigorosa. Um agente pode receber acesso a um banco de dados, consultar documentos internos, chamar diferentes APIs e acionar outras ferramentas para concluir uma única tarefa. Se essas permissões forem excessivas, uma instrução maliciosa ou mesmo um comportamento inesperado, e é exatamente por isso que considero perigoso tratar segurança de IA somente como um problema do modelo.
Se um agente precisa consultar um sistema para realizar determinada tarefa, isso não significa que deva ter acesso permanente a todas as informações daquele ambiente. Se precisa executar uma ação específica, não deveria automaticamente receber permissão para realizar dez outras. É a lógica do Zero Trust: verificar continuamente identidades e acessos e conceder apenas o necessário. O princípio do menor privilégio precisa chegar à IA, o que envolve identidades específicas para agentes, credenciais temporárias sempre que possível, segregação de funções, rastreabilidade das ações, limites claros de autonomia e mecanismos de aprovação humana para operações críticas.
Há uma pergunta simples que considero útil para qualquer organização que esteja implantando agentes: se esse agente cometer um erro ou for manipulado agora, até onde ele consegue chegar? Se ninguém consegue responder rapidamente, existe um problema de arquitetura antes mesmo de existir um ataque.
Outra prática que tende a ganhar relevância é o chamado AI Red Teaming, no qual equipes assumem o papel de adversários para descobrir como determinado sistema pode ser enganado ou levado a executar comportamentos inesperados. É possível induzi-lo a revelar informações que não deveria? Uma instrução escondida em um documento pode modificar seu comportamento? Ele consegue acessar uma API fora do escopo previsto? É possível fazê-lo executar uma ação sem a autorização adequada? Esses testes precisam acontecer antes que as respostas sejam descobertas em um incidente real.
Empresas passaram décadas seguindo a lógica de que nenhum funcionário deveria possuir acesso ilimitado apenas porque era confiável. Agora precisamos aplicar a mesma maturidade aos agentes de inteligência artificial.
(*) Senior Cloud/DevOps Engineer com mais de nove anos de experiência em infraestrutura corporativa, AWS Community Builder e detentor de múltiplas certificações AWS nos níveis Professional e Specialty.
Vigiar e punir, com transparência e responsabilidade | Jornal Empresas & Negócios
