Segurança no Copilot Studio: permissões, DLP, conectores e dados corporativos

A segurança no Copilot Studio não começa no agente. Começa nos dados que ele pode acessar, nas conexões que ele pode usar e nas permissões que a empresa já configurou — ou deixou de configurar — no Microsoft 365, no SharePoint, no Power Platform, no Entra ID e nos sistemas corporativos.

Essa é uma mudança importante de mentalidade.

Leia também https://infob.com.br/agente-de-ia-para-empresas/

Muitas empresas olham para o Copilot Studio como uma ferramenta para criar chatbots ou agentes de IA. Mas, na prática, um agente corporativo pode se tornar uma nova interface de acesso aos dados da organização. Ele pode consultar documentos, acionar fluxos, chamar APIs, usar conectores, responder dentro do Teams, abrir chamados, consultar sistemas e orientar decisões.

Isso é poderoso. Mas também muda o risco.

Antes, um colaborador precisava saber onde procurar uma informação: qual pasta acessar, qual sistema abrir, qual relatório consultar, qual termo buscar. Com um agente de IA, ele pode simplesmente perguntar. Se a governança estiver fraca, o agente pode facilitar o acesso a informações que já estavam expostas, mas que antes eram difíceis de encontrar.

Por isso, discutir segurança Copilot Studio não é discutir apenas IA generativa. É discutir governança de dados, identidade, DLP, conectores, permissões, ambientes, auditoria e compliance.

A pergunta central para o decisor de TI não deve ser: “O Copilot Studio é seguro?”. A pergunta correta é: “A nossa arquitetura está preparada para colocar agentes de IA em contato com dados e processos corporativos?”.

Para uma visão mais ampla sobre o uso de agentes em processos empresariais, veja também o guia pilar da InfoB sobre agente de IA para empresas.

Riscos no Copilot Studio: onde a segurança costuma falhar

O risco mais óbvio é imaginar um agente “vazando dados”. Mas, em projetos reais, o problema raramente aparece de forma tão simples. O que costuma acontecer é mais sutil.

Um agente é criado para responder dúvidas internas. Ele usa como base um site do SharePoint. Esse site tem documentos úteis, mas também arquivos antigos, políticas desatualizadas, planilhas com dados pessoais, documentos herdados de projetos anteriores e permissões amplas demais. O agente não inventou o problema. Ele apenas tornou o problema pesquisável em linguagem natural.

Esse é um ponto crítico: o Copilot Studio pode transformar uma bagunça documental em uma interface aparentemente inteligente.

O segundo risco está nos conectores. Quando um agente usa conectores do Power Platform, ele deixa de ser apenas um canal de conversa. Ele passa a interagir com sistemas. Pode consultar dados, enviar informações, iniciar fluxos e executar ações. A própria Microsoft explica que os conectores funcionam como wrappers ou proxies de APIs, permitindo que Copilot Studio, Power Automate, Power Apps e Logic Apps se comuniquem com aplicativos e serviços externos. Veja a documentação oficial sobre conectores no Copilot Studio.

O problema não é usar conectores. O problema é permitir conectores sem critério.

Um conector de SharePoint pode ser necessário. Um conector de Dynamics 365 pode ser estratégico. Um conector de ServiceNow, Jira ou Freshservice pode automatizar suporte. Mas um conector HTTP genérico, um conector personalizado sem revisão ou uma integração com serviço externo não homologado pode abrir uma rota de exposição de dados.

O terceiro risco está na identidade usada pelo agente. Em muitos cenários, uma ação pode rodar com a credencial do usuário. Em outros, pode usar uma conexão configurada pelo criador. Essa diferença é enorme.

Se o agente opera com a permissão do usuário, ele tende a respeitar o que aquele usuário já poderia acessar. Se opera com uma credencial mais privilegiada, ele pode se tornar uma forma indireta de acessar dados ou executar ações acima do perfil do usuário final.

