Prevenção contra perda de dados para tráfego de LLM: onde ela deve ser implementada

Inspecionar e controlar dados sensíveis antes que eles saiam do seu perímetro em um prompt, uma chamada de ferramenta ou uma resposta do modelo. Ela difere do DLP clássico porque não há arquivo nem destino não autorizado — a carga é JSON dentro de uma sessão TLS para uma API pela qual você paga. Os controles precisam entender o esquema da requisição e ficar em um ponto de controle de saída autenticado.

Três motivos se somam. O destino está na lista de permissões por design, então as regras de destino nunca disparam. O conteúdo fica em um array de conversa aninhado, e não em um arquivo ou campo de formulário, o que os mecanismos orientados a documentos analisam mal. E, sem inspeção de TLS, não há nada para analisar — sendo que nem mesmo um proxy com inspeção consegue dizer qual chamador enviou a requisição.

Depende do detector. A detecção de PII / PHI integrada do TrueFoundry é apenas de mutação — ela sempre oculta os dados, nunca rejeita. Para um bloqueio rígido, você precisa de uma integração com capacidade de validação, como AWS Bedrock Guardrails, Azure PII ou CrowdStrike. “Detecção de PII” em uma lista de recursos nunca diz se o resultado é uma ocultação ou um 400.

Sim. O TrueFoundry é executado na sua VPC, on-prem, em ambiente air-gapped ou híbrido, de modo que os prompts e as respostas nunca saem do seu domínio, mesmo quando você roteia entre muitos provedores.

Sim. Ele inclui um MCP Gateway, um Agent Gateway e um MCP & Agents Registry com controle de acesso em nível de ferramenta. Agentes criados com LangGraph, CrewAI, AutoGen ou um framework próprio podem ser governados de forma centralizada.

Sim. O gateway é compatível com OpenTelemetry e se integra com Grafana, Datadog, Prometheus ou a sua stack preferida. Ele rastreia cada requisição, do prompt à execução da ferramenta e do modelo, para que você obtenha logs unificados sem precisar remover o que você já usa.