Security & Responsible Disclosure

Why this page exists

Pablo is AGPL-3.0 open source. The code is public, the architecture is public, and the security testing should be too. If you're considering Pablo — hosted by us or self-hosted — you shouldn't have to take our word for the security posture. You should be able to read the actual test and see what was found.

Technical implementation

This is the implementation detail behind the commitments in our BAA and Privacy Policy. We keep the receipts here, on a page that engineering can update without rewriting a privacy policy, so the values you read are the values that ship.

In transit

• TLS required. All connections to app.pablo.health use TLS. Plain HTTP requests are rejected with HTTP 400 by the application's HTTPS-enforcement middleware.
• HSTS. Response header on every production response: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload (two years, with subdomains, preload-list eligible). The two-year window is the IETF + browser-vendor recommendation for preloaded production sites; longer is more secure because the browser remembers the HTTPS-only commitment longer.
• WebSocket authentication. Real-time channels (Practice Mode) require a single-use opaque ticket with a 30-second lifetime, issued through an authenticated REST call. Firebase ID tokens are never embedded in WebSocket URLs (which are logged by proxies, CDNs, and browsers).

At rest

• Cloud SQL. Every block on disk encrypted with AES-256 using Google-managed keys.
• Cloud Storage. Every object encrypted with AES-256.
• Application-layer column encryption. Google Calendar OAuth tokens and iCal feed URLs are additionally encrypted with AES-256-GCM at the application layer before storage.

Tenant isolation

• Schema-per-tenant. Each practice receives its own PostgreSQL schema (practice_<id>). Application code resolves the practice schema from the authenticated email at the start of every request and sets the database session's search_path before any handler runs.
• Commit-time template-schema guard. The request middleware refuses to commit a database transaction if the session is still pointed at the default template schema — a defense-in-depth check against bugs that bypass schema resolution.
• Postgres Row-Level Security. RLS is FORCE-enabled on every table that carries a user_id column. The RLS policy fails closed when the per-request user context (app.current_user_id) is unset, so a query that somehow ran outside our middleware returns zero rows rather than leaking across users.

Identity and access

• MFA required. Time-based one-time-password (TOTP) MFA is required by default for all production users. The signup flow gates application access on enrollment.
• Session-token revocation on every request. Firebase ID tokens are verified with the check_revoked=true flag on every request, not just at sign-in, so a revoked token cannot continue to ride a long-lived browser tab.

AI processing

• Routed through Vertex AI. All large-language-model inference (Google Gemini and Anthropic Claude) runs through Google Cloud Vertex AI under Google Cloud's HIPAA BAA and the Cloud Data Processing Addendum, both of which contractually prohibit the use of customer content for model training.
• What goes where. Note generation, Practice-mode AI patient, EHR navigation: Gemini via Vertex. Audit-log behavioral review: Anthropic Claude via Vertex, on PHI-free metadata only.
• No consumer-tier APIs. Production code does not call api.openai.com, api.anthropic.com, or generativelanguage.googleapis.com. The weekly internal pentest probes for egress to those hosts and surfaces any finding in the next dated report; an active finding triggers a release hold.
• Defense-in-depth. The optional "Improve Gemini for Google Cloud" project setting (which only affects certain Duet AI / Cloud Code features, not the raw Vertex AI generate-content path Pablo uses) is disabled on our project.

Audit logging and behavioral monitoring

• PHI-free audit log. Every action that touches PHI writes a structured audit record. Audit-log contents are PHI-free by contract — a runtime assertion in the audit-write path rejects a write that would include a denylisted PHI field.
• Seven-year retention with auto-purge. Audit records expire seven years after the action date and are physically removed by a daily purge job.
• Daily HIPAA log review. A daily job runs over every tenant's audit logs and looks for behavioral patterns that indicate possible misuse — off-hours access bursts, novel user/patient pairings, surname matches between user and patient, no-treatment-relationship views, bulk deletes, and export-rate spikes against a per-user baseline. Findings are summarized by an LLM (Anthropic Claude on Vertex, run on PHI-free behavioral metadata only) and written to a retention-locked compliance bucket. High-severity findings emit an alerting log entry that operators wire to Cloud Monitoring for paging.

Backup and retention

• Cloud SQL backups. Encrypted, rotated on a thirty-day cycle. PHI deleted from the live database disappears from every backup within thirty days as the rotation progresses. Backups are not used to recover deleted data except under the Covered Entity's written instruction.
• Three-stage deletion. See Privacy Policy §10 and BAA §7 for the user-facing retention timeline; the implementation runs as scheduled Cloud Run Jobs (hard_purge_cron, audit_retention_cron, audio_retention_purge).