Para a TI, essa é uma das perguntas mais importantes em qualquer revisão de segurança:

“Essa resposta ou ação está sendo feita com a permissão de quem?”

O quarto risco está nos canais de publicação. Um agente interno publicado no Microsoft Teams tem um perfil de exposição. Um agente publicado em um site público tem outro. Um agente acessível por canal externo, sem autenticação adequada, exige ainda mais cuidado.

A Microsoft permite controlar, por política de dados, a publicação em determinados canais, como Teams, Microsoft 365, Direct Line, Facebook, Omnichannel, SharePoint e WhatsApp. Esse controle é documentado na página de prevenção contra perda de dados no Copilot Studio.

O quinto risco é mais organizacional do que técnico: criar agentes sem dono.

Um agente sem responsável de negócio vira um ativo sem curadoria. Um agente sem responsável técnico vira uma integração sem governança. Um agente sem revisão periódica vira um risco acumulado. E um agente sem auditoria vira uma caixa-preta.

Em outras palavras: o Copilot Studio não deve ser tratado como uma ferramenta isolada de produtividade. Ele precisa entrar no mesmo modelo de governança usado para aplicações corporativas, integrações, automações e dados sensíveis.

Controles essenciais para proteger agentes no Copilot Studio

Uma estratégia madura de segurança no Copilot Studio precisa combinar controle centralizado e autonomia responsável. Se a TI bloquear tudo, as áreas de negócio vão procurar atalhos. Se liberar tudo, a organização cria shadow AI dentro do próprio ambiente Microsoft.

O caminho mais seguro é criar trilhos.

O primeiro trilho é a separação por ambientes. No Power Platform, ambientes funcionam como contêineres lógicos para recursos, conexões, políticas e aplicações. Para Copilot Studio, essa separação é indispensável.

Um agente experimental criado por uma área de marketing não deveria ficar no mesmo ambiente de um agente financeiro em produção. Um agente de RH que consulta políticas internas não deveria compartilhar o mesmo nível de liberdade de conectores de um agente técnico em laboratório. Um agente com acesso a dados pessoais deve ter governança diferente de um agente que responde perguntas sobre produtos públicos.

A recomendação prática é trabalhar, no mínimo, com ambientes separados para experimentação, desenvolvimento, homologação e produção. Para áreas sensíveis, como financeiro, jurídico, RH e segurança da informação, pode fazer sentido criar ambientes mais restritos, com políticas próprias.

O segundo trilho é a autenticação. Para agentes internos, autenticação com Microsoft Entra ID deve ser regra, não exceção. A documentação da Microsoft informa que novos agentes têm autenticação Microsoft ativada por padrão, mas também existem cenários em que um criador pode optar por não exigir autenticação. Essa opção precisa ser controlada por política quando a empresa não quiser permitir agentes anônimos.

Na prática, agentes internos sem autenticação deveriam ser bloqueados. Um agente sem autenticação só faz sentido quando trabalha com informação pública, sem conectores sensíveis e sem qualquer ação transacional.

O terceiro trilho é o controle de permissões. O agente não deve ampliar o acesso do usuário. Ele deve respeitar o princípio de menor privilégio. Isso vale para fontes de conhecimento, conectores, APIs, fluxos do Power Automate e sistemas externos.

A frase que deve orientar a arquitetura é simples:

“O usuário só pode receber pelo agente aquilo que já poderia acessar por meios normais.”

Parece básico, mas é exatamente aqui que muitos projetos falham. O agente é conectado a uma biblioteca ampla demais, usa uma conexão privilegiada, consulta um sistema com credencial compartilhada ou responde com base em documentos que não passaram por classificação.

O quarto trilho é a DLP. As políticas de Data Loss Prevention permitem definir quais conectores podem ser usados, como podem ser combinados, quais recursos devem ser bloqueados e quais canais ou fontes podem ser restringidos. No contexto do Copilot Studio, DLP não é apenas um recurso de compliance; é uma barreira arquitetural contra combinações perigosas.

