Talk to the Team

Tell us about your stack and the privacy problems you're trying to solve. We typically respond within one business day.

Prefer email? support@philterd.ai

Prefer to skip the form? Pick a time on our calendar →
or send a message

Please do not enter PII or PHI in this form. If you need to share an example, use a sanitized one.

← All posts

Redact PII From Your AI Agent in One Block of Config

You are debugging a support issue. A customer record reproduces the bug, so you paste it into Claude Desktop to get a second opinion on the stack trace. The row has a name, an email, a phone number, and the last four of a card. It is now in a model’s context, in a vendor’s logs, and outside your perimeter. You did not mean to send any of it.

This is the gap that production controls miss. A gateway in front of your LLM traffic protects the application. It does nothing for the developer who pastes real data into a chat window at 6pm. That surface is the agent, and the place to fix it is inside the agent’s tool loop.

That is what Philter MCP is for. It exposes Philter’s PII and PHI redaction as Model Context Protocol tools, so any MCP-aware client can redact text before it ever reaches the model. No integration code, no SDK, one block of config.

The fix: one block of config

Philter MCP is a thin client in front of your own running Philter instance. You install the server, point it at Philter, and the redaction tools appear in your client.

For Claude Desktop, add this to claude_desktop_config.json (Settings, Developer, Edit Config):

{
  "mcpServers": {
    "philter": {
      "command": "uvx",
      "args": ["philter-mcp"],
      "env": {
        "PHILTER_BASE_URL": "https://localhost:8080",
        "PHILTER_VERIFY_SSL": "false"
      }
    }
  }
}

uvx downloads and runs the published package on demand, so there is nothing to install first. (pipx run philter-mcp works the same way, and a Docker image is published if you would rather run it in a container.)

For Claude Code, it is a single command:

claude mcp add philter \
  --env PHILTER_BASE_URL=https://localhost:8080 \
  --env PHILTER_VERIFY_SSL=false \
  -- uvx philter-mcp

Then claude mcp list should show philter connected. PHILTER_VERIFY_SSL=false is for Philter’s default self-signed certificate in local development; drop it once you have a real certificate, and set PHILTER_API_KEY if your instance requires a bearer token.

A working transcript

With the server connected, the tools are available mid-conversation. Here is the support-debugging scenario, handled correctly this time:

You: Before I dig into this bug, redact any personal data in this record: Maria Alvarez, maria.alvarez@example.com, 555-712-4490, card ending 4242

Claude: (calls redact_text)

I redacted it before reading. Here is the safe version:

{{{REDACTED-entity}}}, {{{REDACTED-email-address}}}, {{{REDACTED-phone-number}}}, card ending {{{REDACTED-creditcard}}}

The redaction report shows four matches (PERSON, EMAIL_ADDRESS, PHONE_NUMBER, CREDIT_CARD) with their positions and confidence. Now, what is the bug?

The redact_file tool does the same for a UTF-8 file on disk, which is handy when the reproduction is a CSV or a log rather than a single line:

You: Redact ~/tmp/support-export.csv and summarize what types of PII it contained.

Claude: (calls redact_file)

Redacted. The file contained 1,204 entities across three types: EMAIL_ADDRESS (612), PHONE_NUMBER (588), and PERSON (4). The redacted copy is ready and no original values were returned to me.

That last clause is the important one.

Under the hood

Philter MCP wraps the Philter REST API. When you call redact_text or redact_file, the server sends the text to your Philter instance, gets back the redacted output plus a report, and returns that to the client.

The report contains filter types, character positions, confidence, and the replacement token. It does not contain the original matched values. So even though the agent orchestrates the redaction, the sensitive text never enters the model’s context. Privacy is preserved by what the tool refuses to return, not by trusting the model to behave. (explain_redactions can opt in to returning matched values with include_text=true, but only as a deliberate local policy-debugging step.)

Both redaction tools accept optional policy, context, and document_id arguments. context and document_id are passed straight through to Philter, so its consistent pseudonymization and format-preserving behavior hold across calls: the same email redacts to the same replacement everywhere in a context, which keeps a multi-file redaction internally consistent. There are six tools in total. The other four (list_policies, get_policy, and status, plus explain_redactions) let an agent inspect the connected instance and debug a policy.

Because it is a thin client in front of Philter, everything still runs inside your environment. Philter is self-hosted, there is no Philterd cloud, and your data never leaves your perimeter.

When to use MCP, the AI Proxy, or Phileas

Philter MCP is one of three ways to put Philter’s redaction where you need it. They are complementary, and many teams run more than one.

  • Philter MCP: developer and agent workflows. Reach for MCP when the surface is a person or an agent using an MCP-aware client: Claude Desktop, Claude Code, Cursor, Continue, Goose. It is the right tool for IDE-side redaction, agent tool loops, and the ad-hoc “let me paste this in to debug” moment. This is the developer-workflow surface that production controls do not cover.

  • Philter AI Proxy: production LLM traffic. When you need to guard application traffic to OpenAI, Anthropic, or any other provider, put the proxy in the path. It redacts prompts at the network layer with a gateway pattern and audit logging, with no change to the calling code. Use it for production; use MCP for development. They guard different surfaces, and running both is normal.

  • Phileas: embed redaction in your own service. When you want redaction compiled into a JVM application rather than called over the network, Phileas is the library Philter itself is built on. Reach for it when you are building the redaction into your own product.

A quick way to self-route: if a developer or agent is doing the redaction interactively, use MCP. If application traffic is doing it automatically in production, use the proxy. If your own code is doing it in-process, use Phileas.

What is next

Today the tools take a policy name or fall back to a default. On the roadmap is letting an agent express a policy inline in PhiSQL, the SQL-like language for PII operations whose v0.1 specification is already published, so a developer could say “redact every SSN and email, keep the last four of cards” and have it compile to a Philter policy on the fly.

Try it

Philter MCP is open source under Apache 2.0. If you already run Philter, you are about two minutes from redaction inside your agent:

claude mcp add philter \
  --env PHILTER_BASE_URL=https://localhost:8080 \
  --env PHILTER_VERIFY_SSL=false \
  -- uvx philter-mcp

If you do not run Philter yet, start it locally first, then add the MCP server on top. The redaction your production pipeline already trusts is the same redaction your agent will call.