Gatekeeper
Try it for free
Read the report

No-PHI Pilot Architecture — One-Pager

Purpose. A one-page, reviewer-oriented description of the Gatekeeper pilot tier: what the pilot demonstrates, what data is allowed inside it, and what it does and does not prove. It is consistent with, and defers to, the Architecture Brief, which traces every technical claim to current code. This document claims no formal compliance status and invents no control. Statuses use the same labels: REAL / CURRENT (implemented) or ROADMAP / PROPOSED (designed, not shipped).

1. Pilot Purpose

The pilot demonstrates governed AI calls with per-call evidence, using no-PHI data only. A pilot participant routes AI requests through the Gatekeeper gateway and receives, for every call: PII/PHI-pattern redaction before the provider forward, jailbreak/prompt-injection screening, policy enforcement (SOC-2 / HIPAA policy packs), and one audit row mapped to specific controls — exportable as an evidence packet.

The pilot exists to show how the evidence layer behaves, not to process real patient data.

The pilot tier has two distinct components, and they are not the same workflow: the gap-check engagement (§2) — a documentation-and-evidence review with zero PHI custody — and the optional product demonstration on synthetic data (§3–§6). Neither is a production PHI processing workflow.

2. The Gap-Check Engagement Model — Zero PHI Custody

A pilot engagement is delivered as a gap check: a documentation and evidence review, not a production deployment and not a PHI processing workflow. The engagement maps a participant's AI change-related contract clauses against observed change events and available evidence, and produces a findings report.

Zero PHI custody. The engagement operates with zero PHI custody: customer PHI is not requested, not transferred, not stored, not processed, and not retained as any part of the engagement.

Allowed inputs — only these:

  • Redacted contractual clauses (identifying and sensitive details removed by the participant before sharing)
  • Public documentation
  • Public changelogs
  • Publicly available evidence

TPRM positioning. The engagement is designed for organizations that want to complete an initial trust / TPRM questionnaire-only review without transferring PHI — the reviewable materials on this Trust Center plus the gap-check report are the deliverables; no data connection to the participant's systems is required or requested.

Relationship to the product. The gap-check engagement and the Gatekeeper gateway are distinct. The engagement reviews documents and public evidence; the gateway (described from §3 onward) processes live requests. A participant who additionally wants to see the gateway itself in action does so under the separate demonstration boundary below — synthetic / non-PHI data only.

3. Data Boundary — Why the Pilot Is No-PHI

Allowed in the pilot:

  • Synthetic data (the same class of data used for the public demo and sample evidence packet — "synthetic only, by policy" is the existing, stated demo policy)
  • Test / non-production data
  • De-identified data containing no real identifiers

Not allowed in the pilot:

  • PHI or any real patient data
  • Real production data containing personal identifiers
  • Real credentials, API keys, or secrets embedded in prompt text

The honest reasons this boundary exists (all REAL / CURRENT, verified in the Architecture Brief):

  1. Raw request text is stored indefinitely. Every request's pre-redaction original_text is persisted to the audit database with no retention mechanism, TTL, or purge job, and no flag to disable storage. Retention controls are ROADMAP.
  2. One raw-text egress path exists today. The internal jailbreak judge and block explainer receive raw, pre-redaction text snippets (sent to OpenAI). Judge-input redaction is ROADMAP, not shipped.
  3. Detection fails open. If the judge is unavailable, requests proceed rather than block. A fail-closed mode is ROADMAP.
  4. No BAA is available. There is no Business Associate Agreement, DPA, or formal subprocessor register; the BAA stance is an open founder/legal decision.

Because of these documented facts, the pilot must not receive PHI. No claim is made that the system can safely process PHI, and no HIPAA compliance or formal compliance status is claimed.

4. System Flow (actual pipeline)

Pilot participant application
        │  (chat messages + governance headers: X-Gatekeeper-Key,
        │   X-Workflow-Tag, X-Actor-ID + participant's provider key)
        ▼
Gatekeeper proxy  (/proxy/openai · /proxy/anthropic)
        ▼
Jailbreak / prompt-injection detection   ← judge sees RAW text (known gap)
        ▼
PII/PHI detection and redaction  →  [REDACTED_TYPE] placeholders
        ▼
Policy enforcement  (soc2 / hipaa policy packs)
        ▼
Upstream model provider  (OpenAI / Anthropic — redacted text only,
                          participant key passed through in memory)
        ▼
Audit row per call  →  PostgreSQL audit_logs  →  evidence packet export

This is the real, current pipeline order (jailbreak check runs before redaction). No components beyond these exist in the pilot path.

5. Trust Boundaries

  • Inside the pilot boundary: the Gatekeeper proxy and detection pipeline, the policy/governance layer, and the audit database (hosted model: Gatekeeper-managed PostgreSQL on Neon, compute on Railway).
  • Outside the pilot boundary: the participant's own application and users; upstream model providers (OpenAI / Anthropic), which receive redacted text on the proxy forward — plus raw snippets on the judge/explainer path (see §3); Slack (metadata-only block alerts, never prompt content).
  • Where data enters: the proxy endpoints, authenticated per-app via X-Gatekeeper-Key.
  • Where data is processed: in the fixed-order pipeline above, transiently in memory on gateway compute.
  • Where evidence is generated: one audit_logs row per call; evidence exports emit entity-type counts, never raw text.

6. Data Handling in the Pilot

  • Do not submit: PHI, real patient or production data, real secrets (see §3).
  • What is stored: per-call audit rows including raw original_text and redacted cleaned_text, retained indefinitely today (no retention window exists — this is exactly why pilot data must be synthetic or non-sensitive).
  • Synthetic vs production: all pilot, demo, and benchmark traffic uses synthetic or non-production data by policy; the public sample evidence packet is generated from clearly-labeled synthetic data.
  • No deletion guarantee or retention period is claimed, because none is implemented.

7. What the Pilot Does NOT Establish

The pilot is:

  • Not a formal compliance attestation (no HIPAA, SOC 2, or other formal compliance status is claimed; SOC 2 Type I & II engagement in process, not complete)
  • Not a compliance determination for Gatekeeper or any participant
  • Not a production security assessment — see the Pen-Test Scope, which is proposed, not performed
  • Not an independent audit — see the auditor engagement slot on the Trust Center, which is pending publication
  • Not evidence of regulatory approval
  • Not evidence that the system can safely process PHI

The pilot demonstrates the evidence-generation behavior of the gateway on non-PHI data. Nothing more is claimed.