O quinto trilho é a auditoria. Agentes precisam deixar rastros. A Microsoft permite visualizar logs de auditoria do Copilot Studio no Microsoft Purview, e eventos relacionados à autenticação também podem aparecer no Microsoft Entra ID em cenários aplicáveis. Isso é importante para investigar criação, publicação, alterações, uso de conectores, mudanças de configuração e eventos de acesso.

O sexto trilho é a revisão humana. Nem todo processo deve ser automatizado até o fim. Em áreas como financeiro, jurídico, RH e segurança, o agente pode coletar informações, validar campos, consultar políticas e sugerir encaminhamentos. Mas decisões sensíveis devem preservar aprovação humana.

Um agente pode ajudar a montar uma solicitação de reembolso. Não deveria aprovar automaticamente exceções fora da política.
Um agente pode resumir cláusulas contratuais. Não deveria substituir a decisão jurídica final.
Um agente pode abrir chamado de TI. Não deveria liberar privilégio administrativo sem validação.
Um agente pode consultar status de pedido. Não deveria alterar crédito, cadastro bancário ou dados fiscais sem controle adicional.

Essa diferença entre “assistir” e “decidir” precisa estar clara no desenho do agente.

DLP no Copilot Studio: o que realmente precisa ser configurado

DLP é um dos temas mais importantes para segurança Copilot Studio porque define os limites técnicos do que criadores de agentes podem combinar.

No Power Platform Admin Center, administradores podem classificar conectores em grupos como Negócio, Não comercial e Bloqueado. A ideia é evitar que dados corporativos circulem entre conectores incompatíveis. Conectores do mesmo grupo podem compartilhar dados entre si. Conectores em grupos diferentes não devem ser combinados no mesmo fluxo de dados, conforme as regras da política.

Esse controle evita cenários como este:

Um agente consulta documentos internos no SharePoint, usa um conector corporativo aprovado e, em seguida, tenta enviar parte da informação para uma API externa não homologada. Se a política DLP estiver bem configurada, essa combinação pode ser impedida.

A documentação oficial da Microsoft sobre DLP no Copilot Studio mostra que as políticas podem controlar não apenas conectores, mas também recursos específicos, como autenticação, fontes de conhecimento, uso de conectores como ferramentas, requisições HTTP, habilidades, canais de publicação e gatilhos de eventos.

Esse ponto é importante porque muitos times ainda pensam em DLP apenas como “bloquear vazamento de arquivo”. No Copilot Studio, DLP precisa ser vista como política de arquitetura. Ela define o que um agente pode ser, com quem pode se conectar e onde pode aparecer.

Uma configuração madura de DLP deve responder a perguntas como:

Quais conectores são considerados corporativos?
Quais conectores são proibidos?
Quais conectores exigem exceção formal?
HTTP genérico será permitido?
Conectores personalizados podem ser criados por qualquer pessoa?
Quais canais de publicação são aceitos?
Agentes sem autenticação serão bloqueados?
Quais fontes de conhecimento podem ser usadas?
SharePoint será permitido de forma ampla ou apenas por endpoints aprovados?
Gatilhos de eventos externos serão liberados?

A minha recomendação é adotar uma postura conservadora no início. Não porque a tecnologia seja insegura, mas porque a maioria das empresas ainda não tem inventário completo de dados, permissões e conectores.

O padrão mais seguro é classificar novos conectores como Não comercial até que sejam revisados. Conectores só devem ir para o grupo Negócio depois de passarem por uma avaliação mínima: finalidade, tipo de dado, área responsável, autenticação, logs disponíveis, risco de envio externo e impacto caso a credencial seja comprometida.

