Governança de agentes Copilot Studio: o que a v3.2 muda

O problema que a v3.2 tenta resolver

Toda organização que liberou o Copilot Studio para além do time central de TI chegou, em algum momento, ao mesmo ponto: dezenas de agentes publicados, cada um com dono diferente, conectores diferentes e nível de exposição de dados que ninguém documentou. Funciona até funcionar mal, e quando funciona mal, geralmente é porque um agente com acesso a um conector de e-mail ou SharePoint foi construído por alguém fora da área de segurança, sem revisão de escopo, sem DLP aplicada e sem trilha de auditoria clara.

A Microsoft atualizou o whitepaper Administering and Governing Agents para a versão 3.2 justamente para dar resposta estrutural a esse cenário. Não é uma lista de boas práticas genéricas. É um modelo de arquitetura com três peças que se encaixam: zoneamento por Environment Groups, visibilidade centralizada via Agent 365 e controle de distribuição pelo Microsoft 365 Agent Store. As três juntas mudam a forma como um administrador de tenant enxerga e controla o ciclo de vida de um agente, do protótipo à produção.

O modelo de zonas por Environment Groups

O Power Platform já permitia agrupar ambientes em Environment Groups para aplicar políticas de DLP, regras de conexão e configurações de segurança em lote. O que a v3.2 formaliza é o uso desse recurso como mecanismo de zoneamento de risco para agentes, não só de ambientes de aplicação em geral.

Na prática, isso significa desenhar grupos de ambiente que representam estágios de maturidade e nível de exposição, por exemplo:

• Zona de experimentação: ambientes onde qualquer maker autorizado pode criar e testar agentes, com DLP restritiva por padrão e sem conectores de produção liberados.
• Zona de validação: ambientes intermediários onde o agente passa por revisão de segurança, teste de prompt injection e checagem de escopo de dados antes de avançar.
• Zona de produção: ambientes com políticas de DLP alinhadas à classificação de dados do tenant, conectores aprovados explicitamente e agentes publicados só depois de aprovação formal.

O ganho arquitetural aqui é que a política deixa de ser amarrada a um agente individual e passa a ser amarrada ao ambiente onde ele vive. Isso resolve um problema real do Copilot Studio: sem Environment Groups bem desenhados, cada agente novo herda regras de DLP inconsistentes, dependendo de qual ambiente o maker escolheu na hora de criar. Com zoneamento, a regra é do grupo, e o agente simplesmente nasce dentro do perímetro certo.

A pegadinha fica na migração. Se sua organização já tem agentes espalhados em ambientes default ou em ambientes pessoais de maker, mover esses agentes para dentro de um Environment Group exige recriar a topologia de ambientes, reatribuir conexões e, em muitos casos, reconstruir o agente do zero porque conectores personalizados amarrados a um ambiente antigo nem sempre migram limpos. Não é um switch que se liga, é um projeto de reestruturação.

Agent 365: visibilidade que hoje não existe

A segunda peça do modelo é o que o whitepaper trata como camada de observabilidade e identidade para agentes, associada ao Agent 365. A ideia central é simples de enunciar e difícil de implementar sem essa estrutura: todo agente deveria ter uma identidade rastreável no Entra, um dono humano designado, um inventário central de quais dados ele acessa e um log de atividade que um administrador consegue consultar sem precisar entrar agente por agente no Copilot Studio.

Hoje, na maioria dos tenants, essa visibilidade não existe de forma consolidada. Um administrador de segurança sabe quantos usuários do Microsoft 365 existem, mas raramente sabe quantos agentes de Copilot Studio, Copilot Chat com conectores personalizados ou agentes autônomos publicados via Teams estão ativos, muito menos qual é a superfície de dados que cada um toca. Agent 365 propõe fechar essa lacuna tratando o agente como uma identidade de primeira classe, no mesmo sentido em que um usuário ou uma service principal são identidades de primeira classe no Entra ID.

Na prática de operação, isso muda três coisas:

• Auditoria deixa de ser manual. Em vez de rodar consultas ad hoc no Purview para tentar reconstruir o que um agente fez, o administrador consulta um registro central por identidade de agente.
• Revogação de acesso é imediata e granular. Suspender um agente específico não exige desligar um ambiente inteiro ou revogar credenciais compartilhadas com outros fluxos.
• Detecção de comportamento anômalo se torna possível. Um agente que passa a acessar um volume de dados fora do padrão histórico pode gerar alerta, algo impraticável quando não há linha de base de atividade por agente.

O ponto de atenção é que essa camada de visibilidade só entrega valor se a identidade do agente for consistente desde a criação. Agentes criados fora do fluxo recomendado, sem vínculo claro de propriedade e sem registro correto no Entra, aparecem como pontos cegos mesmo depois que o Agent 365 estiver ativo. Governança retroativa em identidade é sempre mais cara que governança desde o início.

Microsoft 365 Agent Store como ponto de controle de acesso

A terceira peça fecha o ciclo: quem pode instalar o quê. O Microsoft 365 Agent Store, evolução da distribuição de agentes dentro do ecossistema Microsoft 365, passa a funcionar como o ponto único onde administradores decidem quais agentes, internos ou de terceiros, ficam disponíveis para instalação por usuários finais.

