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. 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
Check it yourself
Everything a reviewer needs to check our claims, in one place: the build that is running, real records from it, the API that exports them, and the map from record fields to review questions. The records use synthetic data only.
The public /version endpoint names the exact commit production is running (build_sha) and where that name comes from (build_sha_source).
(opens in a new tab)Real audit records written by the deployed pipeline from synthetic data, regenerated each time the page loads.
The same packet as a PDF, for attaching to a security review.
The reference for every endpoint, generated by the running service itself.
(opens in a new tab)POST /api/v1/evidence/export returns a tenant's own records as one JSON packet. It needs that tenant's key and does not return request text.
(opens in a new tab)Maps each record field to what reviewers ask, and marks where the record answers, partly answers, or does not answer.
(opens in a new tab)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.
Founding Engagement pack
Founding Engagement: architecture, pen-test scope, and auditor engagement
The reviewable package for the Founding Engagement. Everything here distinguishes planned from completed work: the engagement 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 no-PHI boundary: synthetic / non-PHI data only, the real request pipeline, trust boundaries, and, honestly, what it 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
Every outside service the product uses, what it is for, and what it receives, as of production build 6929f04. Providers do not all receive the same data. This is our own list; there is no DPA yet.
| Provider | Purpose | Data received |
|---|---|---|
| Railway | Hosts the Gatekeeper API. | Request text is held in memory while a call is processed. The service's configuration, including its keys, is stored with Railway. |
| Neon (PostgreSQL) | Stores the audit records and tenant settings. | One record per screened call. Today that record includes the request text and, except on proxy calls that were blocked, the cleaned text (see Retention). Customers' own model provider keys are not stored. |
| OpenAI | Receives calls on the /proxy/openai route, and runs Gatekeeper's jailbreak check for traffic outside the HIPAA policy. | On /proxy/openai, the cleaned request, sent with the customer's own key, which is not stored. For traffic outside the HIPAA policy, a prompt the local checks find ambiguous is sent unredacted, with Gatekeeper's own key, for a jailbreak verdict. Under the HIPAA policy that call is not made. |
| Anthropic | Receives calls on the /proxy/anthropic route. | The cleaned request, sent with the customer's own key, which is not stored. Gatekeeper makes no Anthropic call of its own. |
| Vercel | Hosts this website, the dashboard, the sample packet, and the public demo. | Text a visitor types into the public demo passes through on its way to the Gatekeeper API. |
| Upstash (Redis) | Rate limits the public demo and the sample packet. | Request counters, some keyed by the visitor's IP address and some shared by all visitors. No request text. |
| Stripe | Billing for paid plans. | Billing details for customers who buy a plan. No request text and no audit records. |
| AIDepShield threat feed | Supplies the list of known-bad indicators the threat check uses. | Nothing. Gatekeeper only downloads the list. |
| Slack | Block alerts, only for a customer who sets up its own Slack webhook. | The app name, the time, the detected entity types, and the block reason. For a jailbreak verdict from the model check, that reason is the model's own one-sentence explanation, which can quote the prompt. |
On text sent to model providers: the stored audit record is never sent to a model provider. On the proxy routes only the cleaned request is forwarded. The one exception is the jailbreak check described in the OpenAI row; redacting its input is planned, not shipped.
Retention
What we keep, and for how long
Today, on production build 6929f04
- Every screened call writes one audit record: the decision, the detected entity types and counts, the policy and build, and the time. A call refused before screening (a missing key or governance header, a malformed request, or a rate limit) writes nothing.
- The record also keeps the request text as received and, except on proxy calls that were blocked, the cleaned text.
- Nothing is deleted automatically, and there is not yet a setting to stop storing the request text.
Tested on staging, not yet on production
- Stop storing the request text.
- Delete the cleaned text 30 days after it is written, for records written after the change goes live.
- Keep the rest of each record for six years; records with exception events are kept longer.
This page will say when it is live, with the build it shipped in.
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 (block, redact, log, throttle).
- One audit-log row written to Postgres for every screened request, with per-call SOC-2 / HIPAA control mapping.
- Untagged calls are refused on the proxy routes and flagged as UNGOVERNED_CALL on /scan, instead of passing silently.
- Exception events are append-only in our code (the database has no tamper evidence yet); Slack alerts carry no request text, apart from what a jailbreak verdict's one-sentence reason may quote (see Subprocessors).
- HTTPS on every public endpoint; Slack webhook URLs encrypted at rest.
- Judge-input redaction — the internal jailbreak judge currently receives raw, pre-redaction text.
- Stop storing the request text and delete the cleaned text after 30 days (tested on staging, not yet on production; see Retention). Today it is kept indefinitely.
- Block the call whenever the jailbreak check cannot be reached, on every workflow. Today a call outside the HIPAA policy passes in that case, with the fallback recorded as an exception event.
- At-rest encryption of the audit text columns, RBAC for audit access, and cryptographic audit immutability.
- SOC 2 Type I & II engagement in process with Johanson Group LLP.
- A Business Associate Agreement (BAA) and a DPA (pending founder decision).