DLP também deve variar por ambiente. Um ambiente de laboratório pode permitir mais testes, desde que sem dados sensíveis. Um ambiente de produção deve ser muito mais restritivo. Ambientes de áreas críticas devem ter políticas específicas.

Um erro comum é criar uma política global genérica e achar que isso resolve todos os casos. Não resolve. Um agente de FAQ institucional e um agente financeiro que consulta centro de custo não deveriam estar submetidos ao mesmo nível de liberdade.

Conectores no Copilot Studio: permitir, bloquear ou restringir?

Conectores são o ponto onde a conversa vira operação.

Sem conectores, um agente pode responder com base em conhecimento, documentos ou instruções. Com conectores, ele pode consultar sistemas, acionar fluxos e executar tarefas. Essa diferença muda o grau de risco.

A Microsoft documenta que conectores podem ser usados no Copilot Studio como ferramentas de agente, em tópicos, em fluxos e em cenários de conhecimento. Na prática, isso permite integrar o agente com serviços Microsoft, sistemas SaaS, APIs internas, ERPs, CRMs, ITSMs e outras plataformas.

Para o decisor de TI, a classificação de conectores deveria seguir uma lógica de risco, não apenas uma lista de “permitido” e “bloqueado”.

Conectores corporativos aprovados, como SharePoint, Teams, Outlook, Dataverse e Dynamics 365, podem fazer parte do grupo de Negócio. Mas ainda assim precisam ser usados no ambiente certo e com o escopo correto. Um conector aprovado não significa um conector liberado para qualquer agente.

Conectores departamentais precisam de contexto. Um conector de CRM pode ser adequado para vendas, mas não para RH. Um conector de ERP pode ser necessário para financeiro, mas perigoso em um agente genérico de atendimento interno. Um conector de ITSM pode ser excelente para suporte, mas não deve permitir automações administrativas sem controle.

Conectores externos estratégicos, como ServiceNow, Jira, Freshservice, Salesforce ou plataformas de assinatura digital, precisam passar por avaliação de segurança e privacidade. A pergunta não é apenas “funciona?”. A pergunta é: “que dado sai, para onde vai, com qual credencial, em qual contrato e com qual registro?”.

Conectores HTTP e conectores personalizados exigem atenção especial. Eles são úteis para integrações sob medida, mas também podem contornar parte da governança se forem usados sem revisão. Um conector personalizado mal documentado é, na prática, uma API corporativa invisível para a governança.

Por isso, qualquer conector personalizado usado em agente de produção deveria ter, no mínimo:

Responsável técnico.
Responsável de negócio.
Sistema de destino.
Métodos permitidos.
Tipo de dado acessado.
Tipo de autenticação.
Escopo da credencial.
Ambiente autorizado.
Logs disponíveis.
Critério de aprovação.
Data de revisão.

Também é importante lembrar que alguns conectores não podem simplesmente ser bloqueados em determinadas condições da Power Platform. Nesses casos, a governança precisa usar outros mecanismos: classificação em grupos de dados, separação de ambientes, endpoint filtering, controle de quem pode criar conexões, revisão de permissões e auditoria.

Para fontes de conhecimento, o mesmo raciocínio se aplica. Permitir SharePoint como fonte não significa permitir qualquer site do SharePoint. O ideal é conectar o agente a bases curadas, com documentos atualizados, permissões revisadas e dono claro.

Um bom padrão para agentes internos é usar bibliotecas oficiais de conhecimento, e não repositórios amplos. Por exemplo:

Uma biblioteca oficial de políticas de RH.
Uma base de procedimentos de suporte técnico.
Um repositório de normas comerciais aprovadas.
Uma área de documentos financeiros com escopo limitado.
Um conjunto de artigos internos revisados pela área responsável.

O que deve ser evitado:

Sites inteiros sem curadoria.
Pastas compartilhadas antigas.
Documentos pessoais no OneDrive.
Bibliotecas com permissões herdadas sem revisão.
Arquivos com dados pessoais sem necessidade clara.
Fontes públicas sem validação.
Bases em que ninguém é responsável pela atualização.

