Identidade com intenção: a chave para controlar os agentes da IA que já operam em produção

Há apenas alguns anos, a implantação de inteligência artificial na empresa costumava significar assistentes que redigiam e-mails ou resumiam documentos. Hoje, esses mesmos sistemas deixaram de ser meros copilotos: provisionam infraestrutura, resolvem tickets de suporte, priorizam alertas, aprovam transações e até escrevem código que chega à produção. Em poucas palavras, Os agentes da IA já não são assistentes passivos: atuam como operadores dentro da organização.

Isso obriga os responsáveis pela segurança — os CISOs — a reenfocar um problema conhecido mas agora muito mais complexo: o controle de acesso. Cada agente se autentica contra APIs, serviços na nuvem e ferramentas de terceiros usando chaves, tokens OAuth, papéis de nuvem ou contas de serviço. Leia dados, escreve configurações e encadeia chamadas a outros sistemas. No mundo técnico, um agente da IA se comporta exatamente como uma identidade, mas em muitos ambientes não se governa como tal.

A realidade operacional é simples e perigosa: muitos agentes herdam privilégios do seu criador, executam-se com contas demasiado amplas para “que tudo funcione” e evoluem mais rápido que os controles que os rodeiam. Essa combinação produz o que já pode ser considerada uma zona cega emergente em segurança da IA. A primeira resposta óbvia é aplicar uma abordagem de identidade para os agentes: tratar cada agente como uma identidade de primeira classe com ciclo de vida, propriedade, papéis e rastreabilidade. No entanto, há uma segunda verdade que complica o panorama: a identidade por si só já não basta.

Os modelos tradicionais de gestão de identidade e acesso (IAM) respondem a uma pergunta concreta: quem solicita o acesso? Em ambientes centrados em pessoas ou serviços estáticos, isso poderia ser suficiente porque os papéis e funções eram previsíveis. Mas os agentes da IA são dinâmicos por design: interpretam objetivos, planejam passos e encadeiam ferramentas de acordo com o contexto. Um agente que arranca com a missão de gerar um relatório trimestral poderia, se for orientado ou manipulado, tentar aceder a sistemas alheios ao relatório. Um agente de remediação pode desviar-se e modificar configurações que excedem seu propósito original.

Esse comportamento rompe a suposição de determinismo em que se baseia o acesso estático: se o papel o permite, a ação é executada embora já não coincida com a razão original da existência do agente. Aqui entra a necessidade de um passo além do IAM clássico: as permissões baseadas na intenção Se a identidade responde ao “quem”, a intenção responde ao “por que”.

Permitir que um agente active privilégios apenas quando a sua missão declarada e o seu contexto de execução justifiquem essa ativação transforma o controle de acesso. Em vez de um mapa estático entre identidade e permissões, o sistema avalia se o propósito e as condições em tempo de execução autorizariam esse acesso. Por exemplo, um agente de implantação poderia ter a capacidade de modificar infra-estruturas, mas esses privilégios só são ativados se a ação for realizada a partir de uma canalização aprovada e em resposta a uma mudança autorizada. Se o mesmo agente tenta tocar produção fora desse fluxo, as credenciais não permitem a operação.

Esta abordagem composta atenua duas falhas recorrentes. Por um lado, a herança de privilégios: é habitual que desenvolvedores tentem agentes com credenciais próprias elevadas e essas credenciais perdurem em produção. Se cada agente tem identidade própria e gerenciada, esse “sangramento” desaparece. Por outro lado, a deriva de missão: os agentes podem pivotar por prompts, integrações ou ataques; as políticas baseadas em intenção impedem que esse pivot se torne acesso não autorizado.

Mas além do fechamento de riscos concretos, há um argumento organizacional poderoso: governação a nível. Em ecossistemas onde um agente pode invocar milhares de APIs e recursos em múltiplas nuvens e SaaS, gerenciar cada permissão como uma regra separada conduz rapidamente a uma explosão de políticas difícil de auditar. Um modelo de intenção simplifica a supervisão: em vez de rever cada chamada possível, os responsáveis auditam perfis de identidade e limites de intenção aprovados. As revisões de política visam se a missão autorizada faz sentido, não inventariar cada endpoint que um agente poderia tocar.

A rastreabilidade também melhora. Em um incidente, não importa apenas saber qual identidade executou uma ação, mas que perfil de intenção estava ativo e se a operação foi alinhada com a missão autorizada. Essa granularidade de contexto é cada vez mais relevante para a responsabilização perante reguladores e diretórios executivos. Para as equipes técnicas, além disso, facilita a pesquisa e a resposta rápida.

Estas ideias não são apenas teoria: elas ligam com marcos e práticas que há anos se consolidam em segurança, como os princípios da Zero Trust ou os modelos baseados em atributos. Recursos como o quadro de gestão dos riscos da IA do NIST (NIST AI RMF), as recomendações de controle de acesso baseadas em atributos (NIST SP 800-162) e a estratégia da Zero Trust (NIST SP 800-207) Eles oferecem princípios que encaixam nesta abordagem de identidade+intenção. Além disso, organizações como a Cloud Security Alliance e projectos comunitários como OWASP começam a documentar riscos e controles específicos para sistemas de IA.

E que medidas práticas podem começar a aplicar as equipas de segurança hoje? O caminho arranca por um inventário claro de agentes e suas capacidades, atribuindo-lhes identidades únicas com gestão de ciclo de vida e proprietários responsáveis. A partir daí, convém definir, por escrito, a missão aprovada de cada agente e os limites operacionais em que pode agir. Essa documentação deve ser integrada com mecanismos técnicos que condicionem a ativação de privilégios à coincidência entre identidade, intenção declarada e contexto em tempo de execução.

Em paralelo, há que instrumentar a supervisão: registros enriquecidos que mostrem não só o que foi feito e por quem, mas qual era a intenção associada e quais sinais de contexto (pipeline, origem da petição, autenticação multifator, etc.) permitiram a ação. Finalmente, automatizar a rotação de credenciais, a revogação do termo do ciclo de vida e as verificações periódicas de desvio de missão reduz a exposição e clarifica a governança.

A alternativa é perigosa: permitir autonomia sem governança multiplica o risco; ter identidade sem intenção deixa lacunas. Na era agentic, entender quem atua é necessário, mas garantir que atua pela razão certa é o que torna a IA segura. Para os CISOs, adaptar processos, ferramentas e revisão de políticas a esta realidade não é uma opção, é uma obrigação para manter controle, cumprimento e resiliência.

Se você quer aprofundar os quadros e recomendações práticas, comece pelos recursos do NIST sobre IA e controle de acesso que mencionei, e pela documentação e boas práticas que publicam iniciativas como a Cloud Security Alliance. A conversa sobre como implementar controlos de identidade e autorização de intenção começa apenas, e é imprescindível que abordem equipamentos de segurança, engenharia e conformidade de forma coordenada.