Antes de um agente de IA receber um role, você sabe quem esse role já alcança? A Snowflake agora sabe

Quando um time pede um role de data warehouse para seu novo agente de analytics, o pedido geralmente soa assim: “o mesmo acesso dos analistas”. O que isso significa em tabelas? Quais dessas tabelas guardam salários, dados de saúde ou identificadores de clientes? E de todas as pessoas que têm esse role hoje, quantas já tocaram de fato nessas tabelas?

Na maioria das empresas, ninguém consegue responder à última pergunta sem um projeto. O lançamento da Snowflake em 20 de outubro transforma isso em um relatório.

Dois relatórios, dois fatos diferentes

A Snowflake colocou dois relatórios do Trust Center em disponibilidade geral (GA), para Enterprise Edition e acima:

• Sensitive Data Entitlement mostra os caminhos de acesso a tabelas com dados sensíveis: os usuários, roles e privilégios que concedem acesso a elas.
• Sensitive Data Access mostra quem realmente consultou essas tabelas, dentro de uma janela retroativa que você configura.

Os dois funcionam em tabelas identificadas como contendo dados sensíveis, então são tão completos quanto a classificação da organização. Tabelas que nunca foram classificadas não aparecem, por mais sensíveis que sejam.

Três perguntas sobre acesso, e qual delas cada ferramenta responde

Pode acessar

• Usuários, roles, privilégios
• Grants herdados

Relatório de entitlement

Acessou

• Quem consultou
• Dentro de uma janela retroativa

Relatório de acesso

Esta solicitação deve ser permitida agora

• Por consulta, por tarefa
• Propósito e contexto

Autorização em runtime, não um relatório

Por que isso importa mais quando os agentes chegam

Agentes herdam roles em escala. Uma pessoa com um role amplo demais raramente explora tabelas que não tem motivo para abrir. Um agente que responde perguntas abertas vai consultar o que seu role permitir quando uma pergunta levar até lá. Privilégio excessivo que estava dormente para pessoas se torna ativo para agentes. O relatório de entitlement mostra essa exposição antes de o agente existir.

“Quem acessou” é a base para o menor privilégio. A diferença entre quem pode chegar a uma tabela sensível e quem a usou nos últimos 90 dias é o achado de menor privilégio mais prático que um time de governança consegue produzir. Para um agente, ela dá o escopo inicial: conceder o que os usuários humanos daquele workflow realmente usaram, não tudo o que o role deles permite tecnicamente. Sob a LGPD, dados de saúde, biométricos e semelhantes são dados pessoais sensíveis (art. 5, II), e o princípio da necessidade (art. 6, III) limita o tratamento ao mínimo necessário, que é a forma legal do menor privilégio.

O relatório de acesso vira um monitor de agente. Depois do go-live, o mesmo relatório mostra se a identidade do agente está lendo tabelas sensíveis que não eram esperadas. Isso só funciona se cada agente tiver sua própria identidade no data warehouse. Um agente que roda sob um usuário de serviço compartilhado, ou sob a identidade do próprio usuário sem um marcador que a distinga, desaparece no tráfego humano.

O que os relatórios não fazem

Eles são evidência, não aplicação. Um relatório que mostra o acesso de ontem não impede a consulta de hoje; decidir se uma solicitação específica deve ser permitida, para um propósito específico, é trabalho das políticas de linha e coluna e da camada de autorização da plataforma de agentes.

Eles também enxergam uma plataforma só. Se um agente combina dados da Snowflake com documentos do SharePoint ou registros de um CRM, sua exposição real é a união, e cada fonte aplica suas próprias regras. É por isso que padrões em que o sistema de origem decide por usuário, ou em que o agente leva a identidade do usuário para cada ferramenta, importam tanto quanto qualquer relatório isolado.

Um uso prático neste trimestre

Inclua os dois relatórios no pedido de qualquer novo role de agente:

1. Rode o relatório de entitlement sobre o role que o agente receberia. Liste as tabelas sensíveis que ele alcança.
2. Rode o relatório de acesso para as pessoas que fazem esse trabalho hoje. Liste as tabelas sensíveis que elas realmente usaram.
3. Conceda ao agente a segunda lista, na identidade dele, e registre a decisão.
4. Revise mensalmente o relatório de acesso do próprio agente, e trate qualquer nova tabela sensível como uma mudança que precisa de aprovação.

Nada disso precisa de tecnologia nova além do que a Snowflake acabou de lançar. Precisa de alguém para decidir que revisões de acesso de agentes começam por evidência, não por “o mesmo acesso dos analistas”.