Um agente seguro depende menos de “ter acesso a tudo” e mais de saber exatamente a que deve ter acesso.

Dados corporativos e exposição: o problema quase nunca nasce na IA

Um dos pontos mais importantes para explicar a executivos e gestores de TI é que o Copilot Studio raramente cria, sozinho, uma falha de governança. O que ele faz é tornar falhas existentes mais visíveis e mais fáceis de explorar.

Se o SharePoint está desorganizado, o agente herda essa desorganização.
Se os grupos do Entra ID estão amplos demais, o agente pode herdar esse excesso de acesso.
Se documentos confidenciais estão em bibliotecas erradas, o agente pode usá-los como fonte.
Se APIs internas não têm escopo adequado, o agente pode acioná-las de forma indevida.
Se conectores externos não são governados, o agente pode enviar dados para destinos inadequados.

A IA não elimina a necessidade de governança documental. Ela aumenta a urgência dela.

Dados corporativos não são apenas contratos sigilosos ou planilhas financeiras. Também incluem políticas internas, propostas comerciais, relatórios, históricos de atendimento, tickets, documentos de RH, mensagens, listas, metadados, dados de clientes, informações de fornecedores e registros operacionais.

A exposição pode acontecer de várias formas.

A exposição direta ocorre quando o agente entrega uma informação que o usuário não deveria ver.

A exposição indireta ocorre quando o agente resume ou cruza informações sensíveis, mesmo sem mostrar o documento original.

A exposição por ação ocorre quando o agente envia dados para um conector externo, fluxo ou API.

A exposição por canal ocorre quando um agente interno é publicado em local inadequado.

A exposição por credencial ocorre quando o agente executa algo com uma permissão superior à do usuário.

A exposição por escopo ocorre quando a fonte de conhecimento é ampla demais.

Para evitar isso, cada fonte conectada ao agente deve passar por uma revisão objetiva:

Que tipo de dado existe nessa fonte?
O conteúdo é público, interno, confidencial ou restrito?
Há dados pessoais protegidos pela LGPD?
Há informações de clientes, contratos ou finanças?
A fonte está atualizada?
A permissão está correta?
Existe dono da informação?
O agente precisa mesmo acessar tudo isso?
O usuário final teria acesso a esses dados fora do agente?
A resposta do agente precisa citar fonte?
Há necessidade de revisão humana?

Essa revisão parece trabalhosa, mas é mais barata do que investigar depois por que um agente respondeu algo que não deveria.

Para empresas que ainda estão amadurecendo segurança no Microsoft 365, o projeto de Copilot Studio deve andar junto com revisão de SharePoint, Entra ID, Purview, Defender e políticas de colaboração. A InfoB também aborda esse tema em conteúdos sobre segurança Microsoft 365, governança de agentes de IA e implementação de Copilot Studio.

Permissões Copilot Studio: o ponto que separa produtividade de risco

Permissão é o centro da discussão.

Um agente pode ter uma interface simples, uma conversa amigável e uma experiência muito melhor do que um sistema tradicional. Mas, por trás da conversa, continua existindo uma pergunta clássica de segurança:

“Quem pode acessar o quê?”

No Copilot Studio, essa pergunta precisa ser desdobrada:

Quem pode criar agentes?
Quem pode editar agentes?
Quem pode publicar agentes?
Quem pode usar o agente?
Quais dados o agente pode consultar?
Quais conectores ele pode usar?
Com qual identidade ele executa ações?
Quem aprova mudanças?
Quem audita o uso?

O erro mais comum é controlar apenas quem usa o agente e esquecer quem cria, quem conecta fontes, quem publica e quem configura ações.

