Security-review evidence for health-tech AI on PHI
Pass your customer's security review. Ship your AI feature.
Gatekeeper routes OpenAI and Anthropic calls through policy checks, redacts detected sensitive fields before the provider call, and writes an audit record for every request through the proxy.
✓Runs as a proxy. Redaction happens before the provider call.
The artifact your reviewer actually asks for.
A scan result tells an engineer what happened. The audit log gives a reviewer the provider, model, policy pack, and what was redacted or blocked — the record they evaluate later.
Run a synthetic clinical prompt through the policy path.
See detected fields, the policy decision, the cleaned prompt, and the evidence record generated for the request.
Screens for high-risk prompt-injection and jailbreak patterns. Edit the text to change the decision.
// Run a scan to generate the evidence record.
Route the call, apply policy, return the evidence.
Route the request
Route OpenAI or Anthropic requests to Gatekeeper's /proxy/openai or /proxy/anthropic endpoint.
Apply policy before the provider call
Detect configured sensitive fields, screen high-risk injection patterns, and allow, redact, or block according to the active policy.
Return the response, record the log
Gatekeeper returns the provider response transparently and writes the audit record to Postgres — surfaced in your dashboard and exportable as audit evidence.
curl -sS -X POST https://gatekeeper-production-7dd1.up.railway.app/proxy/openai \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "X-Workflow-Tag: developer-playground" \
-H "X-Actor-ID: quickstart@example.com" \
-d '{
"model": "gpt-4o-mini",
"messages": [
{"role": "user", "content": "Draft a follow-up to patient John Doe, MRN 948201, email john.doe@example.com, about his lab results."}
],
"max_tokens": 200
}'// audit_logs row — written to Postgres,
// surfaced in the dashboard, exportable as audit evidence
{
"provider": "openai",
"model": "gpt-4o",
"pii_detected": [{"type": "email", "count": 1}],
"jailbreak_detected": false,
"blocked": false,
"policy_violations": [
{"rule": "no-pii-egress", "action": "redact"}
]
}POST your provider request to Gatekeeper's proxy route with the X-Workflow-Tag and X-Actor-ID governance headers. The provider response passes through transparently; the audit record is written to Postgres and surfaced in your dashboard.
Good provider terms do not answer your customer's review.
Your model provider can describe how it handles API data. Your customer still needs evidence of what your application sent, what your policy changed, which workflow made the call, and how the decision maps to its controls.
Policy packs
Start with best-practice guardrails. Customize everything.
Policy packs bundle detectors, thresholds, and evidence templates so security and platform teams can move fast without reinventing compliance.
SOC-2
Security + availability posture for AI systems
- Access controls for prompts, datasets, and model endpoints
- Tamper-evident audit logs for every decision
- Change management hooks for policy updates
HIPAA
PHI-aware scanning for healthcare workflows
- PII/PHI detection with redaction-first defaults
- Minimum-necessary enforcement for tool outputs
- Break-glass workflows with reviewer attestations
Why Gatekeeper
Model safety is not your company policy.
Provider filters are generic. Gatekeeper enforces your organization's rules: which data can leave your environment, which tools your agents can call, which environments are allowed, and exactly what evidence gets logged for your security team.
- Generic, one-size rules
- Runs model-side - outside your control
- No environment or tool awareness
- No audit evidence you own
- Your rules, as code - versioned and reviewable
- Enforced in front of the call, before data leaves
- Environment-, data-, and tool-aware decisions
- Exportable audit logs your security team owns
Integrations
Works seamlessly with your existing tools
Connect Gatekeeper to the platforms security-conscious teams already use - no heavy integration project required.
Workato
Route your Workato AI automations through Gatekeeper - no code required.
Built to be inspected, not just trusted.
SOC 2 Type I & II engagement in process with Johanson Group LLP.
Gatekeeper documents how a specific AI request was handled and maps that record to relevant control evidence. It does not make Gatekeeper or the customer SOC-2 certified, and it does not by itself make an application HIPAA compliant.
Pricing
One ladder. Two doors.
No tiers and no feature matrix — two ways to engage, on one ladder. Start with the fixed-fee sprint, or join the invitation-only pilot.
Sprint
The change-evidence audit: a fixed-fee engagement that names your AI change-notification gap and closes it.
Delivered as a documentation-and-evidence review — your AI change-related obligations mapped against observed change events and available evidence, ending in a findings report.
Pilot
Invitation-onlyThe no-PHI pilot: governed AI calls with per-call evidence, on synthetic / non-PHI data only.
Runs under the published pilot boundary — zero PHI custody, synthetic data only, every call producing an audit row you can export as evidence.
Not sure which door? Start with the free 15-minute gap check, or read the reviewer documentation in the Trust Center.
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.
Bring the security question your customer is asking.
Review the workflow, run a synthetic or approved test request through Gatekeeper, and inspect the evidence packet together. The goal is to learn whether the record answers the review question — not to force a generic product demo.