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.

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.

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.

ProviderPurposeData received
OpenAIModel 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.
AnthropicModel 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.
RailwayApplication 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.
VercelHosting 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.

Real — implemented today
  • 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.
Roadmap — planned, not yet implemented
  • 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).