Criadores de agentes precisam de liberdade para inovar, mas não deveriam ter permissão irrestrita para conectar qualquer fonte ou qualquer API. Publicação em produção deve exigir revisão. Agentes que usam conectores sensíveis devem ter aprovação técnica. Agentes que tratam dados pessoais devem ter avaliação de privacidade. Agentes que executam ações críticas devem ter controles adicionais.

Para agentes internos, o uso de grupos do Microsoft Entra ID é essencial. Em vez de liberar um agente para “todos da empresa”, a TI deve publicar por grupos, funções ou áreas. Um agente financeiro pode estar disponível apenas para colaboradores autorizados. Um agente jurídico pode ser restrito ao time jurídico e gestores específicos. Um agente de TI pode ter funções diferentes para usuários comuns e equipe técnica.

Também é importante separar permissão de conversa e permissão de ação. Um usuário pode ter autorização para perguntar sobre uma política, mas não para executar uma solicitação. Pode consultar status, mas não alterar cadastro. Pode abrir chamado, mas não aprovar exceção. Pode solicitar acesso, mas não conceder acesso.

Essa separação torna o agente mais seguro e mais útil. Em vez de bloquear tudo, a empresa desenha níveis de capacidade.

Um modelo simples funciona bem:

Usuário comum: consulta informação e abre solicitação.
Gestor: aprova ou reprova dentro de uma alçada.
Área responsável: revisa exceções e dados sensíveis.
TI: administra conectores, ambientes e políticas.
Segurança/compliance: audita, define limites e aprova exceções.

Quando esse modelo não existe, o agente tende a virar um improviso. E improviso com IA conectada a dados corporativos é um risco desnecessário.

Como desenhar uma governança Copilot Studio sem travar a inovação

Governança não deve ser sinônimo de burocracia. Uma boa governança permite que a empresa crie agentes mais rápido, porque define previamente o que é permitido, o que exige aprovação e o que é proibido.

O primeiro passo é criar uma classificação de agentes.

Agentes informativos públicos, com dados públicos e sem ações sensíveis, têm baixo risco.

Agentes internos informativos, autenticados e conectados a bases aprovadas, têm risco moderado.

Agentes transacionais, que abrem solicitações ou consultam sistemas, têm risco alto.

Agentes que tratam dados pessoais, financeiros, jurídicos ou estratégicos têm risco elevado.

Agentes que executam ações em sistemas de produção têm risco crítico.

Essa classificação ajuda a evitar discussões subjetivas. Um agente de FAQ público não precisa do mesmo processo de aprovação de um agente que consulta dados de reembolso. Um agente que responde dúvidas sobre benefícios não deve ser tratado como um agente que altera cadastro bancário de fornecedor.

O segundo passo é definir padrões de arquitetura.

Para agentes internos, autenticação Microsoft Entra ID.
Para agentes de produção, ambiente separado.
Para conectores externos, aprovação prévia.
Para HTTP e conectores personalizados, revisão técnica.
Para dados sensíveis, validação de compliance.
Para ações críticas, aprovação humana.
Para publicação, controle por canal.
Para operação, auditoria no Purview e Entra ID.

O terceiro passo é criar um processo simples de aprovação.

Não precisa começar com um comitê complexo. Um fluxo inicial pode ter quatro etapas:

A área de negócio descreve o caso de uso.
A TI avalia dados, conectores e ambiente.
Segurança ou compliance revisa riscos relevantes.
O agente é homologado antes de ir para produção.

O quarto passo é criar um inventário de agentes. Esse inventário deve mostrar nome do agente, área responsável, ambiente, fontes usadas, conectores, canais de publicação, tipo de autenticação, criticidade, responsável técnico, responsável de negócio e data de revisão.

Esse inventário é especialmente importante porque agentes tendem a se multiplicar. Hoje a empresa cria um agente de RH. Amanhã cria um de financeiro, outro de TI, outro de vendas, outro de jurídico, outro de atendimento. Sem inventário, a TI perde visibilidade rapidamente.

