Prevent AI Agents from Leaking Sensitive Data with Fiddler Guardrails and LiteLLM

‍

AI agents can expose sensitive data through prompts, retrieved context, tool results, and model responses. A production API key or patient record can leave the organization before conventional monitoring detects it.

Fiddler Guardrails integrates with LiteLLM to evaluate model traffic inline and redact or block sensitive information before it reaches its next destination.

Powered by purpose built Centor Models, these evaluations meet latency requirements without relying on external LLM API calls. The same approach can also be applied with gateways such as Kong and AgentGateway.

Sensitive Data Leakage Risk in Agent Workflows

AI agents do more than exchange messages with a large language model (LLM). They retrieve documents, query databases, call application programming interfaces (APIs), read files, and pass results to other agents. Each step can add PII/PHI, credentials, secrets or harmful data to the agent's context. Without inline enforcement, sensitive information can cross the organizational boundary before conventional monitoring detects the exposure.

Imagine an agent retrieving a production database API key from a tool result and then including it in a prompt sent to an external model provider. Or consider a healthcare assistant placing sensitive patient information from a retrieved record into a response that reaches a third party. In either case, the exposure occurs as part of the agent's normal workflow and may be discovered only after the data has already left the organization's control.

Sensitive data exposure can occur in both the request and response path:

• On the request path: Prompts, retrieved context, memory, or tool results can send sensitive information to the model provider.
• On the response path: Model outputs can disclose sensitive information to a user, another agent, a tool, or a persistent data store.

Fiddler Guardrails Enforce Policy Inline

Fiddler Guardrails is the enforcement layer of the Fiddler AI Control Plane. Where evaluation and monitoring tell you how agents are behaving, Guardrails enforces what they are allowed to send and receive. Every request and response is evaluated inline before they reach their next destination. It includes four categories of risks:

These guardrails run on Fiddler Centor, Fiddler's evaluation engine, which uses purpose-built Centor Models to score prompts and responses in the customer's environment. When deployed in the customer's cloud or VPC, policy evaluation remains within the organization's environment rather than sending sensitive content to an external foundation model for evaluation.

One of the following actions can be taken based on the results of guardrail evaluation:

Redaction is useful when sensitive information can be removed without changing the intent of the request. For example, a guardrail can remove a patient identifier while allowing the model to summarize the remaining clinical text. Blocking is more appropriate when the sensitive value is essential to the requested action, or when the surrounding content still creates risk after that value is removed. This distinction allows organizations to protect sensitive data without rejecting every request that contains it.

Alongside inline enforcement, the Fiddler AI Control Plane helps teams track agent activity, quality, performance, and cost, investigate failures, and retain enforcement decisions for audits.

Enforcing Guardrails Through LiteLLM

LiteLLM is an LLM gateway that gives agents a common interface to model providers, which makes it a natural place to enforce policy. Every request and response passes through it, so Fiddler Guardrails can evaluate traffic there once and apply the same rules across agents, frameworks, models, and providers.

LiteLLM supports custom guardrails in its proxy configuration. The example configuration below shows an integration pattern for running Fiddler Guardrails before model requests and after model responses proxied through LiteLLM.

In the example below, the pii and secrets sections enable the two checks independently. For PII, threshold defines the minimum confidence required for a detection. Lower values increase sensitivity. redact redacts detected sensitive information and allows processing to continue, while block rejects the request or response. Structured tool call arguments are always blocked, when a detection is triggered, because they cannot be safely redacted.

 - guardrail_name: fiddler-llm
    litellm_params:
      guardrail: generic_guardrail_api
      mode: [pre_call, post_call]
      skip_system_message_in_guardrail: true
      api_base: os.environ/FIDDLER_GUARDRAIL_API_BASE
      headers:
        Authorization: os.environ/FIDDLER_AUTHORIZATION
[...]
      additional_provider_specific_params:
        failure_mode: closed
        timeout: 3
        pii:
          enabled: true
          config:
            threshold: 0.8
            mode: redact
        secrets:
          enabled: true
          config:
            mode: redact

The input guardrail runs in pre_call mode and evaluates content before LiteLLM forwards the request to the LLM model provider. The output guardrail runs in post_call mode and evaluates the response before LiteLLM returns it to the agent.

The diagram below shows LiteLLM invoking Fiddler Guardrails before model requests and after model responses. Sensitive information is redacted before a request crosses the organizational boundary or before a response reaches an agent.

This type of setup provides a centralized enforcement point for model traffic, giving teams consistent protection and a single way to manage and update Fiddler Guardrails policies across agents, frameworks, models, and providers.

Centor also makes evaluation at scale more cost effective, regardless of where enforcement occurs. Unlike external LLM judges, which add an API charge for every trace they evaluate, Centor Models run in your environment with no external API call. That removes the tradeoff between coverage and cost, so teams can evaluate more production traffic without watching their API bill grow with it.

The Fiddler dashboard below shows how Guardrails acts on traffic to an agent, including the number of requests inspected, blocked, or redacted and the classes of sensitive values withheld from leaving the organizational boundary.

Fiddler Guardrails Beyond LiteLLM

The LiteLLM configuration above is one way to put Fiddler Guardrails in the path of your model traffic, not the only one. The same pattern works with other gateways, including Kong and AgentGateway . Wherever your traffic already flows, Guardrails can evaluate requests and responses there and apply one set of policies across agents, frameworks, models, and providers, so you can pick the gateway that fits your architecture without giving up consistent enforcement.

Learn how Fiddler Guardrails enforces policies through LiteLLM — request a demo.