Resumo Técnico: Verificação de Conformidade em Tempo de Execução para Agentes de IA

Declaração do Problema

Agentes de IA lidam cada vez mais com dados pessoais por meio de uso de ferramentas, chamadas de função e diálogos de múltiplos turnos. Diferente das APIs tradicionais, os agentes decidem dinamicamente quais ferramentas chamar, quais argumentos passar e o que revelar em linguagem natural. Essas decisões em tempo de execução podem desencadear obrigações sob o Regulamento Geral de Proteção de Dados (GDPR), como o processamento de dados pessoais sem consentimento ou a divulgação de dados após um pedido de exclusão.

As práticas de teste atuais falham em abordar esse risco dinâmico:

• Red-Teaming Offline: Testa modelos com prompts curados, mas não impõe regras em tempo de execução nem observa o estado da sessão dos agentes implantados.
• Bibliotecas de Guardrails: Correspondem a padrões em entradas/saídas individuais, mas carecem de histórico de sessão, falhando em rastrear se o consentimento foi concedido anteriormente em um diálogo ou se um propósito foi declarado.

Consequentemente, uma implantação de agente pode estar em conformidade em um diálogo e não estar em conformidade em outro sem qualquer alteração de código ou de pesos do modelo. Isso cria a necessidade de verificação em tempo de execução sobre o rastro de eventos do agente, acompanhada de um driver de ataque em processo para testar o monitor com entradas hostis.

Metodologia: Estrutura C-Trace

Os autores propõem o C-Trace (Compliance Trace-based Runtime Agent Conformance Enforcement), uma estrutura que trata a conformidade com o GDPR como uma propriedade de tempo de execução de um fluxo de eventos, em vez de uma propriedade de uma única mensagem.

1. Modelo de Evento e Extração

A estrutura instrumenta o loop do agente para converter execuções em linguagem natural em um rastro de eventos tipado ($\tau = e_1 \dots e_n$). Os eventos incluem UserMsg (Mensagem do Usuário), AsstMsg (Mensagem do Assistente), ToolCall (Chamada de Ferramenta), ToolRet (Retorno de Ferramenta), Consent (Consentimento) e Erasure (Exclusão).

• Anotação: Um extrator anota cada evento com categorias de dados ($C(e)$) e propósitos ($\Pi(e)$).
• Política: Uma política de sessão define propósitos declarados, vínculos ferramenta-propósito e listas brancas de categorias de dados por propósito (dados necessários).

2. Predicados Formais

Quatro princípios do GDPR são codificados como predicados de primeira ordem sobre o rastro crescente. Esses predicados são monotônicos: uma vez que uma violação ocorre, ela não pode ser "corrigida" por eventos subsequentes.

• P1 (Consentimento): O processamento de dados requer um evento de Consent prévio para aquele propósito específico (a menos que um fundamento de Interesse Legítimo se aplique).
• P2 (Limitação de Propósito): Todo propósito anexado a um evento deve ser declarado na política.
• P3 (Minimização de Dados): As categorias de dados em uma chamada de ferramenta devem ser necessárias para pelo menos um dos propósitos declarados da chamada.
• P4 (Direito à Exclusão): Após um evento de Erasure para um sujeito, nenhum evento subsequente pode revelar o identificador desse sujeito.

3. Monitor de Tempo de Execução e Driver de Ataque

• Interceptor: Posicionado entre o loop do agente e as APIs de ferramentas, ele avalia os predicados incrementalmente. As decisões incluem forward (encaminhar), redact (redigir/remover dados não necessários) ou block (bloquear o evento).
• Attack Driver (Driver de Ataque): Gera diálogos adversários visando cada predicado usando:
  • Prompts gerados via DSPy: Variantes de solicitações semente usando interpretação de papéis (role-play), urgência e enquadramento de jailbreak.
  • Prompts de corpus real: Prompts literais de corpora de red-teaming (HarmBench, AdvBench, DAN).
