Como avaliar um proxy de IA com políticas e redação de dados sensíveis

Uma API de atendimento envia tickets a um modelo de linguagem. Um worker resume incidentes usando logs. Um assistente consulta documentos internos e aciona ferramentas. Todos precisam de acesso a modelos, mas não deveriam transmitir indiscriminadamente e-mails, credenciais ou informações comerciais.

A divulgação de informações sensíveis é um risco reconhecido pelo OWASP para aplicações com grandes modelos de linguagem, ou LLMs. Restrições no prompt não substituem controles de acesso e tratamento dos dados. (genai.owasp.org)

Este artigo propõe um protocolo de avaliação: provar quais bytes atravessam a fronteira, quais decisões são aplicadas e o que acontece durante falhas. Os critérios e números apresentados são propostas de engenharia, não resultados de benchmark nem garantias de produto.

O recorte é complementar ao de dimensionamento de rede para sandboxes de agentes: aqui avaliamos o conteúdo e a decisão de segurança, sem repetir a configuração de isolamento de rede.

1. O que estamos avaliando

Chamaremos de proxy de tráfego de IA o componente intermediário que recebe chamadas das aplicações e as encaminha aos serviços de inferência. Para esta avaliação, ele deve oferecer ou integrar autenticação, políticas, inspeção e transformação de conteúdo.

Não confunda três responsabilidades:

• Gateway: encaminhar chamadas, administrar conexões e aplicar limites.
• Motor de políticas: decidir se determinada operação pode acontecer.
• Detector e transformador: identificar informações sensíveis e modificar os campos autorizados.

O Open Policy Agent, ou OPA, avalia dados estruturados usando Rego. Ele pode fornecer a decisão, mas a integração continua responsável por executar o bloqueio ou encaminhamento. (openpolicyagent.org)

Neste texto, redação de dados significa redaction: remoção ou ocultação de conteúdo, e não produção de texto. Defina explicitamente a transformação desejada:

O Presidio separa identificação de entidades e transformação por operadores. Sua documentação alerta que a detecção automatizada não garante encontrar todos os dados sensíveis. Portanto, ausência de achados não deve ser interpretada como prova de ausência de risco. (data-privacy-stack.github.io)

Como regra de projeto, não trate substituição de identificadores como garantia de anonimização: contexto, relações e mapas reversíveis também precisam entrar na análise.

2. Arquitetura e fronteiras de confiança

A arquitetura de referência proposta é:

Aplicação → autenticação → validação estrutural → inspeção → transformação → decisão final → adaptador do provedor → modelo

No retorno:

Modelo → inspeção de saída → transformação ou bloqueio → aplicação

O plano de controle publica políticas e configurações. O plano de dados executa essas decisões em cada chamada. Exija que ambos tenham responsabilidades e permissões separadas.

O contrato de avaliação deve exigir:

1. Identidade derivada de credenciais verificadas, não de um cabeçalho livre como X-Tenant.
2. Limites de tamanho, descompressão e tempo antes de operações custosas.
3. Inspeção de todos os campos relevantes do protocolo aceito.
4. Decisão vinculada ao corpo efetivamente encaminhado.
5. Credenciais do provedor inacessíveis à aplicação quando essa separação fizer parte do modelo de segurança.
6. Reavaliação de destino, região e modelo em qualquer fallback.

Mapeie também histórico, documentos recuperados, argumentos de ferramentas, arquivos, imagens, áudio, respostas, erros e telemetria. Para cada superfície, registre: inspecionada, bloqueada ou fora do escopo. Na proposta deste artigo, conteúdo fora do escopo não recebe autorização implícita.

A configuração de endpoint na aplicação deve ser acompanhada de um teste de tentativa de acesso direto ao provedor. Para ferramentas e Model Context Protocol, ou MCP, complemente esta análise com autenticação e fronteiras de confiança em MCP.

3. Defina a política antes de comparar produtos

Comece com uma tabela de decisões aprovada pelas equipes responsáveis pelos dados:

Especifique precedência: uma regra de bloqueio deve vencer uma regra permissiva. Inclua versão, responsável, justificativa e prazo para exceções.

Também defina o comportamento sem plano de controle. Uma opção é continuar com o último pacote validado por um período aprovado, sem aceitar alterações. Sem política válida, a recomendação para rotas protegidas é negar.

Exemplo executável de decisão com OPA

O exemplo abaixo usa Rego v1. É uma política didática de autorização após a transformação; não implementa detecção, redação nem um proxy. Os campos de entrada são um contrato interno do exemplo, não propriedades de um produto.

Salve como policy.rego:

package ai.egress

import rego.v1

default allow := false

