Trust Center
Gatekeeper Trust Center
One place for a security reviewer to find everything they need: our trust and security posture, compliance approach, subprocessors, and live evidence. Every document here is grounded in the product's code and marked honestly as implemented today or planned — no invented compliance statuses, no benchmark numbers.
Looking for third-party vendors? See the public-source vendor registry — neutral, sourced facts only; no scores or compliance judgments.
FAQ
Questions security and compliance teams ask.
Keep your guardrails — they're good controls. But guardrails enforce; Gatekeeper proves. A security review doesn't ask whether you filter — it asks for evidence of what happened on every call: per-call audit records mapped to SOC 2 and HIPAA controls, policy and pipeline version lineage, and an exportable packet a reviewer reads in minutes. And two things guardrails can't give you by design: visibility into traffic that never invoked them — Gatekeeper flags untagged PHI calls as UNGOVERNED_CALL instead of letting them pass silently — and independence, because evidence produced by the same platform that runs your workload is the platform grading its own homework. Guardrails are a control. Gatekeeper is the evidence of control.
No product does — and you should be skeptical of any that claims to. HIPAA compliance is a program: policies, training, BAAs, risk analysis, and technical safeguards together. What Gatekeeper provides is the technical evidence layer for one hard part of it: every AI call through the gateway produces an audit record mapped to specific controls — HIPAA 164.312(b) and SOC 2 CC6.1, CC6.3, CC6.8 — showing what was detected, what was redacted, what was blocked, and under which policy version. When your auditor or a customer's security review asks "prove what happens to PHI in your AI features," these records are the answer you hand them. Gatekeeper is evidence for your audit, not a substitute for your compliance program.
No detector catches everything — and a vendor claiming 100% detection is telling you about their marketing, not their system. Gatekeeper is designed on the assumption that misses exist, and makes them bounded and visible instead of silent. Deterministic where possible: fields you configure — your MRN formats, member-ID schemas, known identifiers — are redacted by rule, not probability. Probabilistic detection, honestly measured: for identifiers in free text, we measure the hard way — strict span-level recall and precision, per entity type, on adversarial corpora — with per-entity floors locked in CI so performance can't silently regress. Misses are auditable, not invisible: every call is logged with its policy and pipeline lineage, so you can always identify which traffic was processed by which detector version. And untagged traffic is flagged loudly as UNGOVERNED_CALL, never silently passed. We'd rather show you how we measure than promise you a number that can't be true.
Good — many strong teams have. But when a hospital's security review examines it, the questions won't be "do you scrub PHI?" They'll be: what's its measured recall, and on what test set? Which detector version processed which historical calls? Can you export per-call evidence of what it did? In-house scrubbers almost always fail those three — not because the detection is bad, but because nobody built the measurement and evidence machinery around it. That machinery is most of what Gatekeeper is. Detection without evidence doesn't pass review; evidence is what we sell.
Yes. Our sample evidence packet (/sample-packet) is generated live by the deployed Gatekeeper pipeline using clearly-labeled synthetic data — the records are real rows the gateway persisted; only the data is fictional. It shows the three outcomes of a call: a governed call with detected entities redacted, a governed call blocked for prompt injection (with its block reason), and an untagged call loudly flagged as UNGOVERNED_CALL. We never use real patient or hospital data for demos or benchmarks — synthetic only, by policy.
Evidence
Sample evidence packet
Both surfaces are public, unauthenticated, and generated live by the deployed pipeline from clearly-labeled synthetic data — the records are real rows the gateway persisted; only the data is fictional.
Documentation
Reviewer documentation
The pre-answer pack a reviewer can read before requesting a call. Each opens as a Markdown document.
Pre-answered healthcare vendor-security questions across PHI handling, security controls, compliance, incident response, and subprocessors — each row labeled REAL or ROADMAP with repository evidence.
One-page reviewer summary of the real data flow, data lifecycle, deployment models, subprocessors, and failure behavior, with every claim traced to current code or configuration.
One-page reviewer guide to the audit fields, decision values, and compliance-control statuses shown in the evidence packet.
Maps the evidence packet's record fields and control statuses against HSCC Appendix E/F contract asks, the five areas of the Joint Commission's RUAIH program, HIPAA §164.312(b) / SOC 2 controls, and an ONC/ASTP HTI-1 stretch reference — documenting where the packet answers, partially answers, or doesn't address each ask.
Pilot-tier pack
Pilot tier: architecture, pen-test scope, and auditor engagement
The reviewable package for the no-PHI pilot tier. Everything here distinguishes planned from completed work: the pilot runs on synthetic / non-PHI data only, the pen test is scoped but not performed, and the auditor engagement letter is available to reviewers on request.
Defines the pilot boundary: synthetic / non-PHI data only, the real request pipeline, trust boundaries, and — honestly — what the pilot does not establish. Grounded in the architecture brief.
Scoping document for a future penetration test: intended targets, boundaries, objectives, and expected deliverables. Status is Proposed / Planning — no test has been performed and no provider engaged.
The auditor engagement letter is available to reviewers on request. No audit has been completed — this slot exists so the letter can be displayed here the moment it is cleared for publication.
Subprocessors
Subprocessors & data flows
There is no formal subprocessor register or DPA yet (pending founder decision). The table below reconstructs each provider's purpose and the data it receives strictly from documented technical data flows. Providers do not all receive the same data.
| Provider | Purpose | Data received |
|---|---|---|
| OpenAI | Model provider for the /proxy/openai route, and the internal jailbreak judge / block explainer (gpt-4o-mini). | Redacted text on the proxy forward (the customer's key is passed through in memory, never stored). On the judge / explainer path, a raw pre-redaction prompt snippet using Gatekeeper's own key. The stored original_text audit column is never shared. |
| Anthropic | Model provider for the /proxy/anthropic route. | Redacted text only, with the customer's key passed through in memory. Not used for detection, the judge, or the explainer, and never receives raw original_text. |
| Neon (PostgreSQL) | Managed PostgreSQL for the audit trail. | Audit rows (including raw text) and governance metadata. Customer provider API keys are never stored. |
| Railway | Application hosting / compute for the Gatekeeper service; terminates TLS. | Request text passes through compute transiently in memory during processing; durable storage is the database, not the Railway app process. |
| Vercel | Hosting for the marketing site, dashboard, live sample-evidence packet, and public demo; terminates TLS. | Demo text a visitor submits through the public demo route, which forwards to the backend. The production audit database does not live on Vercel; demos use synthetic data by policy. |
On text sent to model providers: the stored original_text audit column is never sent to a model provider or any other subprocessor, and on the proxy path only cleaned / redacted text is forwarded to OpenAI and Anthropic. One honest nuance: raw pre-redaction prompt text currently reaches OpenAI on the internal jailbreak-judge path — redacting the judge's input is a roadmap item, not shipped behavior.
Honesty box
What's real today, and what's on the roadmap
We describe unfinished work as unfinished. Nothing below represents formal compliance status. The per-call compliance mapping is evidence, not proof of formal compliance status — it does not make Gatekeeper or a customer SOC-2 certified, and it does not by itself make an application HIPAA compliant.
- Transparent proxy for OpenAI and Anthropic, with PII/PHI redaction before the provider call on the proxy path.
- Jailbreak / prompt-injection detection, plus SOC-2 and HIPAA policy packs (redact / block / warn).
- One audit-log row written to Postgres for every request, with per-call SOC-2 / HIPAA control mapping.
- Untagged calls flagged loudly as UNGOVERNED_CALL instead of passing silently.
- Append-only audit trail; Slack alerts carry metadata only, never prompt content.
- Judge fail-open on provider outage, with the fallback recorded as an exception event.
- Encryption in transit (HTTPS/TLS) everywhere; Slack webhook URLs encrypted at rest.
- Judge-input redaction — the internal jailbreak judge currently receives raw, pre-redaction text.
- Configurable retention window / purge for stored audit text (retained indefinitely today).
- Option to disable raw-text storage (STORE_ORIGINAL_TEXT).
- At-rest encryption of the audit text columns, RBAC for audit access, a fail-closed mode, and cryptographic audit immutability.
- SOC 2 Type I & II engagement in process with Johanson Group LLP.
- A Business Associate Agreement (BAA), DPA, and formal subprocessor register (pending founder decision).