• Oracle (Oráculo): Um oráculo separado e observável determina o sucesso do ataque verificando o rastro aceito contra a política, independentemente dos predicados internos do monitor.

4. Validação Cruzada

Para garantir que o monitor operacional corresponda à especificação formal, a mesma lógica de política é implementada em três runtimes:

1. Python: Implementação de conformidade operacional.
2. Rego/OPA: Política voltada para auditoria.
3. MFOTL (MonPoly): Especificações de lógica temporal formal.
   Os autores verificam que todos os três concordam evento a evento em cada rastro.

Avaliação e Resultados

A estrutura foi avaliada em quatro estudos de caso reestruturados sob a ótica do GDPR: Shopper (varejo), Airline (viagens), MedAgent (saúde) e FinAssist (bancário/KYC).

Métricas Principais

• Taxa de Sucesso de Ataque (ASR - Attack Success Rate): A porcentagem de ataques que conseguem contornar o monitor.
• Taxa de Falso Positivo (FPR - False Positive Rate): A porcentagem de solicitações benignas incorretamente bloqueadas.
• Taxa de Realização: Com que frequência o modelo tenta a violação na ausência de um monitor.

Descobertas

1. Vulnerabilidade de Agentes Não Monitorados: Sem um monitor, os agentes cometem violações em todas as quatro famílias. O bypass de consentimento (A1) e a coleta excessiva (A3) são frequentemente acionados (até 100% de ASR em alguns casos).
2. Limitações de Baselines:
   • Regex/Presidio (Sem estado/Stateless): Estes baselines falham em detectar violações dependentes do histórico da sessão (Consentimento, Limitação de Propósito, Exclusão). Embora o Presidio reduza a coleta excessiva, ele não consegue impedir o bypass de consentimento ou a recuperação pós-exclusão.
   • Baseline Aleatório: Altos falsos positivos (72–88%) sem proteção direcionada.
3. Desempenho do C-Trace:
   • Extração Perfeita: Alcança 0% de ASR e 0% de FPR em todos os estudos de caso e registros de ataque (gerados e de corpus real).
   • Extração Ruidosa: Sob ruído de extração de categoria inferior a 10% (simulando queda de dados e excesso de tipagem):
     • O ASR permanece $\le$ 12% (significativamente menor que os baselines).
     • O FPR permanece $\le$ 16%.
   • Ablação: Remover predicados individuais restaura famílias de ataques específicas (ex: remover P1 restaura o bypass de consentimento), confirmando que cada predicado é necessário.
4. Sobrecarga (Overhead): O monitor adiciona uma latência mediana negligenciável de 1.8 $\mu$s por evento.

Significância e Alegações

O artigo afirma ser o primeiro trabalho a aplicar a verificação de tempo de execução de obrigações do GDPR aos rastros de execução de linguagem natural de agentes de IA.

• Novidade: Diferente dos guardrails sem estado, o C-Trace raciocina sobre o rastro da sessão, permitindo capturar violações que dependem de eventos anteriores (ex: consentimento prévio ou exclusão).
• Praticidade: A estrutura opera como um interceptor em processo sem exigir mudanças no modelo subjacente ou nas implementações das ferramentas. Ela produz logs de auditoria JSONL de adição exclusiva (append-only) adequados para revisão de conformidade.
• Confiabilidade: Os resultados indicam que a confiabilidade do monitor depende fortemente da precisidade do extrator de categorias. Embora a lógica da política seja robusta, a perda de categorias devido a erros de extração é o principal modo de falha.
• Escopo: A abordagem foca em quatro princípios centrais do GDPR (Consentimento, Limitação de Propósito, Minimização de Dados, Direito à Exclusão) aplicáveis em múltiplos domínios (varejo, saúde, finanças) e bases legais (consentimento, obrigação legal).

Os autores concluem que o monitoramento baseado em rastro é uma camada de aplicação prática para agentes de IA, desde que a extração de eventos subjacente seja de alta qualidade e mecanismos de fechamento seguro (fail-closed) sejam considerados para categorias de dados ambíguas.