allow if {
    input.identity.tenant == "support"
    input.destination == "approved-provider"
    input.model == "support-approved"
    input.original_classification in {"public", "internal"}
    input.scan.complete == true
    input.scan.remaining_sensitive == 0
    input.transform.status == "verified"
}

approved-provider e support-approved são aliases internos ilustrativos. Em produção, o adaptador deve resolvê-los para destinos autorizados, sem permitir que o cliente substitua a URL.

Salve como input.json:

{
  "identity": {"tenant": "support"},
  "destination": "approved-provider",
  "model": "support-approved",
  "original_classification": "internal",
  "scan": {"complete": true, "remaining_sensitive": 0},
  "transform": {"status": "verified"}
}

Com OPA 1.x instalado, execute:

opa eval --fail --data policy.rego --input input.json 'data.ai.egress.allow == true'

A comparação com true é importante: --fail trata resultado indefinido ou vazio como falha; consultar apenas uma decisão definida como false não produz o mesmo comportamento. (openpolicyagent.org)

Teste também entradas sem identidade, com destino diferente, inspeção incompleta e classificação restrita. Todas devem negar.

O proxy deve construir esses metadados a partir de componentes confiáveis. remaining_sensitive: 0 representa o resultado do detector, não uma verdade absoluta. verified só deve existir após a transformação exigida e a validação do corpo final. Nunca aceite essas declarações diretamente do cliente, nem reutilize uma aprovação para outro corpo, tenant ou versão de política.

4. Monte um corpus que possa reprovar a solução

Use dados sintéticos com marcações esperadas por entidade e por requisição. Inclua português brasileiro e inglês, casos benignos e situações ambíguas. Não use somente exemplos que o fornecedor demonstra.

O conjunto proposto deve cobrir:

• E-mails, telefones, CPF, endereços e identificadores corporativos.
• Segredos sintéticos com formatos representativos, nunca credenciais ativas.
• Unicode, separadores incomuns, texto multilíngue e entidades adjacentes.
• JSON aninhado, histórico, documentos recuperados e argumentos de ferramentas.
• Payloads grandes, comprimidos, malformados e formatos não suportados.
• Entidades divididas entre eventos de streaming.
• Erros, retries, fallback, cache e isolamento entre tenants.

Separe o conjunto usado para ajustar reconhecedores daquele usado para aprovação. Para idiomas e documentos específicos, exija evidência no corpus correspondente, em vez de inferir cobertura a partir do nome do produto.

Métricas de qualidade

Adote definições explícitas:

• Precisão: TP / (TP + FP).
• Recall: TP / (TP + FN).
• Taxa de vazamento por requisição: requisições com algum conteúdo proibido encaminhado, divididas pelas requisições que continham conteúdo proibido.
• Preservação de utilidade: desempenho da tarefa após transformação, comparado à referência aprovada.

TP, FP e FN representam verdadeiros positivos, falsos positivos e falsos negativos. Defina se um acerto exige cobertura integral da entidade; mascarar somente metade de uma credencial não deveria contar como sucesso.

No protocolo proposto, qualquer vazamento no conjunto crítico reprova a versão. Registre tamanho e composição desse conjunto: zero falhas observadas não demonstra risco zero fora dele.

5. Verifique os bytes, não somente a decisão

Monte um ambiente isolado com um destino de teste controlado no lugar do provedor. Esse destino deve capturar os corpos recebidos depois da transformação e da adaptação de protocolo, usando apenas dados sintéticos.

Para cada caso:

1. Envie uma entrada com identificador de teste não sensível.
2. Capture o resultado no destino e no cliente.
3. Verifique ausência dos valores proibidos e presença da transformação esperada.
4. Para bloqueios, confirme que nenhuma chamada de inferência chegou ao destino.
5. Procure os marcadores também em logs, traces, erros e armazenamento temporário.

Um HTTP 403 no cliente não é evidência suficiente: o teste precisa excluir o cenário em que o corpo já foi encaminhado antes da negativa.

Para tokenização reversível, acrescente tentativas de restauração em outra sessão e outro tenant, expiração do mapa e indisponibilidade do armazenamento. Nesta proposta, não restaurar conteúdo é preferível a restaurá-lo para o destinatário errado.

6. Streaming: exija uma garantia precisa

Avalie separadamente streaming da requisição e da resposta. No primeiro, a fronteira protegida é o provedor; no segundo, é o consumidor final.

Faça o destino de teste emitir uma entidade sensível em partes, como ana@ e example.test. A aprovação deve depender do conteúdo concatenado recebido pelo cliente, não apenas do resultado de inspeção de cada fragmento isolado.

Exija que o fornecedor documente uma destas estratégias:

• Buffer completo antes da liberação.
• Janela com retenção suficiente para uma classe delimitada de padrões.
• Bloqueio de streaming nas rotas que exigem inspeção integral.

Uma janela finita não deve ser vendida como garantia de detectar qualquer segredo arbitrariamente longo. Estabeleça limites de tamanho, tempo de retenção e comportamento quando a garantia não puder ser cumprida.

Em integrações com Envoy, o filtro ext_proc permite processamento externo. Entretanto, observability_mode observa sem aplicar respostas do processador; não equivale a enforcement. failure_mode_allow também altera o tratamento de falhas. Verifique a documentação da versão efetivamente implantada. (envoyproxy.io)

Inclua cancelamento, pressão de retorno, timeout, JSON estruturado e argumentos de ferramentas nos testes. Se a resposta já começou, exija um sinal de interrupção que o cliente reconheça como falha, sem retry silencioso que replique efeitos de ferramentas.

7. Cenário próximo de produção

Problema: uma plataforma de atendimento possui API e workers no Kubernetes. Tickets contêm contatos pessoais e, ocasionalmente, credenciais copiadas por usuários.

Solução proposta: acesso centralizado à inferência, classificação original preservada, redação de contatos permitidos e bloqueio de segredos.

Implementação: autenticar cada workload; impedir saída direta não autorizada; inspecionar antes do envio; manter políticas em Git; executar testes sintéticos no pipeline; liberar por tenant em canário.

Resultado esperado: evidências reproduzíveis de bloqueio, transformação e isolamento, acompanhadas do impacto sobre latência e utilidade. Não se pressupõe ganho percentual ou eliminação completa do risco.

Kubernetes: autoscaling como parte do experimento

O manifesto completo abaixo cria apenas um HorizontalPodAutoscaler, ou HPA. Ele pressupõe um namespace ai-gateway e um Deployment ai-proxy já instalados e configurados conforme o produto escolhido. Não instala um proxy nem ativa redação.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ai-proxy
  namespace: ai-gateway
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-proxy
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Percent
          value: 25
          periodSeconds: 60

O HPA usa utilização de CPU relativa aos requests e depende da API de métricas disponível. scaleTargetRef identifica o Deployment; behavior controla a redução de réplicas. (kubernetes.io)

Três a doze réplicas, 65% e os intervalos são valores ilustrativos. Adapte-os ao teste de carga. Para esta avaliação, acompanhe também conexões abertas, fila e bytes em buffer; CPU não deve ser o único critério de capacidade. O autoscaling não substitui limites de admissão nem capacidade disponível nos nós.

Exija requests e limits revisados, distribuição entre zonas, orçamento de interrupção e drenagem de streams. A distribuição topológica e o PodDisruptionBudget atendem aspectos diferentes de disponibilidade; o segundo não impede falhas involuntárias nem controla o rolling update do Deployment. (kubernetes.io)

As probes também têm papéis distintos: startup protege a inicialização, readiness determina aptidão para tráfego e liveness detecta necessidade de reinício. Na arquitetura proposta, não vincule liveness à disponibilidade do provedor externo. (kubernetes.io)

Desenvolvimento versus produção

Em desenvolvimento, use uma réplica, corpus sintético e destino simulado. Preserve desde cedo o comportamento de bloqueio.

Para produção, acrescente múltiplas réplicas, limites de concorrência, alertas, isolamento de workloads e recuperação testada. Exija ServiceAccount dedicada, RBAC mínimo, TLS entre componentes e identidade de workload para acesso ao gerenciador de segredos. Se houver necessidade de Secrets, controle acesso e rotação; não grave credenciais em imagens ou Git.

Inclua backup e teste de restauração de políticas e configurações. Se existir mapa reversível persistente, defina recuperação, expiração, criptografia e segregação por tenant. Não transforme a cópia de payloads brutos em uma estratégia de backup.

8. Observabilidade sem criar outro vazamento

OpenTelemetry recomenda tratar dados sensíveis na telemetria e evitar coleta desnecessária. A avaliação deve abranger a instrumentação, não somente o payload encaminhado ao modelo. (opentelemetry.io)

Para o projeto proposto, registre identificador aleatório da requisição, versão da política, ação, categoria detectada, destino lógico, duração e tamanhos. Não registre prompts completos, respostas, credenciais ou valores encontrados.

Crie dashboards com:

• Latência p50, p95 e p99 da inspeção, decisão e chamada total.
• Tempo até o primeiro token e duração dos streams.
• Throughput, fila, conexões, memória de buffer e reinicializações.
• Bloqueios esperados separados de erros operacionais.
• Timeouts do detector e divergência de versões de política.

