Resumo Técnico: Controle de Fluxo de Dados (DFC)

1. Definição do Problema

O artigo aborda uma lacuna crítica na segurança de agentes de IA e analistas de dados que interagem com sistemas de banco de dados. Enquanto pesquisas recentes focam em melhorar a correção do SQL gerado por agentes (ou seja, se a consulta reflete a intenção do usuário), elas frequentemente negligenciam a segurança. Uma consulta pode ser semanticamente correta e, ainda assim, violar restrições regulatórias, de privacidade ou de negócios relativas a como os dados são combinados, transformados e liberados.

Os mecanismos de segurança atuais são insuficientes por três razões primárias:

1. Controle de Acesso vs. Fluxo de Dados: Os controles de acesso tradicionais governam quem pode ler os dados, não como os dados fluem e se combinam durante a execução da consulta.
2. Restrições de Integridade: Estas governam o estado estático do banco de dados, não os estados intermediários de consulta ou derivações.
3. Sobrecarga de Proveniência: Embora sistemas de proveniência possam auditar derivações retrospectivamente, a materialização de polinômios de proveniência completos acarreta custos de desempenho proibitivos (variando de 20× a 10.000× de lentidão), tornando-os inadequados para aplicação em tempo real.
4. Abordagens Probabilísticas: Confiar em Grandes Modelos de Linguagem (LLMs) para verificar a segurança via prompts ou validação post-hoc é inerentemente probabilístico, carece de garantias formais e degrada-se conforme a complexidade da política e a escala dos dados aumentam.

Os autores argumentam que a segurança de dados é fundamentalmente um problema de infraestrutura, que requer um mecanismo determinístico para aplicar políticas declarativas sobre fluxos de dados ao nível de tupla dentro do próprio DBMS.

2. Metodologia

O artigo introduz o Data Flow Control (DFC), um framework para especificar declarativamente e garantir a aplicação de políticas sobre fluxos de dados. A metodologia consiste em três componentes principais:

2.1 Formalização da Segurança de Dados

Os autores formalizam a segurança de dados como predicados agregados sobre monômios de proveniência.

• Invariância do Otimizador: Um desafio fundamental é que planos de consulta físicos afetam a estrutura dos polinômios de proveniência. Para garantir que as políticas sejam invariantes ao otimizador, o DFC define políticas sobre uma representação normalizada: um saco de monômios de proveniência ($M(o)$) para cada tupla de saída $o$, em vez da própria estrutura do polinômio.
• Agregação por Semirring: O sistema utiliza propriedades de semirrings (ex: números naturais, conjuntos) para computar agregações sobre esses monômios de forma eficiente sem materializar o polinômio completo.

2.2 A Linguagem de Política PGN

Os autores propõem a PGN (Provenance Guard Notation), uma linguagem declarativa para expressar políticas de DFC. A PGN permite que os usuários definam:

• Fontes ($S$): Relações às quais a política se aplica.
• Restrições ($B$): Expressões booleanas sobre atributos de relações de origem e monômios de proveniência (ex: "custo máximo < 100" ou "contagem distinta de usuários > 1").
• Resolução ($F$): Ações tomadas em caso de violação, como REMOVE (remover a tupla), KILL (abortar a consulta) ou Funções Definidas pelo Usuário (UDFs) customizadas que podem transformar dados ou invocar LLMs para decisões semânticas.
• Extensões: A PGN suporta dimensões externas (referenciando catálogos do sistema ou outras tabelas), sinks (tabelas alvo para inserts/updates), fontes obrigatórias (grounding) e resoluções ao nível de relação.

2.3 O Mecanismo de Aplicação Passant

O Passant é uma camada de reescrita de consulta portátil que aplica políticas PGN sem materializar a proveniência completa. Ele emprega duas estratégias principais de reescrita:

1. Partial-Push (Empuxo Parcial): Empurra os cálculos de agregação de política através de joins, mas ainda exige o cálculo de polinômios de proveniência para acessar atributos de entrada.
2. Full-Push (Empuxo Total): A principal contribuição. Ele reescreve a consulta base para "pegar carona" nos cálculos de agregação de política diretamente na execução da consulta base usando anotações de semiring.
   • Anotação de Folha: As relações de entrada são anotadas com elementos de semiring (ex: 1 para contagem, valores de atributo para soma).
   • Regras de Operador: Joins multiplicam as anotações; agregações somam as anotações.
   • Resultado: As restrições de política são avaliadas inline durante a execução normal da consulta, evitando o "imposto de proveniência" de re-escanear tabelas ou realizar joins com dados de linhagem.

O sistema lida com construtos SQL-92, incluindo outer joins (via anotações de conjunto), uniões e self-joins (via otimizações de simetria).

3. Principais Contribuições

1. Formalização: Elevar a proveniência de uma ferramenta de auditoria para um mecanismo ativo de aplicação de políticas, definindo a segurança como restrições sobre a proveniência ao nível de registro que são invariantes à otimização de consulta.
2. Linguagem PGN: Projetar uma linguagem declarativa capaz de expressar restrições complexas (privacidade, grounding, limites de transformação) que referenciam o contexto do sistema, privilégios de usuário e metadados relacionais.
3. Mecanismo e Algoritmos Passant:
   • Uma linha de base de pós-processamento ingênua usando sistemas de proveniência existentes.
   • Algoritmos de reescrita Partial-Push e Full-Push que reduzem significativamente o estado intermediário.
   • Otimizações para políticas de template (colapsando múltiplos limiares em uma única restrição dominante) e self-joins simétricos (reduzindo a complexidade fatorial para linear).
4. Avaliação Empírica: Demonstrar que a aplicação de DFC pode ser alcançada com overhead quase nulo em diversos motores de banco de dados.

4. Resultados

Os autores avaliaram o Passant em cinco motores de DBMS: DuckDB, Umbra, PostgreSQL, DataFusion e SQLServer.

• Desempenho: Em consultas TPC-H, o Full-Push alcançou ≈0% de overhead na maioria dos casos e, surpreendentemente, superou a consulta base (Sem Política) no motor Umbra.
• Comparação com Baselines:
  • Proveniência Lógica/Física: Essas abordagens incorreram em lentidões massivas (2.000% a 75.000% para Lógica; 300% a 700% para Física) devido ao custo de materializar e realizar joins de dados de proveniência.
  • Verificações de LLM: Em uma comparação de 13 consultas TPC-H contra 1–32 políticas, o DFC foi ordens de magnitude mais rápido que as verificações baseadas em LLM, que também carecem de garantias formais.
• Escalabilidade:
  • Contagem de Políticas: O sistema escala de forma sublinear com o número de políticas usando otimização de template (colapso de restrições).
  • Self-Joins: Otimizações de política simétrica reduziram a complexidade de aplicação de fatorial ($O(n!)$) para linear ($O(n)$) para consultas com muitos self-joins.
• Aplicação: Em uma tarefa de aplicação de máquina de estados de processo de negócio, o Full-Push foi duas ordens de magnitude mais rápido que uma abordagem baseada em LLM, fornecendo simultaneamente correção determinística.

5. Significância e Alegações

O artigo afirma que o Data Flow Control representa o primeiro passo para mover a segurança de dados de "prompts e verificações post-hoc" para dentro da infraestrutura de dados.

• Segurança por Padrão: Ao alcançar um overhead quase zero, o DFC torna viável a aplicação de políticas de segurança em cada consulta, tornando a segurança a escolha natural em vez de um complemento opcional e caro.
• Garantias Determinísticas: Ao contrário dos guardas probabilísticos de LLM, o DFC fornece garantias formais e determinísticas de que os fluxos de dados cumprem as restrições regulatórias e de negócio.
• Mudança de Infraestrutura: O trabalho argumenta que a segurança não deve ser delegada a aplicações ou agentes, mas aplicada pelo próprio motor de banco de dados, governando como os dados são transformados e combinados, não apenas quem os acessa.

Os autores observam que, embora o protótipo atual foque em consultas SQL-92 monotônicas, estender o DFC para construtos não monotônicos (negação, recursão) é um próximo passo necessário para uma aplicabilidade mais ampla. O sistema está disponível como código aberto.