Security Posture

AI operates the workflow. Source systems prove the facts. Humans make every regulated decision. Every regulated action is designed to be attributed, receipted, and replayable.

Reviewed: 2026-07-22 · Canon: generation 8, effective 2026-07-21 · Posture: pre-launch by design. Security and compliance controls are designed and staged. The deployed environment runs on synthetic data and fails closed on real data. Production claims require current evidence, executed agreements, and completed tests.

1. What exists today

The deployed system operates on a synthetic corpus. No real roster, no paying customer, and no production PHI has run through it. That is a deliberate sequencing decision, not an accident: the trust controls ship and get proven before any real data does.

• Platform spine on Google Cloud. The platform API and product surfaces (operator, readiness, worker, admin, hire, demo) are deployed as Cloud Run services behind Google-managed TLS, with Cloud SQL for PostgreSQL as the system database.
• Investor room on the same spine. This room runs on Cloud Run with a Vertex AI agent pinned to the hash-verified generation 8 canon.
• Synthetic-data gate. The deployed backend refuses real-data mode. Activating real PHI or regulated data requires the contractual, technical, security, legal, and operating gates in canon section 34 to pass first, and the gate fails closed.
• Append-only audit design. The audit ledger is designed append-only with hash chaining, actor attribution on every event, and named-human binding on every regulated decision.
• Secrets and identity. Vendor credentials live in Secret Manager. Services run under least-privilege service identities. No long-lived credentials belong in code.

Known open work, stated plainly: known trust-hardening work remains open in the deployed backend. It is tracked, prioritized, and gated ahead of any real-data activation. We state this because the honest version is the one that survives diligence.

2. The six-plane architecture

Per canon section 34, the technical foundation is organized into six planes with explicit authority boundaries:

3. Cloud spine

The approved architectural direction:

• Cloud Run for stateless services and isolated workloads
• Cloud SQL for PostgreSQL, with high availability and point-in-time recovery required before production real-data use
• Cloud Storage with retention controls for immutable artifacts, subject to an approved retention matrix
• Cloud Tasks and Pub/Sub for durable asynchronous work
• Secret Manager and least-privilege service identities
• Cloudflare for DNS and selected public or static delivery
• Vertex AI for the investor-room agent; the product agent runtime is model-agnostic by design

Historical note: earlier room documents describe an AWS deployment (ECS, RDS, S3, Cognito). That environment is labeled history. The current deployment spine is Google Cloud, and AWS-era statements in dated documents are historical snapshots, not current deployment proof.

4. Security invariants (design requirements)

These are the invariants the platform is built to, per canon section 34. Each is a checkable requirement, not a certification claim:

• default-deny access, with real server-verified authentication
• organization and facility scope enforced below the UI
• separate runtime, verifier, and decision capabilities
• no provider call inside a held database transaction
• idempotent jobs and immutable external-call reservations
• append-only audit and source receipts
• explicit secret rotation, no committed credentials
• fail-closed source activation and fail-closed real-data mode
• signed deployment receipts and exact image identity
• tested backup, restore, incident, and failover procedures before production real-data use

5. What we explicitly do not claim

• Not SOC 2 certified. The SOC 2 Type II program and its dates are in 06.3. No report has been issued.
• Not HIPAA certified. No HIPAA certification exists from any authority. The only approved phrasing is HIPAA-aligned, BAA available. See 06.2.
• Not NCQA-certified. The CVO trajectory is in 06.8. No filing has been made.
• Not penetration tested yet. An external pentest is a scheduled target (Q4 2026), not a completed artifact.
• No production-proven claims. A deployed surface is not real-data production readiness. Production claims require the trust gate, security proof, observability, rollback, incident, and data-mode receipts.
• No breach-count marketing. There is no production PHI flow, so absence-of-breach statements would be trivially true and misleading. We do not make them.

6. Data handling rules

1. The deployed environment carries synthetic data only. Real PHI is gated behind the canon section 34 activation gates and fails closed.
2. PHI-contingent vendors (identity verification, background checks, communications carrying PHI) require an executed BAA before any real PHI reaches them. Execution status is stated only with the signed document on file. See 06.4.
3. AI providers receive regulated data only after the contractual, configuration, minimization, and logging gates are satisfied. See 06.5.
4. Error tracking and logs are designed with PHI scrubbing and classification before any real-data activation.
5. Audit records are designed to carry identifiers and hashes, not PHI bodies.

7. Customer-facing security artifacts

For any future enterprise pilot conversation, the artifact set is:

1. This security posture document
2. SOC 2 Type II program status with current evidence (06.3)
3. HIPAA posture memo (06.2)
4. Threat model (06.9)
5. Incident response runbook (06.10)
6. Sub-processor registry (06.11)
7. Customer BAA template (08.9)

End of security posture.