Security | Divinci AI

Security is core to how we build. This page describes what’s actually true about our architecture and practices today — not a marketing checklist. Where we haven’t finished something (a formal audit, a certification), we say so plainly rather than implying otherwise.

Healthcare and HIPAA

Protected health information (PHI) is handled only in a separate, dedicated runtime — never in the main Divinci platform. The main platform is not approved for PHI, and you should not put PHI into it.

For health care use, we run a dedicated chat runtime in its own Google Cloud project, kept apart from the rest of the Divinci platform:

No stored conversations. The runtime keeps no message text. Its only database holds counters, acceptance records and a transcript-signing key.
Google-only model path. Requests go to Google’s Vertex AI and to two internal Google Cloud services (embeddings and a safety guard). The runtime is configured to refuse any other model host, so a third-party AI provider cannot receive PHI by accident.
Private by design. The database has no public address and requires encrypted connections; the internal embeddings and guard services reject any call that is not authenticated as the runtime’s own service identity.
Covered by agreements. Our Google Cloud agreement includes a Business Associate Agreement for this project. We sign a Business Associate Agreement with each health care customer before any PHI is handled.
A written program. We maintain 32 written HIPAA policies, reviewed by our legal counsel and approved; our workforce has completed HIPAA and security awareness training; and we have completed a security risk assessment. The program is managed in Accountable HQ.

What this is not: a HIPAA compliance certification. There is no government-issued HIPAA certificate. Compliance is a combination of technical safeguards, written policies, and signed agreements with every vendor in the data path, and it is assessed for each customer relationship. We describe our program here so you can evaluate it against your own obligations. To discuss the health care runtime, write to security@divinci.ai.

Network and edge protection

Divinci’s web and API traffic passes through several independent layers.

Main platform

Cloudflare edge (Enterprise). All public web and API hostnames are proxied through Cloudflare: TLS 1.2 or higher only, end-to-end encryption to our origin with certificate validation (“Full (strict)”), automatic HTTP to HTTPS redirect, and HTTP Strict Transport Security with a 30-day lifetime, subdomains included and preload enabled.
Web application firewall. Cloudflare’s Managed Ruleset and OWASP Core Ruleset run on every request, together with custom rules of our own, including edge blocking of the exploit and scanner probes that target API hosts.
Rate limiting and DDoS protection. Separate limits guard anonymous chat and one-time-code endpoints, chat and generation requests, and total API volume; Cloudflare’s layer 7 DDoS protection runs in front of all of it. Anonymous chat is gated by Cloudflare Turnstile.
Origin lockdown on Google Cloud. Behind Cloudflare, traffic enters a Google Cloud external Application Load Balancer protected by a Cloud Armor policy that allows only Cloudflare’s published source addresses and denies everything else. Our Cloud Run services accept traffic only from that load balancer, so the origin cannot be reached by going around Cloudflare.

Dedicated HIPAA runtime

The health care runtime deliberately does not route through Cloudflare, so no additional vendor sits in the path of its traffic. It is served directly by a Google Cloud load balancer with its own Cloud Armor policy (preconfigured rules for SQL injection and similar attacks, plus request throttling), a TLS 1.2-or-higher policy, and a runtime service that accepts traffic only from that load balancer.

Run it in your own cloud

For customers who want the strongest isolation, we can contract to deliver Divinci’s chat runtime for you to run inside your own cloud account and network, under your own agreements with your cloud provider. You own the stack, and no Divinci system sits in the path of a visitor’s message.

What you receive. A signed release bundle (your assistant’s prompts, settings and knowledge base), the runtime as a hardened container image (it runs as a non-root user and carries no bundle, key or credential), and the public key used to verify the bundle.
Nothing calls home. The runtime does not contact Divinci systems, and it keeps no copy of conversations.
Verified before it serves. The runtime refuses any bundle that is not signed by a key you trust, and refuses to serve one that has been altered.
Your models, your agreements. You point the runtime at the chat, embedding and moderation models you choose and hold agreements for, including models that run inside your own infrastructure.
Where it can run. Google Cloud (our own dedicated health care runtime is exactly this, and runs there today), AWS, Azure, Hetzner, Cloudflare Workers, or any host that runs a container. We set up and validate each target with your team before go-live, and we are upfront about which targets we have operated ourselves.
What comes along. This is the text chat runtime for a published assistant. A few platform features, such as voice and video, are not part of it; we list exactly which ones before you sign.
Licence and updates. A bundle is a perpetual licence to run that export, so a running deployment never switches itself off. Refreshed content, runtime updates, security patches and support continue under a subscription.

