This guide is a technical control mapping, not legal advice or a compliance opinion. SOC 2 and HIPAA obligations depend on your specific environment and scope. Work with your compliance officer, security team, and auditor to confirm how these controls apply to your program.
Prospects in regulated industries ask the same question once the Philter AI Proxy clears the technical evaluation: which of our SOC 2 and HIPAA controls does this help us satisfy, and what do we have to configure to claim it? This guide answers both. It maps the proxy’s features to the SOC 2 Trust Services Criteria and the HIPAA Security Rule safeguards, explains how the architecture affects your Business Associate Agreement chain, and lists the configuration steps that turn each mapped capability on.
The proxy is one control among many in your environment. It does not make you compliant on its own, and it does not cover the administrative and physical safeguards that are your responsibility as the operator. What it does is give your LLM traffic a defensible, auditable privacy layer, and produce the evidence reviewers expect for AI workloads.
The architecture changes the control story
Most LLM privacy questions start from the assumption that prompts reach the model provider and you have to govern that. The proxy inverts it. It sits between your application and providers like OpenAI, Anthropic, Amazon Bedrock, and Google Gemini, redacts PII and PHI from each prompt before it crosses your network boundary, and optionally scans responses on the way back. Sensitive data never leaves your perimeter.
That single fact does a lot of work in an audit. Data that is redacted before egress is not confidential data being transmitted to a third party, which simplifies your boundary-protection and transmission-security story. PHI that never reaches the LLM provider keeps that provider off your Business Associate Agreement chain. The proxy is self-hosted, so the vendor (Philterd) never touches your data and is not a business associate or a sub-processor. The controls below build on that foundation.
SOC 2 Trust Services Criteria
The mapping below covers the Common Criteria plus the Confidentiality, Availability, and Processing Integrity categories. Use it as a starting point for your own control matrix; your auditor will map to the specific criteria in scope for your report.
| Trust Services Criteria | What it calls for | Proxy capability |
|---|---|---|
| CC6.1 Logical access security | Restrict access to systems and protect data with encryption | API-key authentication (keys hashed at load with SHA256 or bcrypt, verified in constant time, never held as plaintext), mutual TLS, and a TLS listener |
| CC6.3 Least-privilege authorization | Authorize access based on roles and need | Per-key authorization scopes (deny-by-default allow-lists for providers, models, and paths), per-key policy binding, and a scoped usage-read admin role |
| CC6.6 Boundary protection | Protect against threats from outside the system boundary | TLS to every provider with certificate verification (tlsVerify), request hardening (body and header size caps, slowloris read and handshake timeouts), and concurrency ceilings |
| CC6.7 Transmission and movement of data | Restrict and protect data in transit | Inbound prompt redaction before egress, opt-in outbound response scanning, TLS on every hop, and stripping of the proxy auth header before forwarding so providers never see it |
| CC7.1 / CC7.2 Monitoring and detection | Detect, log, and respond to anomalies | Structured JSONL audit log, a Prometheus /metrics endpoint, OpenTelemetry tracing, and /livez and /readyz probes |
| A1.1 / A1.2 Availability | Manage capacity and maintain resilience | Per-client and global rate limits, per-key token quotas, a Philter circuit breaker with configurable fallback, health probes, and Helm support for autoscaling and Pod Disruption Budgets |
| C1.1 / C1.2 Confidentiality | Identify, protect, and dispose of confidential information | Policy-driven redaction of confidential data before egress; an audit log that records metadata only and never message content; no persistence of prompt or response content by default |
| PI1.x Processing integrity | Process data completely, accurately, and only as authorized | Deterministic, policy-driven redaction; outbound block and flag enforcement when PII is detected in a response; first-match routing to the correct policy per request |
HIPAA Security Rule safeguards
This maps the proxy to the technical safeguards of the HIPAA Security Rule (45 CFR Part 164, Subpart C), with the two administrative safeguards it most directly supports. The administrative and physical safeguards as a whole remain your responsibility as the covered entity or business associate operating the proxy.
| Safeguard (45 CFR) | Requirement | Proxy capability |
|---|---|---|
| 164.312(a)(1), (a)(2)(i) Access control, unique user identification | Allow access only to authorized users, each uniquely identified | A unique API key per client or team, optional mutual TLS, and per-key authorization scopes |
| 164.312(b) Audit controls | Record and examine activity in systems that handle ePHI | Structured JSONL audit log capturing provider, model, redacted entity types, counts, direction, latency, client IP, document ID, HTTP status, and trace ID |
| 164.312(c)(1) Integrity | Protect ePHI from improper alteration or destruction | Outbound response scanning with block or flag, and a deterministic redaction policy |
| 164.312(d) Person or entity authentication | Verify that a person or entity seeking access is who they claim | API-key authentication and mutual TLS, independently or together |
| 164.312(e)(1), (e)(2)(ii) Transmission security and encryption | Guard ePHI in transit and encrypt it where appropriate | TLS on the listener and to Philter and every provider, mutual TLS, and certificate verification |
| 164.308(a)(1)(ii)(B) Risk management | Reduce risks and vulnerabilities to a reasonable level | Redacting PHI before it reaches the LLM provider removes an entire category of exposure and shrinks the downstream BAA chain |
| 164.308(a)(4) Information access management | Authorize access to ePHI appropriately | Per-key authorization scopes and per-key policy binding (for example, a healthcare team’s key locked to a HIPAA Safe Harbor policy) |
HIPAA BAA readiness
“BAA readiness” here means readiness for your program, not a signature from Philterd. Philterd does not sign a Business Associate Agreement, because self-hosted software creates no business-associate relationship to govern: the vendor never creates, receives, maintains, or transmits your PHI. The full reasoning, from the regulatory definitions up, is in Why Philterd Doesn’t Sign a BAA. Point your compliance team there when procurement raises the question.
What the proxy gives your HIPAA program is concrete and verifiable:
- PHI handling. The proxy redacts PHI from prompts before they leave your network, according to your Philter policy. When you route healthcare traffic through a HIPAA Safe Harbor policy and enable outbound scanning, PHI does not reach the LLM provider in either direction.
- Content non-retention. The proxy does not persist prompt or response content. The audit log records metadata only (entity types and counts, never the text itself). The optional response cache is off by default; if you enable it, it holds responses in memory or Redis for its configured TTL, so leave it off on PHI routes or scope it deliberately.
- Encryption in transit. TLS protects every hop: client to proxy, proxy to Philter, and proxy to provider. Mutual TLS adds verified client identity for zero-trust service-to-service deployments.
- A shorter BAA chain. Because de-identified data is no longer PHI, redacting at the edge can take downstream LLM providers off your BAA chain entirely. See Automating HIPAA Safe Harbor for that pattern.
Configuring the proxy to support your attestations
The proxy ships with authentication, rate limiting, quotas, and outbound scanning disabled by default so it runs out of the box. For a SOC 2 or HIPAA posture you enable them deliberately. The authoritative reference for every key is the proxy’s Configuration documentation; this checklist points at the relevant sections.
- Require authentication. Enable API-key authentication with one key per client or team, and pre-hash the keys so plaintext never appears in your config, source control, or images. For zero-trust service-to-service traffic, set
listen.clientCAto require and verify client certificates (mutual TLS). The two combine. - Apply least privilege. Use per-key scopes to restrict each key to the providers, models, and paths it needs, and bind keys that handle PHI to your HIPAA policy so the policy cannot be overridden by the client.
- Encrypt every hop. Configure the TLS listener, keep
tlsVerify: trueto Philter and to each provider, and supply an internal CA where you use private certificates. - Turn on outbound scanning for PHI routes. Set the route’s
outbound.actiontoblockso a response containing detected PII is rejected rather than returned. Inbound redaction alone does not catch PHI the model emits. - Capture the audit trail. Enable logging to a file, then ship the JSONL audit log to your SIEM and apply your standard retention. The log is metadata only, but client IPs may be personal data, so govern it accordingly.
- Protect availability. Enable per-client and global rate limits and per-key token quotas. For multi-replica deployments, back them with Redis so the limits are shared. Enable the Philter circuit breaker and wire
/livezand/readyzinto your probes. - Make it observable. Scrape the Prometheus
/metricsendpoint into your monitoring stack and, where your program calls for distributed tracing, enable OpenTelemetry.
What the proxy does not cover
Honest scoping matters in an audit. The proxy is a control for LLM traffic; it is not your whole compliance program. These remain your responsibility:
- Administrative and physical safeguards. Workforce training, sanction policies, contingency planning, facility access, and the rest of the HIPAA administrative and physical safeguards sit outside any single tool.
- The Philter instance and its host. The proxy depends on a running Philter instance. Encryption at rest, OS hardening, and patching of that host are covered in Deploying Philter in a HIPAA Environment.
- Your application and identity provider. Authentication of end users, session management, and access to your own application are upstream of the proxy.
- Your downstream systems. Anything you do with redacted output, and any system that still handles PHI elsewhere in your environment, is in your scope, not the proxy’s.
Used as part of a complete program, the proxy gives your LLM workloads a control set you can point an auditor at and evidence you can produce on demand. To work through how this maps to your specific environment, talk to the team.