Philterd

Talk to an Expert

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

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

← All posts

Why API-Based Redaction is a Security Antipattern

By AI · Philter · Redaction

In the rush to adopt AI and modern data processing, many organizations have fallen into a convenient but dangerous trap: "Privacy-as-a-Service" APIs. It sounds simple — you send your raw text to a third-party provider, they redact the sensitive bits, and send it back.

But there is a fundamental flaw in this logic. To protect your PII (Personally Identifiable Information), you are starting the process by handing that PII over to someone else.

In cybersecurity, we call this an antipattern — a solution that looks good on paper but creates more problems than it solves. Here is why the API-based approach to privacy is a massive security hole, and why true data sovereignty requires a local solution.

The "Security Hole" in Your Perimeter

When you use an external API for redaction, you are essentially punching a hole in your firewall. You spend millions of dollars securing your internal perimeter, only to create a pipeline that streams your most sensitive data — patient records, Social Security numbers, financial transactions — straight to a third-party vendor.

1. The Data Residency Nightmare

The moment your data leaves your infrastructure, you lose control. Where is it being processed? Is it being stored in a temporary cache? Is it being used to train the vendor's next AI model?

Under regulations like GDPR and HIPAA, data residency isn't a suggestion — it's the law. Moving data across borders or into unauthorized cloud environments, even for a split second, can result in massive compliance violations and seven-figure fines.

2. Third-Party Exposure: Inheriting Someone Else's Risk

When you rely on an external API, your security is only as good as the vendor's security. If they suffer a breach, your sensitive data is exposed. You aren't just managing your own risk anymore — you're inheriting the risk of every engineer, administrator, and sub-processor working for that vendor.

In a zero-trust world, the goal is to minimize blind trust. Relying on an external API is the ultimate act of blind trust.

3. The "Training" Trap

Many SaaS providers include clauses in their terms of service that allow them to use anonymized or "de-identified" data to improve their models. The problem? PII discovery isn't perfect. If the provider's API misses a name or a unique identifier and then uses that text to train their next LLM, your data is now part of a permanent, public-facing model. Once data is absorbed into a model's training set, it is virtually impossible to delete.

Getting Started with Philter

Because Philter is built for data sovereignty, you don't "sign up" for an account — you launch an instance. The software is open source and self-managed, so you maintain 100% control from day one.

The 3-step launch

  1. Choose your environment. Philter is available as a container image that runs anywhere Docker or Kubernetes is supported. For a streamlined experience, launch it directly from the AWS, Google Cloud, or Azure marketplaces.
  2. Define your policy. Philter uses JSON-based policies to tell the engine what to find (names, SSNs, credit card numbers, custom identifiers) and how to handle each (redact, encrypt, anonymize, mask). If you'd rather not write JSON, the Redaction Policy Editor gives you a visual interface that exports valid Philter policies.
  3. Integrate via API. Once the container is running, Philter exposes a REST API. You send text or documents to the /api/filter endpoint and Philter returns the sanitized version in milliseconds — running entirely within your own network.

Sample Network Configuration: The Zero-Trust Perimeter

To achieve a true zero-trust or air-gapped architecture, deploy Philter in a private subnet with no direct route to the public internet.

In this configuration, your data stays within your secure boundary. Your application servers talk to Philter over a local, private network. Because Philter contains all its NLP models locally, it never needs to "call home" to verify a license or download a model update.

Network diagram tip: place your Philter container in a private subnet with no Internet Gateway (IGW). Use a NAT Gateway only if you need to pull initial container updates — or better yet, use an internal private registry to keep the environment 100% isolated.

What about LLM traffic?

The same antipattern applies to generative AI: every prompt sent to a hosted LLM provider is data leaving your perimeter. If your team is already calling OpenAI, Anthropic, or AWS Bedrock from production, the Philter AI Proxy applies the same self-hosted philosophy to that traffic. It sits between your application and the model provider, redacting PII from prompts before they ever leave your network — and scanning responses on the way back. Your existing SDK code keeps working; you change one URL.

The bottom line

Privacy shouldn't require a compromise. Sending your data to a third party to "clean" it is like giving a stranger your house keys so they can make sure the back door is locked.

True privacy is built on the principle of containment. By self-hosting your redaction engine, you eliminate the risks of third-party exposure and ensure that your data remains where it belongs: under your control.

Is your data leaking through your redaction API? Restore your perimeter with Philter.