Egress allowlist

The application boundary is allowlisted to the subprocessors named in the BAA §5.2 and Privacy Policy §5. The weekly internal pentest probes for egress to non-allowlisted hosts; any finding is surfaced in the next dated pentest report and triggers a release hold while it is investigated. The release hold is operational today (an on-call engineer reviews the report and pauses release) — automating it as a hard CI gate is on our roadmap.

Our disclosure pledge

That's deliberately stricter than what HIPAA requires. The Breach Notification Rule (45 CFR §164.400–414) only triggers on actual unauthorized access to PHI — not on the vulnerabilities that could have led there. We publish those anyway. For Critical findings against deployments that can't patch in an hour, a short embargo (typically 7–30 days depending on severity) protects users while patches roll out, consistent with how Django, Rails, and the Linux kernel coordinate security releases.

How we test

This isn't a checkbox. We built our own pentest tool — a custom LLM agent (open source, in our repo) that drives the scanners, cross-references our BAA manifest on every external egress, maps each finding to the specific HIPAA Security Rule control it touches, and tracks closure week-over-week.

This is our primary technical evaluation today. As Pablo grows, the program will grow with it.

A week-by-week authorized penetration test runs against the deployed Pablo app. The methodology is mapped to the HHS Office for Civil Rights' expectations for a qualified pentester of a HIPAA-regulated system:

• OWASP ASVS L2 for the web-app authorization boundary
• OWASP API Security Top 10 for the FastAPI surface
• NIST SP 800-115 (planning → discovery → attack → reporting)
• HIPAA Security Rule (45 CFR §164.308, §164.310, §164.312) as the lens for severity

Every finding is tagged with the specific CFR section it affects (a CFR mapping) so operators and auditors can see which control the finding speaks to. Examples: an audit-logging gap maps to §164.312(b); a cross-tenant access issue maps to §164.308(a)(4) and §164.312(a)(1).

Reproducibility — run it yourself

The entire pentest methodology ships in the repo as an agent skill, with parallel implementations for Claude Code (.claude/skills/pentest/SKILL.md) and the Gemini CLI (.gemini/skills/pentest/SKILL.md). The same playbook also runs unattended in a hardened container as a scheduled Cloud Run Job — that's what produces the dated reports below. Two different LLMs running the same playbook surface different things, so we run both deliberately.

If you self-host Pablo, you can run the same owner-authorized test against your own deployment with /pentest — no black box, no "trust us."

Published reports

Each run produces a dated report. We publish them as we go — including ones with open findings. Findings stay in the report until they're closed; closed findings are re-tested the following week and noted in the next report's "items tested clean" section. Browse the archive in the public repo.

Methodology: HIPAA Pentest Guide (what OCR expects, what we do, CFR mapping, severity rubric, rules of engagement).

If you're self-hosting

Pablo is AGPL — you can (and many will) run it on your own infrastructure. Your security posture is your own, but we'll do everything we can to make it defensible:

• Register your deployment at pablo.health/register so we can reach you for operator-first notifications.
• Run the pentest skill against your own instance — same test we run on ours, as often as you want.
• Subscribe to security releases — we'll tag security fixes clearly in the GitHub release notes and on the announce list you join at registration.
• Your breach, your notification. If an incident happens on your self-hosted deployment, you are the business associate (or covered entity) responsible for the §164.410 notification. We'll help with forensics and patches; the regulatory filing is yours.

Reporting a vulnerability

If you find something in Pablo — the hosted product, the OSS codebase, or a deployment you're running — email security@pablo.health. We read it.

What helps:

• A clear reproduction (one PoC is enough — please don't keep pivoting).
• The affected component (frontend / backend / infra) and, if you know it, the CFR section you think is implicated.
• Your preferred credit in the public write-up (or "prefer anonymous").

We'll acknowledge within 72 hours, work a fix with you, and publish per the policy above. We don't currently run a paid bug bounty — but we do credit every valid report by name in the pentest report archive.

What this page does not cover

• The pablo.health marketing site — a small Next.js app with Stripe checkout and signup endpoints; issues still welcome at security@pablo.health.
• Google, Firebase, or Anthropic infrastructure — those are upstream providers with their own disclosure programs. Report to them directly.
• Issues in forks or derivatives of Pablo not published by us. We'll help if we can, but the maintainer is whoever shipped the fork.