Security & Subprocessors

Last updated: June 28, 2026

This page is maintained by ANZLabsAI LLC to describe security practices and third-party subprocessors used by the 340B Audit OS service. It is informational and does not, by itself, constitute a security certification.

1. Application Controls

  • TLS 1.2+ in transit for all customer traffic.
  • Authentication via email/password and OAuth (Google), backed by Supabase Auth.
  • Row-Level Security (RLS) policies enforce per-organization data isolation in the database.
  • Role-based access: customer vs. staff/reviewer paths are separated server-side.
  • Automated PHI scanners run on uploads, chat input, and document body text to block PHI before it is persisted or sent to AI providers.
  • Secret scanning (Gitleaks), Dependabot, and CodeQL run on the source repository.
  • Per-finding human acknowledgment is required for customer review of automated findings.

2. Data Handling

  • The Service is designed for non-PHI administrative, financial, and program-eligibility data only. PHI submission is prohibited under the Terms (§ 2.3).
  • Encryption at rest is provided by our infrastructure subprocessor (Supabase / AWS-backed Postgres and object storage) using their standard AES-256 defaults.
  • Customer Data is logically isolated per organization.
  • Backups are managed by the database subprocessor under its standard practices.

3. Subprocessors

The following third parties process Customer Data on our behalf:

SubprocessorPurposeLocation
Supabase, Inc.Database, authentication, object storageUnited States (AWS)
Stripe, Inc.Payment processingUnited States
Lovable AI GatewayRouting of AI prompts to upstream model providers (currently Google Gemini)United States
Lovable (hosting)Web application hosting and edge runtimeGlobal edge

We rely on these subprocessors' standard published security practices and their own third-party attestations (e.g., Supabase publishes SOC 2 Type 2 reports at trust.supabase.com; Stripe is PCI-DSS Level 1 certified). ANZLabsAI itself does not currently hold an independent SOC 2, ISO 27001, or HITRUST certification, and does not represent that it does.

4. What We Do Not Do

  • The Service is designed for non-PHI data. We do not act as a HIPAA Business Associate and no BAA is required or offered for use of the Service.
  • We do not sell Customer Data.
  • We do not currently use third-party analytics, error-monitoring, or marketing SDKs (no Sentry, PostHog, Google Analytics, Segment, etc.) in the customer application.
  • We do not use Customer Data to train foundation models.

5. Incident Reporting

Report a suspected security issue to [email protected]. We will acknowledge within five (5) business days.

6. Updates

We will update this page when subprocessors or material controls change.