Isso resolve um problema de shadow IT específico de IA generativa: usuário final encontra um agente de terceiro publicado por um ISV, instala em nome próprio via Teams ou Copilot Chat, e concede permissões de acesso a dados corporativos sem que a área de segurança tenha sido consultada. O modelo de controle de acesso descrito no whitepaper trata o Agent Store como um portão administrável, com aprovação prévia, listas de permissão por departamento ou perfil de risco, e bloqueio padrão para agentes não avaliados.

Do ponto de vista de arquitetura, o Agent Store se conecta com as outras duas peças da seguinte forma: um agente só chega ao catálogo interno depois de passar pela zona de validação nos Environment Groups, e uma vez instalado, sua atividade passa a ser rastreada pela camada de visibilidade do Agent 365. As três peças não são independentes, são estágios de um mesmo pipeline de governança.

O impacto real para quem já tem agentes em produção

Aqui está o ponto que mais importa para quem lê este artigo pensando na própria operação: nada disso é retroativo por padrão. Se sua organização já publicou agentes de Copilot Studio sem Environment Groups definidos, sem DLP consistente e sem inventário central, adotar o modelo da v3.2 significa um trabalho de descoberta e reclassificação antes de qualquer ganho de segurança aparecer.

O primeiro passo, na prática, não é técnico, é de inventário. Antes de desenhar zonas ou configurar o Agent Store, é preciso responder três perguntas para cada agente ativo no tenant:

• Quem é o dono de negócio e quem é o responsável técnico?
• Quais conectores e fontes de dados o agente acessa, e essas fontes têm classificação de sensibilidade definida no Purview?
• O agente está em ambiente default, ambiente pessoal de maker ou em um Environment Group já governado?

Agentes que aparecem em ambiente default ou pessoal são o sinal mais claro de dívida de governança. Eles não têm política de DLP herdada de grupo, muitas vezes não têm dono formalizado e, em geral, foram os primeiros a nascer, exatamente porque o Copilot Studio facilita demais a criação de um agente por qualquer maker licenciado. Migrá-los para uma zona apropriada exige recriar conexões, revalidar escopo de permissão e, em alguns casos, reconstruir partes do agente, porque nem toda configuração migra automaticamente entre ambientes.

Vale registrar um trade-off de licenciamento que costuma pegar times de TI de surpresa: capacidades avançadas de observabilidade e controle centralizadas via Agent 365 e via políticas mais granulares de Environment Groups tendem a estar atreladas a camadas de licenciamento do Power Platform e do Microsoft 365 que nem todo tenant já tem contratadas. Antes de desenhar a arquitetura de zonas, vale confirmar com o time de licenciamento quais SKUs cobrem quais partes do modelo, porque o whitepaper descreve a capacidade, não o custo dela para o seu ambiente específico.

Como priorizar a adoção sem parar a operação

Não é realista congelar a criação de agentes até que todo o modelo esteja implementado. A abordagem que funciona na prática é sequencial:

• Primeiro, congele o ponto de entrada. Configure o Microsoft 365 Agent Store para exigir aprovação de qualquer agente de terceiro antes da instalação por usuário final. Isso interrompe o crescimento descontrolado sem afetar o que já está em uso interno.
• Depois, feche o inventário do existente. Levante todos os agentes ativos, classifique por sensibilidade de dados acessados e identifique os que estão fora de Environment Groups.
• Em seguida, desenhe as zonas. Comece com duas, experimentação e produção, e só adicione a zona de validação intermediária quando o volume de agentes justificar o overhead de um estágio a mais de revisão.
• Por fim, ative a visibilidade central. Vincule os agentes já zoneados à camada de identidade e auditoria do Agent 365 antes de expandir a criação de novos agentes para mais áreas do negócio.

Essa ordem importa porque cada etapa reduz o risco de a próxima aumentar a superfície de exposição em vez de reduzi-la. Ativar zoneamento antes de ter inventário, por exemplo, tende a produzir zonas mal desenhadas, porque a equipe está adivinhando o perfil de risco em vez de decidir com base em dados reais de uso.

O que o modelo não resolve sozinho

Vale ser direto sobre os limites. Environment Groups, Agent 365 e Agent Store dão estrutura de controle, mas não substituem decisão humana sobre o que um agente deveria ou não ter permissão de fazer. Um agente com escopo de acesso mal definido, ainda que dentro da zona de produção corretamente configurada, continua sendo um risco se ninguém revisar periodicamente se aquele escopo ainda faz sentido para a função do agente.

Da mesma forma, a camada de observabilidade do Agent 365 entrega dado, não julgamento. Alguém na organização precisa revisar os logs, definir o que é comportamento anômalo para o contexto específico do negócio e agir quando um alerta aparecer. Sem esse processo humano por trás, a visibilidade vira um painel bonito que ninguém olha.

O valor real do modelo descrito na v3.2 está em transformar governança de agentes de um esforço artesanal, agente por agente, em um processo estruturado por zona, com identidade rastreável e ponto único de controle de distribuição. Isso reduz drasticamente o esforço de auditoria e resposta a incidente, mas não elimina a necessidade de alguém dono do processo de governança dentro da organização.

Onde a Trinapse entra nessa conversa

Boa parte das organizações que conversam com a Trinapse sobre Copilot Studio já tem agentes rodando havia meses antes de perguntar sobre governança, e o desafio nunca é técnico no sentido estrito, é de priorização e de inventário do que já existe. Se esse é o momento da sua operação, vale começar pelo levantamento do que está em produção antes de desenhar qualquer zona nova.