O quinto passo é educar os criadores. A maioria dos problemas não nasce de má-fé. Nasce de pressa, desconhecimento e ausência de padrões. Criadores precisam saber quais fontes podem usar, quais conectores são aprovados, como pedir exceção, o que não pode ser publicado e quando envolver TI ou compliance.

A melhor governança é aquela que aparece antes do erro.

Checklist de segurança Copilot Studio

Antes de publicar um agente corporativo no Copilot Studio, use este checklist como revisão mínima.

Governança

O agente tem responsável de negócio definido?
O agente tem responsável técnico definido?
O caso de uso foi classificado por risco?
Existe ambiente correto para desenvolvimento, teste e produção?
A publicação em produção exige aprovação?
Existe data de revisão periódica?
O agente está registrado em um inventário central?

Dados e fontes de conhecimento

As fontes foram aprovadas pela área dona da informação?
O escopo está limitado ao necessário?
A base contém dados pessoais, financeiros, jurídicos ou estratégicos?
As permissões no SharePoint, OneDrive ou outro repositório foram revisadas?
Há documentos antigos, duplicados ou desatualizados?
O agente deve citar fontes nas respostas?
Existe responsável pela atualização do conteúdo?

Autenticação e permissões

O agente exige autenticação com Microsoft Entra ID?
Agentes sem autenticação foram bloqueados quando não necessários?
O acesso ao agente está restrito por grupos ou perfis?
O agente respeita as permissões do usuário final?
As ações usam credencial do usuário ou do criador?
Credenciais privilegiadas foram evitadas?
Há separação entre consultar, solicitar, aprovar e executar?

DLP

Existe política DLP aplicada ao ambiente?
Conectores foram classificados como Negócio, Não comercial ou Bloqueado?
O grupo padrão para novos conectores é restritivo?
Conectores externos exigem aprovação?
HTTP genérico está bloqueado ou limitado?
Conectores personalizados passam por revisão?
Canais de publicação inadequados foram bloqueados?
Fontes de conhecimento não aprovadas foram restringidas?
Gatilhos de eventos foram avaliados?

Conectores e ações

Todos os conectores têm finalidade documentada?
Conectores com escrita foram avaliados separadamente?
Conectores externos têm base contratual e revisão de segurança?
APIs internas têm escopo e autenticação adequados?
Ações críticas exigem aprovação humana?
Existe log das ações executadas?
Há plano para revogar conexão em caso de incidente?

Publicação e canais

O canal escolhido é adequado ao tipo de dado?
Agentes internos estão em canais autenticados?
Canais públicos foram evitados para dados corporativos?
WhatsApp, Direct Line ou site público foram avaliados com rigor?
A publicação foi aprovada por TI e área responsável?
Existe plano de desativação ou rollback?

Auditoria e compliance

Logs do Copilot Studio estão disponíveis para auditoria?
Eventos relevantes aparecem no Microsoft Purview ou Entra ID?
Há processo para investigar uso indevido?
Dados pessoais foram avaliados sob ótica da LGPD?
O agente evita decisões finais em áreas sensíveis?
Exceções são documentadas?
A empresa sabe quem acionar em caso de incidente?

FAQ sobre segurança Copilot Studio

O Copilot Studio é seguro para empresas?

Sim, desde que seja implementado com governança. A plataforma oferece recursos de autenticação, DLP, conectores controlados, ambientes e auditoria. Mas a segurança final depende da arquitetura criada pela empresa: permissões, fontes de dados, conectores, canais, credenciais e processo de aprovação.

O que é DLP no Copilot Studio?

DLP, ou Data Loss Prevention, é o conjunto de políticas que controla como agentes podem usar conectores, dados, canais e recursos. No Copilot Studio, DLP ajuda a impedir combinações indevidas entre conectores corporativos e serviços externos, além de permitir bloqueios relacionados a autenticação, fontes de conhecimento, HTTP, canais e gatilhos.

