Security and HIPAA posture

The Health Insurance Portability and Accountability Act (HIPAA) sets the standard for protecting sensitive patient data. Miravio, a product of Antitropy LLC, is built to handle protected health information (PHI) on behalf of clinics and practitioners, and this page describes the safeguards that exist in the product today, ahead of the platform being cleared to hold any. We keep it factual: every statement here is verifiable in our codebase or in the linked infrastructure documentation, we say plainly where a control is designed but not yet legally activated, and we update the page as things ship, never before.

1. Encryption in transit and at rest

• In transit: all traffic between your browser and Miravio is served over HTTPS (TLS). Connections from the application to the database are TLS as well.
• At rest: Miravio's database, file storage, and backups run on Google Cloud, whose published security documentation states that it encrypts customer data at rest by default with AES-256 and encrypts data in transit.

Published evidence for the infrastructure claims above:

• Google Cloud default encryption: States that Google Cloud encrypts customer data at rest by default with AES-256, and encrypts data in transit between its facilities.
• Google Cloud SOC 2 compliance: Confirms that the Google Cloud infrastructure Miravio runs on is independently audited and SOC 2 Type 2 compliant. That attestation belongs to the infrastructure provider; Miravio itself holds no SOC 2 attestation.
• Google Cloud HIPAA compliance: Describes the Business Associate Agreement Google Cloud offers for its HIPAA-eligible services. Miravio has executed one covering its production infrastructure (Cloud SQL, Cloud Storage, Cloud Run, and Memorystore). The remaining regulated-lane controls and the per-clinic agreements described in section 5 are still being stood up, which is why the beta permits no PHI.
• Google Cloud shared responsibility model: Defines which safeguards Google Cloud provides at the platform layer and which we implement in the application layer, as documented on this page.

2. Access control and tenant isolation

Every table holding clinical data is protected by database-enforced Row-Level Security (RLS). Access is scoped to the requesting user's organization and role, so therapists, parents, and clinic staff can only reach records their organization and permissions explicitly allow. Role-based permissions are enforced on the server for every action, sign-in attempts are rate limited, and when a team member is removed or downgraded their active sessions are revoked.

3. Audit trails

Miravio writes audit log entries for authentication events (sign-in success and failure, sign-out, password changes, role changes, member removal) and for access to client records, including record views, session note reads, and data exports. That is the path that will carry PHI once the platform is cleared to hold it. During the beta those records contain demo data, so the audit trail is exercised against the same code path without any real client information passing through it. Audit entries reference records by internal identifiers rather than names, so the audit trail itself does not duplicate the underlying data. Clinic administrators can review their organization's audit history from the compliance dashboard.

4. AI features and PHI

Miravio's optional AI executive summaries are disabled by default. When the feature is off, summaries are produced by deterministic templates and no data leaves our infrastructure. The AI prompt path is reviewed so that it carries only organization-level aggregate metrics (counts, totals, and rates), never client records or names, and we will not enable AI processing for any clinic's data until a business associate agreement with the AI provider is in place.

5. Business Associate Agreements: the regulated lane

This section describes a process that is under way but not complete. It is what has to be in place before Miravio accepts PHI, not what happens today. During the invite-only beta Antitropy LLC is not a business associate of any clinic, because no clinic's protected health information is on the platform and none is permitted.

HIPAA requires an unbroken chain: a covered entity may only disclose PHI to a business associate under a BAA, and that business associate may only pass it to a subcontractor under another one. Ours has three links; the first is executed, and the other two are not in place yet:

• Infrastructure. Executed. Miravio's production infrastructure (Cloud SQL, Cloud Storage, Cloud Run, and Memorystore) runs under a Business Associate Agreement with Google Cloud, which covers its HIPAA-eligible services (see the compliance guide linked in section 1).
• Antitropy to each clinic. Not yet in place. A BAA is executed with the individual clinic before it brings any client data onto the platform, so none exists until the first clinic onboards.
• Onward subprocessors. Not yet in place. Any additional service that would touch PHI needs its own agreement before it is enabled. This is why the optional AI summaries in section 4 remain switched off.

The remaining links are executed as each clinic is brought into the regulated lane, which we are targeting to open in mid-September 2026. We would rather publish this sequence plainly than let a clinic assume cover that does not exist. To discuss a BAA ahead of that date, or to be told when the lane is live, contact us at the address below.

6. Your data, guaranteed portable

Families and clinics can export their complete records at any time. Guaranteed portability is a product principle: if you leave Miravio, your data leaves with you in usable formats, and the clinic remains the covered entity for its clinical records throughout. This holds for beta data as well: whatever you put into the beta, you can take out of it, and the migration path off the beta environment is documented before it is needed rather than after.