Agente de Segurança Power Pages: Como Ativar

O que o agente de segurança power pages resolve na rotina de uma cooperativa

Portal do associado com abertura de conta digital, simulação de crédito consignado e emissão de boleto é canal público por natureza. Ele precisa ficar acessível a qualquer pessoa antes do login e, ao mesmo tempo, blindar tudo que é dado de conta, proposta ou extrato depois dele. Esse equilíbrio entre autenticação e autorização é revisado hoje, na maioria das cooperativas, por meio de chamado: alguém da TI ou do maker do portal precisa acionar o time de segurança ou o DPO sempre que uma mudança de configuração levanta dúvida.

O Microsoft Power Pages lançou, em preview público, um agente de IA embutido no workspace de segurança do próprio design studio. Ele responde em linguagem natural perguntas sobre a postura de autenticação e autorização do site, aponta configurações de risco e propõe correções, sempre pedindo aprovação explícita antes de aplicar qualquer alteração. Para quem administra portal de associado, isso significa revisar configuração de acesso sem abrir chamado para checar o que já está exposto.

Este guia mostra como habilitar esse agente, o tipo de pergunta que vale fazer sobre autenticação e autorização de portal, e onde ele para de ser suficiente, especialmente para quem responde por compliance regulado pelo Banco Central.

Pré-requisitos antes de habilitar o agente

Como recurso em preview, o Security agent tem uma lista de pré-condições mais rígida do que um recurso já em disponibilidade geral. Confirme os itens abaixo antes de procurar o botão.

Requisito	Onde verificar	Detalhe
Licença Power Pages ativa	Power Platform admin center > Environments > ambiente do site	O site precisa estar provisionado sobre um ambiente com Dataverse e licença Power Pages válida, seja per app ou incluída em plano premium do Power Apps
Papel de segurança correto	Dataverse > Configurações > Segurança > Usuários	É preciso System Administrator ou System Customizer no ambiente. Acesso apenas ao Portal Management app ou papel de editor de conteúdo não é suficiente
Preview features habilitado	Power Platform admin center > Environments > ambiente > Settings > Product > Features	Exige papel de Environment Admin ou Power Platform Administrator no tenant para alterar
IA generativa liberada no tenant	Power Platform admin center > Policies / Tenant settings	O agente depende de modelo de linguagem hospedado. Vale checar a política equivalente a "Allow external language models for generative responses" e confirmar se a região do tenant já recebeu a onda de rollout
Site já publicado	Power Pages design studio > botão Publicar	O agente lê o estado publicado do site, não o rascunho em edição

Vale testar primeiro em ambiente de homologação, não direto no ambiente de produção onde o portal do associado está no ar. Preview significa que o comportamento do agente pode mudar até a disponibilidade geral, inclusive nome de botão, texto de resposta e escopo de configuração que ele consegue alterar.

Passo a passo: habilitando o agente no workspace de segurança

Sequência de seis passos para habilitar e usar o Security agent do Power Pages, do preview até a aprovação da mudança

Etapa 1. Ativar recursos em preview no ambiente

No Power Platform admin center, acesse Environments, selecione o ambiente onde o site Power Pages está provisionado e abra Settings > Product > Features. Na seção referente a Power Pages, procure o toggle de recursos em preview relacionados a segurança. Como o rótulo exato pode mudar enquanto o recurso está em preview, ele aparece listado junto aos demais recursos experimentais dessa seção, não como item isolado.

O racional de deixar esse toggle no nível de ambiente, e não já habilitado por padrão, é evitar que um recurso de IA generativa comece a ler e sugerir mudança de configuração de segurança em produção sem que alguém do time de plataforma tenha decidido isso conscientemente.

Etapa 2. Confirmar que a IA generativa está liberada no tenant

Ainda no Power Platform admin center, verifique nas configurações de tenant se recursos de IA generativa estão permitidos para a região onde o ambiente está hospedado. Se essa política estiver bloqueada no nível do tenant, o painel do agente pode aparecer vazio ou indisponível mesmo com o toggle do ambiente ativado, porque a política de tenant tem precedência sobre a configuração de ambiente.

Etapa 3. Abrir o workspace de Segurança do site

Acesse o Power Pages design studio (make.powerpages.microsoft.com), abra o site do portal e, no painel lateral esquerdo, selecione o workspace Segurança. Esse workspace concentra autenticação, permissões de tabela, papéis da web e configurações de aplicativo, e é onde o agente está embutido, não em um menu separado.

Etapa 4. Acionar o Security agent e fazer a primeira pergunta

Dentro do workspace de Segurança, localize o ícone de chat do agente. A primeira interação vale ser ampla: peça uma revisão geral antes de perguntas pontuais, para o agente construir contexto sobre o site inteiro antes de focar em um provedor de autenticação específico ou em uma tabela.

Etapa 5. Revisar a recomendação e aprovar (ou rejeitar) a mudança

Quando o agente identifica um risco, ele não altera a configuração direto. Ele apresenta o achado, explica por que considera risco e propõe uma correção, deixando explícito que só aplica com aprovação. Esse é o ponto do fluxo que mais importa documentar, porque é aqui que a decisão humana entra formalmente no processo.

Que tipo de pergunta o agente responde sobre autenticação e autorização

O escopo declarado do agente cobre quatro frentes: postura geral de segurança do site, configuração de autenticação, configuração de autorização e configurações de aplicativo relacionadas a segurança. Na prática, para um portal de cooperativa, essas perguntas tendem a ser úteis:

Quais provedores de autenticação estão habilitados neste site, e existe login local (usuário e senha) coexistindo com Microsoft Entra External ID sem justificativa clara?
Alguma tabela do Dataverse está exposta ao papel Anônimos que deveria estar restrita ao papel Associado?
Quais páginas não têm permissão de tabela associada, e por isso herdam acesso público por omissão?
Quais papéis da web (web roles) têm a opção de acesso global marcada, e isso é necessário para o funcionamento do site?
Existe inconsistência entre a permissão de leitura de uma tabela e a permissão de leitura das colunas dessa mesma tabela?

Uma interação típica se parece com isto, de forma ilustrativa:

Pergunta: "Revise a configuração de autorização deste site e aponte tabelas com acesso mais amplo do que o esperado."
Resposta do agente: "Encontrei três tabelas com permissão de leitura para o papel Anônimos: Proposta_Credito, Extrato e Dados_Cadastrais. Isso permite que um visitante sem login leia esses registros se souber o identificador. Recomendo restringir a leitura dessas tabelas ao papel Associado. Deseja aplicar essa mudança?"

A resposta cita a configuração real do site, não um checklist genérico de boas práticas. Se a resposta vier genérica, sem referenciar papel ou tabela específica do seu ambiente, é sinal de que algo no passo 3 ou 4 não foi concluído corretamente, e o assunto volta na seção de erros comuns mais abaixo.

Como validar que a configuração ficou correta

Aprovar uma recomendação do agente não é o fim da validação, é o começo dela. Depois de aplicar uma mudança:

Republique o site em Power Pages design studio > Publicar. O agente e o próprio runtime do portal leem o estado publicado, não o rascunho.
Confira manualmente no workspace de Permissões de tabela se o papel afetado mudou exatamente como esperado, sem efeito colateral em outras permissões que compartilham o mesmo papel.
Abra uma sessão anônima do navegador e tente acessar o recurso que era exposto antes da mudança. O comportamento esperado é acesso negado ou redirecionamento para login.
Faça a mesma pergunta ao agente novamente. A resposta deve refletir o novo estado, citando a mudança recém aplicada.

Para deixar rastro do que foi perguntado, respondido e decidido, um modelo simples de registro ajuda a documentar a revisão para auditoria interna, já que o preview ainda não integra esse histórico a um log de auditoria formal do Dataverse:

json

{
  "site": "portal-associado-cooperativa-x",
  "data_revisao": "2026-08-15",
  "revisor_humano": "nome.sobrenome@cooperativa.com.br",
  "pergunta_ao_agente": "Quais tabelas estao expostas ao papel Anonimos?",
  "resposta_resumida_do_agente": "3 tabelas expostas: Proposta_Credito, Extrato, Dados_Cadastrais",
  "acao_recomendada": "Restringir leitura ao papel Associado",
  "decisao_do_revisor": "aprovado_com_ressalva",
  "justificativa": "Tabela Extrato mantida publica apenas para pagina de simulacao sem dados reais",
  "politica_dlp_relacionada": "revisada manualmente em 2026-08-15, sem alteracao"
}

Erros comuns e o que eles significam

Painel do agente não aparece no workspace de Segurança. Causa mais frequente: o toggle de preview não foi ativado no ambiente correto, ou o rollout regional do preview ainda não chegou ao datacenter do tenant.
Mensagem indicando que você não tem permissão para revisar essa configuração. Causa: o usuário logado tem apenas acesso ao Portal Management app ou papel de editor de conteúdo, e não System Administrator ou System Customizer no ambiente Dataverse.
Botão de aplicar mudança aparece desabilitado. Duas causas possíveis: uma política de DLP do tenant bloqueia o conector que o agente usaria para gravar a alteração, ou o pool de créditos de IA generativa do tenant está esgotado no momento.
Respostas genéricas, sem citar tabela ou papel específico do site. Causa: o site tem alterações não publicadas desde a última edição, e o agente está lendo uma versão publicada anterior que não reflete a configuração atual.

Como o recurso está em preview, o texto exato dessas mensagens pode mudar antes da disponibilidade geral. O que não muda é a causa raiz: preview desligado no ambiente, papel insuficiente, política de DLP no caminho, ou site não republicado.

Por que isso não substitui a revisão de política de DLP

O agente examina a configuração de autenticação e autorização do site: provedores, papéis, permissões de tabela e coluna. Ele não examina a política de prevenção de perda de dados do tenant, que decide quais conectores e quais fluxos de dados são permitidos fora do Power Pages. São duas camadas diferentes de governança, e uma recomendação aprovada dentro do Security agent não documenta, nem substitui, a análise de DLP que a área de segurança da cooperativa já mantém.

Para uma instituição regulada pelo Banco Central, com política de segurança cibernética formal exigida pela Resolução CMN/BCB 4658 e obrigações de proteção de dados sob a LGPD, isso importa na prática: a resposta do agente é insumo para a decisão, não a decisão registrada. O revisor humano que aprova a mudança continua sendo o responsável pela justificativa documentada, e é essa documentação, não o histórico de chat do agente, que sustenta uma auditoria.

Vale também lembrar que o agente enxerga o que está declarado na configuração do site. Lógica customizada em template de página, JavaScript embutido ou regra de negócio implementada fora do modelo de permissões do Dataverse fica fora do escopo dele. Um portal com permissão de tabela correta, mas com um script client-side que expõe dado por engano, continua sendo risco que só revisão manual de código captura.

Times que já tratam a revisão de autenticação e autorização de portal como parte de um programa maior de governança de Power Platform tendem a usar o agente como um primeiro filtro rápido, reservando a revisão manual de DLP e a auditoria de código para o que o agente não alcança. É esse desenho de camadas, e não a troca de uma pela outra, que costuma amadurecer com o tempo dentro de uma cooperativa que expõe portal público como canal crítico.

Agente de Segurança Power Pages: Guia de Configuração