A DLP impede todo vazamento de dados?

Não. DLP é uma camada essencial, mas não substitui governança de dados. Ela reduz o risco técnico de combinações perigosas, mas a empresa ainda precisa revisar permissões, classificar dados, controlar fontes, auditar agentes e definir responsáveis.

Quais conectores devem ser bloqueados no Copilot Studio?

Devem ser bloqueados ou tratados como exceção conectores externos não homologados, HTTP genérico, conectores personalizados sem revisão, serviços pessoais, APIs sem controle e canais públicos incompatíveis com dados internos. Conectores corporativos podem ser permitidos, mas sempre com escopo e ambiente corretos.

O Copilot Studio respeita as permissões do usuário?

Depende da configuração. Em cenários bem desenhados, o agente deve operar dentro das permissões do usuário. Mas, quando usa conexões configuradas pelo criador ou credenciais privilegiadas, o risco muda. Por isso, a identidade usada em cada ação precisa ser revisada.

Posso publicar um agente interno sem autenticação?

Para uso interno, não é recomendado. Agentes internos devem exigir autenticação com Microsoft Entra ID. Agentes sem autenticação só deveriam ser usados para informações públicas, sem dados sensíveis e sem ações transacionais.

O maior risco está na IA ou nos dados?

Na maioria dos casos, está nos dados e permissões. A IA pode tornar mais fácil encontrar, resumir ou combinar informações, mas o problema geralmente nasce em fontes mal governadas, permissões amplas, conectores sem controle e ausência de auditoria.

Como auditar agentes criados no Copilot Studio?

A Microsoft oferece integração com recursos de auditoria, incluindo Microsoft Purview e registros relacionados ao Microsoft Entra ID em cenários aplicáveis. A empresa deve manter inventário dos agentes, revisar alterações, acompanhar canais de publicação e monitorar uso de conectores.

Quem deve ser responsável pela segurança do Copilot Studio?

A responsabilidade deve ser compartilhada. TI administra ambientes, conectores e políticas. Segurança define controles e revisa riscos. A área de negócio responde pelo conteúdo e pelo processo. Compliance avalia dados sensíveis e requisitos regulatórios. O erro é deixar tudo apenas nas mãos do criador do agente.

Qual é o primeiro passo para melhorar a segurança Copilot Studio?

O primeiro passo é fazer um inventário dos agentes, ambientes, fontes de conhecimento, conectores, canais e responsáveis. Depois, a TI deve aplicar políticas DLP, revisar autenticação, separar ambientes, restringir conectores críticos e criar um processo formal de aprovação para produção.

Conclusão: segurança no Copilot Studio é governança de dados em tempo real

O Copilot Studio pode acelerar a criação de agentes corporativos e transformar processos internos. Mas ele também aumenta a responsabilidade da TI sobre dados, conectores, identidade e automação.

O ponto central é simples: um agente de IA não deve ser uma rota alternativa para acessar dados ou executar ações fora da governança corporativa.

Empresas maduras vão tratar o Copilot Studio como plataforma de aplicação corporativa. Vão separar ambientes, aplicar DLP, classificar conectores, exigir autenticação, controlar canais, auditar uso e revisar agentes periodicamente.

Empresas imaturas vão tratar o Copilot Studio como “mais uma ferramenta de produtividade”. E é aí que mora o risco.

A diferença entre inovação e exposição não está em usar ou não usar IA. Está em como a empresa conecta a IA aos seus dados e processos.

A InfoB apoia empresas na avaliação, desenho e implementação segura de agentes de IA com Microsoft Copilot Studio, incluindo governança, permissões, DLP, conectores, autenticação, auditoria e publicação controlada no Microsoft Teams e Microsoft 365.

Para avançar com segurança, acesse o guia completo sobre agente de IA para empresas ou fale com um especialista da InfoB.