Security and privacy

Designed as though it will hold protected health information, because one day it will

The prototype holds no patient data at all. The architecture is nonetheless built to business-associate expectations, because retrofitting those controls after the first real deployment is how clinical software fails its first security review.

What this prototype holds today

No patient data. No external transmission. No telemetry. Every case, image, structure, plan and number is a fixture compiled into the application. There is no database, no upload path, and no field anywhere on the public site that accepts clinical detail.

Deployment modes

Most clinics will want the first two. The platform is designed so that choice is theirs.

Research local: Synthetic or de-identified data only. No connection to a clinical system.
Single-site on-premises: All patient data and all inference remain inside the clinic's own network.
Hybrid: Patient data stays on-premises; de-identified operational metrics sync to a control plane.
Private cloud: A clinic-approved cloud environment under the agreements that environment requires.
Enterprise multi-site: Federated policy with local gateways and centralised governance.

Controls

Identity: SAML or OIDC single sign-on with phishing-resistant multi-factor authentication. Role-based access combined with patient-context attribute checks.
Least privilege: Just-in-time administrative access. Agent services hold narrow, explicit tool allowlists and never hold delivery-system credentials.
Encryption: In transit and at rest, with managed keys and documented rotation.
Audit: Immutable, tamper-evident events covering access, export, approval and every model inference. Refused actions are recorded as well as permitted ones.
Network: Segmentation, gateway allowlists, and an outbound-only design where the site's policy allows it.
Data minimisation: No patient data in source control, support tickets, telemetry, prompts or training by default. De-identification validated across metadata and burned-in pixels.
Supply chain: Software bill of materials, dependency scanning, code signing and signed updates.
Resilience: Backup, disaster recovery, incident response and breach procedures, each tested rather than documented.
Lifecycle: Penetration testing and a secure development lifecycle, with retention, deletion, legal hold and customer export controls.

Threats specific to an AI platform

The classic controls are necessary and not sufficient. These are the ones that come with agents.

Prompt injection: Instruction text hidden in a referral, a report or a retrieved page. All retrieved content is treated as data. Agents may extract it; they may never obey it. The prototype demonstrates this on a synthetic case where a referral footer carries an injected instruction.
Data poisoning: A malicious or mistaken expert correction. Corrections become candidate training data behind adjudication and offline release, never live learning.
Context leakage: Cross-patient or cross-tenant bleed. Patient context is carried explicitly on every agent call and checked at the boundary.
Fabricated citations: A source that does not exist or does not say what is claimed. Every claim is verified against an approved source with a version and a review date, or it is not shown.
Unauthorised tool use: An agent reaching for a capability outside its contract. Tool allowlists are enforced outside the agent, and an attempt is recorded in the audit history.
Silent change: A model or prompt that changed without a version. Version pinning, commissioned-version checks and a stop condition when they differ.
Malformed interchange: Adversarial DICOM fields, decompression bombs, malformed objects and identifier collisions, handled by conformance and fuzz testing.
Automation bias: The reviewer who accepts a bad output because the last hundred were fine. Treated as a security-adjacent risk and measured, not assumed away.

Quality management

A quality-management system is being established alongside the product rather than after it: design and development planning, user needs and requirements, risk management with hazard traceability, design reviews, verification and validation, configuration and change control, supplier qualification, complaint and incident handling, corrective and preventive action, a cybersecurity lifecycle, post-market monitoring and training records.

Mapping the applicable requirements and standards is work for qualified regulatory and quality leadership. Purchasing a standard is not the same as complying with it, and we do not claim compliance we have not demonstrated.