ChironAI is built for the security expectations of regulated healthcare. Encryption, audit, access control, and data isolation are not policies bolted onto the product after the fact — they are architectural properties of the platform itself, inherited by every deployment.
All ChironAI traffic is encrypted in transit using TLS 1.3 with modern cipher suites. The production application enforces HSTS with a two-year max-age and preload directive. 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 key (BYOK) support is on the roadmap and is available for institutional deployments on request.
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 to signed documents are recorded as new versions; the original signed version remains immutable and verifiable.
Document versioning enables full historical reconstruction. Amend, co-sign, and bulk-sign workflows preserve the audit posture end to end.
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. bulk signing, 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, blue-green deployment patterns, and canary traffic splits (5% to 25% to 50% to 100% with soak intervals between).
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-split flip rather than a redeploy. Canary traffic patterns surface regressions before they hit the full user base.
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.
External penetration testing is performed on a defined cadence and on major release boundaries. Results are not published publicly but are available to institutional customers under NDA as part of the procurement diligence process.
Our security team responds to procurement and audit-firm inquiries within two business days. Vulnerability disclosure is routed to hello@mindhyve.ai with the subject prefix "Security Disclosure".
Contact our security team →