A nova governação de identidades para agentes de IA e workloads

A gestão do ciclo de vida de identidades que reina na maioria das empresas foi desenhada pensando em pessoas: alta em RR. HH., com um gerente, com mudanças de posto documentados e uma data de saída. Esse modelo funciona porque se baseia em sinais estruturados (altas, transferências, baixas) que disparam provisão, recertificação e desprovisão. No entanto, essa arquitetura não se encaixa quando o principal não é humano: os agentes de IA e as identidades de workload emergem de pipelines, contêineres e APIs, sem passar pela portagem de RR. HH., sem um dono claro e sem os eventos administrativos que alimentam as ferramentas IGA tradicionais.

O problema não é puramente teórico. Quando uma identidade entra no ambiente sem um registro de incorporação e com credenciais emitidas pela própria pipeline, a visibilidade e o controle se quebram. Esses agentes podem ampliar sua superfície de acesso em execução, bifurcar-se em múltiplas instâncias com credenciais díspares, delegar tarefas a sub-agentes e persistir com chaves ou tokens que nunca foram revogados. O resultado prático é simples: credenciais sobredimensionadas, ausência de histórico de aprovação, revisões de acesso que atestam registros obsoletos e caminhos de acesso que permanecem abertos muito após o workload desapareciera.

As consequências ultrapassam a higiene operacional. Do ponto de vista de segurança, um token de agente sem rotação ou responsabilidade definida facilita a escalada de privilégios e a exfiltração encadeada através de APIs. Em termos de cumprimento, auditorias que confiam em provas de HR e em campanhas de recertificação trimestrais obterão um registo formal “verde” enquanto a atividade real mostra um panorama diferente; isso agrava o risco legal e regulatório em ambientes sujeitos a SOX, HIPAA ou normas setoriais. Em resposta a incidentes, a falta de correlação entre identidade, dono e propósito complica a contenção e a atribuição.

A boa notícia é que a solução não passa por forçar um modelo de RR. HH. sobre agentes, mas sim por reconstruir a governação segundo as características operacionais desses principais. Isso implica três eixos técnicos e organizacionais: descoberta contínua de identidades onde realmente vivem (IAM de nuvem, servidores de autorizações OAuth, Kubernetes, gestores de segredos, registros de CI/CD), um modelo de atributos específico para agentes(equipamento proprietário, finalidade operacional, perímetro autorizado, data de expiração esperada) e controlos em tempo real que tratem os desvios de comportamento como eventos de governança e não como achados trimestrais.

No plano técnico, é conveniente adoptar práticas comprovadas: emitir credenciais efímeras quando possível (tokens de curta vida via STS ou fluxos OIDC), integrar federação de identidades para workloads(Workload Identity Federation of Azure ou soluções equivalentes no Google Cloud) e centralizar a gestão de segredos com rotação automática em gestores como AWS Secrets Manager, Azure Key Vault ou HashiCorp Vault. A documentação e as políticas devem ser impostas na canalização: qualquer implantação que crie um agente e solicite permissões deve gerar um ticket de governança ou endpoint de aprovação que seja registrado na plataforma IGA ou num catálogo de riscos. Microsoft e Google oferecem guias práticas sobre federação de identidades para workloads que são relevantes para essa abordagem: guia Azure Workload Identity Federation e Documentação do Google Workload Identity Federation.

A observabilidade é o outro pilar: instrumentar APIs e fluxos de agent-to-service, exportar telemetria para SIEM/UEBA e construir linhas base do comportamento normal do agente permite definir alertas quando um agente solicita scopes novos, eleva privilégios ou acessa dados que não correspondiam com seu propósito documentado. Em vez de esperar pela próxima campanha de recertificação, essas divergências devem ser traduzidas em workflows automáticos que limitem permissões, disparem revisões de risco e peçam re-autorização para a equipe proprietário. As boas práticas de desenvolvimento seguro e API estão coletadas em recursos como o projeto OWASP API Security: OWASP API Security, que oferece controles aplicáveis ao design e proteção de interfaces que os agentes consomem.

Quanto à governação e aos processos, a recomendação é clara: defina um atributo obrigatório para cada agente antes da sua primeira execução em produção — dono (equipamento ou pessoa), propósito funcional, lista de APIs autorizadas e janela de vida prevista — e faça com que o fornecimento de licenças dependa desse registo. Defina regras de política como código que rejeitem implantaçãos que solicitem scopes fora dos padrões aprovados e automatice a revogação para credenciais inativas através de políticas de caducidade e telemetria de uso.

A integração entre pipeline e IGA deve ser bidirecional: os pipelines não são um “foro livre” para criar identidades, mas um ponto de controle que deve submeter pedidos de acesso a guardrails. Isso é obtido com portas CI/CD que validen pedidos de IAM contra catálogos de risco e modelos de least-privilege, com documentação automática no inventário de identidades e com auditoria legível por cumprimento. Os testes operacionais devem incluir exercícios de "red team" e simulações de roubos de tokens para validar que a rotação, o corte de acesso e a detecção funcionam sob pressão.

A transformação é incremental: comece por identificar os agentes que acessam recursos sensíveis (bases de dados com PII, segredos críticos, serviços financeiros) e desenrede suas cadeias de credenciais; estabeleça telemetria e políticas para esses casos antes de abranger massas de workloads menos críticos. Em paralelo, amplie a capacidade de descoberta para eliminar a "caixa negra" de identidades não visíveis e vincule cada identidade nova a um processo de aprovação automatizado.

Se a sua organização quiser alinhar o seu modelo de ciclo de vida de identidades com a realidade de agentes autônomos, a receita combina tecnologia, processos e responsabilidade. Visibilidade contínua, atributos de identidade concebidos para agentes e controlos em tempo real São a base para evitar que centenas ou milhares de credenciais órfãs se tornem vetores exploráveis. Não basta confiar em campanhas trimestrais: os agentes exigem uma governação permanente e ligada à infraestrutura que os cria e os executa.