Security engineered into the reasoning substrate.

All ChironAI traffic is encrypted in transit with TLS 1.2 or higher, using modern cipher suites; TLS 1.3 is used whenever the browser supports it, and older protocol versions are refused. The clinician application sends HSTS with a two-year max-age, so browsers never fall back to plain HTTP. Inter-service traffic inside the Azure deployment also uses TLS termination at the ingress, with private virtual networks for service-to-service calls where appropriate.

Data at rest is encrypted with 256-bit AES, the industry standard for regulated workloads. Application data lives in encrypted PostgreSQL Flexible Server instances; binary clinical media (radiology images, lab reports, DICOM, photo exam) lives in encrypted Azure Blob Storage. Encryption keys are managed through Azure Key Vault. Customer-managed keys (BYOK) are on the roadmap and are not available today.

Every clinical action that mutates state in ChironAI writes an entry to an append-only audit log. Each entry stores the previous entry’s hash, the action metadata, the actor identity, the tenant ID, and a timestamp. A new hash is computed over those fields, and an HMAC signature is taken over the new hash using a server-side secret.

The resulting structure is a tamper-evident chain: any single-entry modification breaks the hash linkage forward, and any signature forgery is detectable at chain-verification time. The audit log is enforced as immutable at the database layer — no UPDATE or DELETE permitted, regardless of caller.

Every signed clinical document carries a SHA-256 hash of its content at signature time, captured alongside the signing clinician’s identity and timestamp. Any subsequent modification fails hash verification.

Amendments never overwrite a signed document. In ChironAI CDS an amendment is a hash-bound addendum and co-signature is recorded; in ChironAI OM the amendment is a separate record linked to the original. Either way the original is left unmodified.

Permissions in ChironAI are not coarse role buckets. They are fine-grained clinical capabilities (read-own-patients, prescribe-medications, sign-documents, override-drug-interactions, view-audit-logs, etc.) that compose into roles configured per institution. User-level overrides and revocations let clinical operations teams handle break-glass scenarios without granting blanket admin access.

Effective permissions per user are resolved server-side on every request, cached in Redis for performance, and surfaced to the UI for affordance gating. Every privileged action is logged.

Every database row in ChironAI carries a tenant ID. Tenant-ID guards run on every request before query execution; row-level security policies in PostgreSQL enforce isolation at the database layer. Platform super-administrators have a documented break-glass path with explicit X-Tenant-Id header attestation and tamper-evident audit logging of the impersonation.

Tenant isolation is verified by automated tests in the application layer, and by the database-level RLS policies independently of the application layer.

MFA is supported and recommended for all staff accounts. Implementation supports TOTP authenticator apps; SMS is deprecated. Step-up MFA can be required for privileged actions (e.g. document amendment, super-admin operations).

ChironAI runs on Eve-Grid™ — our proprietary Azure-native deployment posture. Production workloads run on Azure Container Apps with health probes and blue-green releases: each new revision starts at 0% of traffic and takes over only after its health checks pass.

Secrets live in Azure Key Vault and are surfaced to the application via secretRefs, never in plaintext environment variables. Service-to-service messaging runs on Azure Service Bus. Binary clinical media lives in Azure Blob Storage. Observability runs through Application Insights and OpenTelemetry with the chiron-cds tracer.

No customer is on a generic Azure deployment. Every deployment is purpose-built for the latency, compliance, and reliability properties that regulated healthcare requires.

Database backups run on a continuous-restore window via Azure PostgreSQL Flexible Server. Recovery-time and recovery-point objectives are documented per institutional deployment in the deployment Statement of Work.

Blue-green deployment posture means production rollback is a traffic flip back to the previous revision rather than a redeploy, and a revision that fails its health checks never takes traffic.

cds.chirongrid.ai and om.chirongrid.ai do NOT ship behavioral analytics, session-replay tooling, or heatmap instrumentation. The clinical screens render PHI by definition — encounters, lab values, medication lists, narrative notes — and any session-replay collection of those screens would capture PHI by accident even with aggressive masking. The architectural decision is to keep that class of tool off the clinical surfaces entirely, not to mask around it.

Operational telemetry on the clinical surfaces is limited to Azure Application Insights, capturing only first-party performance signals (page-load timing, request errors, JS exceptions) and explicit instrumentation events (e.g., "appointment_saved", "report_generated") which are designed so no PHI flows into the telemetry. Application Insights runs under the same Microsoft BAA that covers the rest of our Azure substrate.

The www.chirongrid.ai marketing site uses Microsoft Clarity for session-replay and heatmap analytics, gated by a CCPA / GDPR consent banner. Clarity does not load until the visitor has affirmatively granted analytics consent; declining keeps the site fully functional and ships no behavioral signal. The marketing site is intentionally a separate domain and a separate codebase from the clinical surfaces so that the clinical posture is not contaminated by marketing-grade telemetry.

Application Insights also runs on the marketing site for first-party performance and error telemetry; that runs regardless of consent under both the CCPA "necessary services" carve-out and GDPR’s legitimate-interest basis for operational instrumentation.

Behavioral analytics are valuable for marketing-site iteration and harmful in a clinical context. The cleanest engineering posture is to enable one and disable the other at the platform level rather than to install everything and rely on per-surface masking. We chose the cleanest posture.

ChironAI operates audit-ready controls aligned to the SOC 2 Trust Services Criteria. Formal audit pathway evaluation is underway. We are not currently SOC 2 certified, and we will not claim certification until the audit completes and the report is in hand.

For procurement teams that need security-questionnaire material in advance of a formal report, we provide a controls-mapping document on request that walks through how each Trust Services Criterion is met by our current operational and architectural controls.

ISO 27001 alignment is part of the same audit-pathway evaluation. Status updates are published on the Disclosures page as the timeline solidifies.

No external penetration test of ChironAI has been completed yet. An internal white-box security review has been performed and its findings are being fixed. When an external test is completed, its summary will be available to institutional customers under NDA.