Defina um objetivo de nível de serviço, ou SLO, para requisições elegíveis. Uma negativa correta não é indisponibilidade; uma chamada permitida bloqueada por falha de infraestrutura é outro evento operacional. Evite IDs de usuário e valores sensíveis como labels de métricas.

9. Performance, custos e FinOps

Faça a comparação sem inspeção e com inspeção usando o mesmo corpus, concorrência, tamanho de payload e perfil de streaming. Separe o custo do proxy da variabilidade do modelo. Não estime o overhead subtraindo percentis de experimentos independentes.

Como aproximação inicial de buffer, suponha, hipoteticamente, 400 chamadas simultâneas com 512 KiB retidos por chamada: são cerca de 200 MiB apenas de conteúdo. Acrescente cópias, estruturas internas, conexões e memória do detector, e valide o pico com carga realista.

No orçamento, inclua inferência, retries, detectores, nós, tráfego entre zonas, saída de rede, balanceadores, telemetria e armazenamento temporário. Compare custo por tarefa útil concluída, não apenas por requisição aceita.

A recomendação é manter capacidade estável para a fronteira de segurança e avaliar Spot somente com margem para interrupções. Para caches, exija segregação por tenant, modelo e versão de política; comece sem cache de conteúdo sensível até demonstrar isolamento e invalidação corretos.

10. Troubleshooting e injeção de falhas

Comandos reais para o ambiente descrito:

kubectl get pods -n ai-gateway
kubectl get hpa -n ai-gateway
kubectl describe hpa ai-proxy -n ai-gateway
kubectl top pods -n ai-gateway
kubectl get events -n ai-gateway --sort-by=.metadata.creationTimestamp
kubectl rollout status deployment/ai-proxy -n ai-gateway

Use logs apenas depois de confirmar a política de sanitização. Não ative captura irrestrita de corpos em produção para investigar redação.

No ambiente de teste, interrompa detector, plano de controle e armazenamento de tokens; injete latência; esgote limites; simule queda de zona. O resultado exigido deve distinguir degradação controlada de envio sem inspeção.

11. Upgrades, rollback e critérios de aprovação

Versione em conjunto proxy, adaptadores, políticas, reconhecedores e configurações de idioma. Fixe artefatos por versão e digest quando disponíveis; não promova uma tag mutável sem registrar o artefato efetivo.

Execute regressão no pipeline, canário com dados sintéticos e promoção gradual. Observação passiva pode ajudar a medir divergências, mas não deve substituir o controle obrigatório existente.

No rollback, restaure uma combinação compatível de aplicação e política. Não use acesso direto ao provedor como recuperação de disponibilidade. Antes da expansão, teste reversão, restauração do estado necessário e tratamento de conexões em andamento.

Use critérios eliminatórios antes de qualquer nota ponderada:

• Nenhum vazamento no corpus crítico aprovado.
• Negativa sem chamada de inferência ao destino.
• Isolamento entre tenants e ausência de bypass nos testes previstos.
• Streaming e formatos não suportados com comportamento explícito.
• Falhas de inspeção sem encaminhamento indevido.
• Telemetria sem os marcadores sensíveis do corpus.
• Latência, capacidade e custo dentro dos limites acordados.
• Rollback reproduzível e responsável operacional definido.

12. Quando utilizar, alternativas e limites

Esta abordagem é indicada quando múltiplas aplicações precisam de políticas consistentes, destinos controlados e evidências centralizadas, e existe equipe para operar essa dependência.

Para uma aplicação pequena, com dados previamente minimizados e poucos fluxos, uma camada explícita na própria aplicação pode ser mais simples. Ainda assim, exija testes equivalentes de conteúdo e falha.

Como decisão arquitetural:

Não escolha um proxy apenas por uma lista de integrações. Também não o trate como substituto da autorização em ferramentas, da classificação dos dados ou da segurança da aplicação.

Resumo prático

Avalie decisões e bytes. Teste dados sintéticos representativos, streaming, erros e caminhos alternativos. Separe detecção de transformação, e transformação de autorização. Exija evidência de isolamento e recuperação antes de otimizar throughput.

Conclusão

Um proxy de IA deve ser aprovado como componente da fronteira de confiança, não apenas como roteador de modelos. Para Platform Engineering, isso significa oferecer contratos claros e capacidades reutilizáveis. Para SRE, significa medir disponibilidade sem esconder falhas de segurança. Para DevOps, significa transformar políticas e testes de vazamento em artefatos versionados do pipeline.

A decisão final deve combinar proteção comprovada no escopo testado, utilidade preservada e operação sustentável. Se essas três condições não puderem ser demonstradas, o próximo passo é restringir o escopo ou simplificar a arquitetura, não liberar tráfego sem controle.