Architecture and threat model
Philterd is self-hosted software. Every product in the toolkit runs inside your own environment, whether that is your cloud, your own servers, an air-gapped network, or a single Windows computer running Philter Desktop . 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
Run the software and your data does not leave your environment:
- Redaction processing runs in your VPC, on-premises environment, air-gapped cluster, or on a single desktop computer.
- No telemetry, usage metrics, or processed content is transmitted to Philterd or any third party.
- Philterd products do not phone home.
Consulting engagements are the exception to the above, because people rather than software are doing the work. Most of an engagement runs inside your own environment, and where a piece of work does not, the engagement contract says so before it starts. See consulting engagements below.
Model training
The models Philterd ships are trained entirely on synthetic and publicly available datasets. No customer data is used to train, benchmark, or evaluate a released Philterd model, at any stage.
Custom detection models built during a consulting engagement are the deliberate exception. A model built for you is for your exclusive use, and that work never feeds back into a model Philterd ships to anyone else. Where that training runs and what data it uses vary by engagement, and both are set out in the engagement contract before any work begins.
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:
- Email security@philterd.ai with a description of the issue, the affected component and version, and reproduction steps.
- We will acknowledge receipt within two business days.
- We will provide a remediation timeline within five business days.
- 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 packages page lists the current published 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.
Business Associate Agreements
Philterd does not need a BAA with you, and that is the point. For the full reasoning from first principles, see the guide Why Philterd doesn’t need to 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.
What this means for your own BAA 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, and deployment review that does not require Philterd staff to see real records. When an engagement includes the implementation step, that work happens inside your own environment, so the data still does not come to us. 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 .