Philterd

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.

Security & Trust

How Philterd is built, how vulnerabilities are disclosed, and where your data lives (it stays with you).

Architecture and threat model

Philterd is self-hosted software. Every product in the toolkit (Philter, Phileas, PhEye, Philter AI Proxy, Phinder, Phield, Arbiter) runs inside your own infrastructure. There is no Philterd cloud, no SaaS endpoint, and no outbound connection back to Philterd servers at runtime.

The consequence for your threat model is direct: Philterd has no access to your data. There is nothing for Philterd to disclose, breach, or mishandle because the data never reaches us. Your PII stays inside the perimeter you control.

Where customer data lives

Customer data does not leave your environment:

  • Redaction processing runs in your VPC, on-premises environment, or air-gapped cluster.
  • No telemetry, usage metrics, or processed content is transmitted to Philterd or any third party.
  • Philterd products do not phone home.

Model training

Our NLP models are trained entirely on synthetic and publicly available datasets. No customer data is used in model training, benchmarking, or evaluation, at any stage.

Audit trail and evidence

Self-hosting keeps your data private. It also has to produce proof. Philter records every redaction request to an audit log inside your own datastore: the time, the API key that made the call, the client IP, the policy applied, and the number of entities redacted. Nothing in that record leaves your environment, and Philterd never sees it.

The log is built for compliance evidence, not just debugging:

  • Tamper-evident. Redaction records are written to a ledger whose entries are hash-chained with SHA-256, so any later modification is detectable.
  • Queryable. Retrieve the redaction history for a date range without grepping application logs.
  • Exportable. Export the audit log to CSV directly from the API, so handing an auditor a record of what was redacted and when is a single call, not an engineering project.
  • Per-document detail. Philter’s explain endpoint returns the exact spans it acted on for any document (character position, entity type, confidence, and replacement), so you can show not just that redaction happened but precisely what it did.

The result is a verifiable chain of custody for the sensitive data flowing through your pipeline, held entirely inside the perimeter you control.

Open source auditability

Every Philterd product is released under the Apache 2.0 license. The full source code is publicly available on GitHub. Security-conscious teams can:

  • Read the redaction and detection code directly before deploying.
  • Build from source rather than using published Docker images.
  • Run the test suite against their own inputs.
  • Fork and modify under the terms of the license.

Transparency is the baseline. If something looks wrong in the code, open an issue or a pull request.

Vulnerability disclosure

Philterd follows a responsible-disclosure model. If you discover a security vulnerability in any Philterd product, please report it privately before public disclosure.

To report a vulnerability:

  1. Email security@philterd.ai with a description of the issue, the affected component and version, and reproduction steps.
  2. We will acknowledge receipt within two business days.
  3. We will provide a remediation timeline within five business days.
  4. We coordinate a public disclosure date with the reporter after a patch is available.

Please do not open public GitHub issues for security vulnerabilities until a patch has been released and we have agreed on a disclosure date.

Supported versions and patch policy

Security fixes are applied to the current stable release series of each product. The prior major release series receives critical security patches for 90 days after a new major version ships. Older releases are unsupported.

The releases page lists the current stable version of each product.

Supply chain security

  • Dependency scanning: Dependencies are scanned for known vulnerabilities in CI on every commit.
  • Signed releases: Docker images and release artifacts are signed. Verification instructions are published in each repository.
  • SBOM availability: Software Bill of Materials files in CycloneDX format are available on request for enterprise customers evaluating supply-chain risk.
  • Reproducible builds: Build configurations are published in each repository so teams can reproduce release artifacts from source.

Sub-processors

Philterd has no sub-processors. Because all products are self-hosted, no customer data is processed by Philterd or any third-party service on Philterd’s behalf.

Data Processing Agreements and Business Associate Agreements

Philterd does not need a BAA or a DPA with you, and that is the point. For the full reasoning from first principles, see the guide Why Philterd doesn’t sign a BAA.

Why no BAA is needed

A HIPAA Business Associate Agreement is between a covered entity and a business associate, defined under 45 CFR § 160.103 as a vendor that creates, receives, maintains, or transmits protected health information on the covered entity’s behalf. Philterd ships software that runs entirely inside your infrastructure. Customer PHI never reaches Philterd, is never processed by Philterd, and is never accessible to Philterd at runtime. Philterd is therefore not a business associate, so there is no BAA to sign.

This is not a workaround or a paperwork shortcut. It is a direct consequence of the architecture: software you self-host cannot create a business-associate relationship with the software vendor.

Why no DPA is needed

GDPR Article 28 governs the controller-processor relationship. A data processor is an organization that processes personal data on behalf of a controller. The same architecture argument applies: Philterd does not process personal data on your behalf, because Philterd does not process your personal data at all. You are both controller and processor; Philterd is a software vendor sitting outside that boundary.

What this means for your own BAA and DPA chain

Your obligations with downstream vendors (your cloud provider, any SaaS service you send redacted output to) are unaffected by this. In fact, Philter is often the tool that makes those downstream relationships cleaner: HIPAA Safe Harbor de-identification before data leaves your perimeter can take a whole class of vendor BAAs off the table because the data is no longer PHI by the time it gets there.

The one edge case: consulting engagements

Consulting engagements where Philterd staff would touch real PHI in your environment are a different situation, governed by the engagement contract rather than a standing BAA. In practice, most engagements are scoped to work on synthetic data, policy design, deployment review, and model training that does not require Philterd staff to see real records. When that scoping is not possible, the engagement contract spells out how PHI is handled inside the engagement.

Compliance

For a full mapping of Philterd products to specific regulatory frameworks (HIPAA Safe Harbor, GDPR, PCI DSS, GLBA, FERPA, FedRAMP, and others), see the Compliance Matrix.