O Microsoft Entra colocou em prévia políticas de ciclo de vida para identidades de agentes de IA. Elas permitem exigir reconfirmação periódica, número mínimo de patrocinadores e monitoramento de inatividade, com ações de desativação ou exclusão. A Microsoft também anunciou uma política padrão que avisa o responsável depois de 60 dias sem atividade e desativa a identidade se ela continuar sem uso. O objetivo é impedir que agentes esquecidos mantenham acesso indefinido a dados e sistemas.
Comece por um inventário com responsabilidade clara
Liste cada agente, identidade usada, finalidade, proprietário, patrocinador, ambientes, permissões e última atividade. Uma identidade sem responsável não deve depender de uma caixa de email abandonada. Defina também um destinatário alternativo para receber avisos quando não houver patrocinador ou proprietário válido.
Separe identidade do agente, identidade de serviço e conta humana. Compartilhar uma conta genérica dificulta saber qual automação acessou um recurso e impede aplicar um ciclo de vida específico. Cada identidade deve existir por uma finalidade documentada e ter prazo de revisão.
- Agente, ambiente e processo atendido
- Proprietário técnico e patrocinador de negócio
- Permissões, dados e sistemas alcançados
- Data da última emissão de token ou uso confirmado
- Procedimento de desativação e recuperação
Entenda a prévia e os requisitos
A política de ciclo de vida está em prévia, sem acordo de nível de serviço, e a documentação não recomenda recursos de prévia para cargas de produção. Os requisitos informados incluem Microsoft 365 E7 ou uma licença Microsoft Agent 365 combinada com Microsoft Entra P1 ou Microsoft 365 E3, além de uma função administrativa compatível.
A política padrão de inatividade anunciada pela Microsoft está disponível para todos os tenants sem licença adicional, mas outras regras e ações dependem do produto e do plano. Confirme o contrato, a região e o comportamento observado no próprio tenant antes de tratar o recurso como controle obrigatório.
Configure reconfirmação, patrocinadores e inatividade
A reconfirmação periódica obriga o patrocinador ou proprietário a declarar que a identidade ainda é necessária. O intervalo configurável vai de 30 a 730 dias. Use períodos menores para agentes com acesso amplo ou dados sensíveis e maiores para automações estáveis de baixo risco, sem transformar a revisão em uma aprovação automática.
A exigência mínima de patrocinadores cria responsabilidade e envia a violação para quem pode corrigir a situação. O monitoramento de inatividade considera a ausência de tokens emitidos durante o período definido. Falta de uso é um sinal útil, mas não prova que a identidade pode ser apagada sem verificar tarefas sazonais, contingência e dependências externas.
Escolha ações e prazo de correção
A política pode desativar, excluir ou desativar e excluir depois de um prazo. Prefira desativar primeiro quando ainda existe dúvida sobre dependências. Defina um período de carência para que o responsável possa reconfirmar a necessidade, adicionar patrocinadores ou encerrar o agente de forma planejada.
Exclusão deve considerar logs, auditoria, retenção e recuperação. Guarde a configuração e o motivo da ação sem reter dados além do necessário. O processo precisa impedir novos acessos imediatamente quando houver risco, mas preservar evidência suficiente para investigação e restauração autorizada.
Teste em poucas identidades antes de ampliar
A Microsoft recomenda selecionar identidades específicas no piloto, usar a frequência mínima de 30 dias para testar reconfirmação e confirmar que avisos chegam aos destinatários esperados. Verifique se o patrocinador consegue estender ou desativar a identidade e se uma violação não corrigida aciona a ação configurada.
Quando mais de uma política alcança a mesma identidade, a de maior prioridade prevalece. Mapeie sobreposições antes de ativar. Uma regra geral pode impedir uma política mais rigorosa se estiver acima dela ou desativar um agente crítico por não considerar uma exceção legítima.
Acompanhe atividade e exceções fora do Entra
Emissão de token não mostra se o agente concluiu trabalho correto nem se a permissão continua proporcional. Combine o ciclo de vida com logs de ações, dados acessados, ferramentas chamadas, custo, falhas e aprovações. Revise permissões quando o processo, o modelo ou a integração mudar.
Exceções precisam de responsável, justificativa, data de término e compensações. Um agente de contingência pode permanecer inativo por meses, mas deve ter credenciais protegidas, teste periódico e ativação controlada. Não use uma exceção permanente para evitar corrigir um fluxo sem proprietário.
Trate a identidade como parte da governança do agente
Desativar identidades esquecidas reduz superfície de ataque, mas não corrige prompt injection, excesso de autonomia, vazamento em ferramentas ou decisões incorretas. A empresa ainda precisa de menor privilégio, rede limitada, segredos rotacionados, revisão humana e um caminho para interromper a execução.
Crie uma revisão trimestral que una inventário, atividade, permissões, responsáveis e incidentes. O agente só deve permanecer ativo quando existe finalidade atual, proprietário identificável e evidência de que seu acesso continua necessário. A ausência de um desses elementos deve gerar correção ou retirada.
Para levar daqui
Políticas de ciclo de vida ajudam a retirar identidades esquecidas, mas precisam de inventário, patrocinadores, piloto e integração com logs e menor privilégio para reduzir risco de verdade.