To discuss a customer-hosted deployment, write to security@divinci.ai.

Workforce access

Multi-factor authentication is required for the workforce accounts that can reach or administer the health care runtime: Google Workspace and Google Cloud, our compliance platform (Accountable HQ), and our AI provider account.
Cloudflare Access protects our internal tools, and workforce devices use the Cloudflare One WARP client.
Device safeguards required by written policy: full-disk encryption, firewall on, automatic screen lock, and no PHI stored on any laptop.
Least privilege. Access to the health care project is by named role, and an alert fires if an unexpected human account acts in it.

Data protection

Encryption

In transit: TLS everywhere between clients, our edge, and our origin infrastructure.
At rest: provider-level encryption on our primary datastore and object storage, plus a dedicated field-level encryption layer for designated sensitive fields.
Secrets management: credentials and API keys are managed through a centralized secrets manager, not hardcoded or stored in plaintext config. Production is configured to fail closed rather than silently fall back to stale credentials if the secrets service is unreachable.

Data minimization

Optional PII redaction (Microsoft Presidio) can be applied to chat content before it is stored or sent to an AI provider. It is entity detection, not a HIPAA de-identification determination, and it does not make a product safe for PHI.
Logs are metadata-only by policy: we don’t write message content, emails, or other personal data into application logs or error messages.

Access controls

Authentication via Auth0.
Role-based access control (platform-level) plus per-resource permissions (document/workspace-level) — least-privilege by default.
Tamper-evident audit logging: access to sensitive records is recorded in a hash-chained log designed so entries can’t be silently altered afterwards.
Access and configuration reviews of production services, scheduled under our written HIPAA policies (the first quarterly access review is set for January 2027).

Application security

XSS defense at the render boundary: user-generated and AI-generated content is sanitized (DOMPurify) wherever it’s rendered as HTML; raw HTML injection from untrusted sources is not permitted.
Authorization testing: we run our own AI-assisted and manual security testing against staging and production, including authenticated authorization/IDOR probes — not (yet) a recurring third-party penetration testing program, and we’re not going to claim one until it exists.
Dependency and code review: standard code review on all changes; dependency updates tracked through our normal build tooling.

Availability & monitoring

Synthetic monitoring on customer-facing endpoints, alerting on-call via PagerDuty within minutes of a real outage, not just on server errors — content-verified checks, not just “did it return 200.”
Cloudflare’s global edge in front of a Google Cloud origin, with automated backups on our primary datastore. The health care runtime’s database keeps 14 daily backups with point-in-time recovery, and we have rehearsed restoring it.
Health care runtime monitoring: alerts for runtime errors, failures of the at-risk (crisis) check, server errors, database outages, IAM and key changes, unexpected administrator activity, and permission-denied bursts.
Audit logs in the health care project: data-access audit logging (reads and writes) is on for the database, secrets, AI platform, runtime and storage services. Administrator activity is retained 400 days; application logs hold metadata only and are retained 90 days.
We do not currently publish a contractual uptime SLA. If your use case needs one, ask — we can talk through what’s realistic for your deployment.

Incident response

We maintain a documented incident response process: detection and classification, containment, an honest assessment of whether an incident rises to a reportable breach, remediation, and a blameless post-mortem that feeds back into what we monitor for next. If you’re a customer under a Business Associate Agreement with us, that agreement specifies our notification obligations to you — those terms govern, not this page.

To report a security concern or a suspected vulnerability, email security@divinci.ai. We don’t currently run a formal bug bounty program; we do take reports seriously and will work with you in good faith.

Where we are on formal certifications

Being direct about this, since a lot of security pages aren’t:

HIPAA: no HIPAA certification exists. We operate the dedicated health care runtime under the written program described in “Healthcare and HIPAA” above.
SOC 2: not yet started. It’s on our roadmap; we’ll update this page when there’s something real to report — not before.
ISO 27001, FedRAMP, PCI DSS: we don’t hold these certifications. Card payments are processed through Stripe; Divinci does not store cardholder data directly.

We’d rather under-claim here and be trusted than over-claim and have to walk it back.

Contact

Security questions, vulnerability reports, or compliance questions for a specific deal: security@divinci.ai