Platform
Zero-trust AI
in the network layer.
CareProxy sits in the network — not on every endpoint. Every request is classified, routed fail-closed, and cryptographically logged. 100% on the hospital's own infrastructure. No US cloud.
How zero-trust routing works
Three stages — Triage, Route, Verify. Every request is classified and routed in under 10 milliseconds.
Triage
Classify in real time
Every request is scanned against our Clinical Domain Dictionary. Patient identifiers, ICD-10 codes, medication names, and department-specific terms are classified by risk level. Sub-10ms.
Route
Zero-trust decision
High-risk payloads are locked to your on-prem AI — never public cloud. Low-risk payloads route to OpenAI/Anthropic. Fail-closed: when classification is uncertain, data stays local. Sticky-local sessions.
Verify
Cryptographic proof
Hash-chained audit log records per request: session ID, risk score, trigger rule, destination, SHA-256 payload hash. Immutable. Verifiable. Ready for auditor and regulator.
Triage
Classify in real time
Every request is scanned against our Clinical Domain Dictionary. Patient identifiers, ICD-10 codes, medication names, and department-specific terms are classified by risk level. Sub-10ms.
Route
Zero-trust decision
High-risk payloads are locked to your on-prem AI — never public cloud. Low-risk payloads route to OpenAI/Anthropic. Fail-closed: when classification is uncertain, data stays local. Sticky-local sessions.
Verify
Cryptographic proof
Hash-chained audit log records per request: session ID, risk score, trigger rule, destination, SHA-256 payload hash. Immutable. Verifiable. Ready for auditor and regulator.
AI-injection-firewall
Ten attack patterns · per-persona · ALLOW / WARN / BLOCK
Patient notes and clinical documents pasted into a prompt may contain hidden instructions — deliberate or accidental — attempting to manipulate the model's behaviour. CareProxy scans every prompt for ten attack patterns before it ever reaches an external model.
The ten signal types
- 01
Instruction OverrideAttempts to cancel or replace the system prompt. E.g. "ignore all previous instructions and …".
- 02
Role-Tag InjectionEmbedded chat-format tags forging a new system or assistant turn. E.g. ChatML <|im_start|>, Llama [INST], Anthropic-style turn prefixes.
- 03
Exfiltration RequestAttempts to make the model dump records, list everything, or reveal the system prompt. E.g. "list all patients", "repeat your initial instructions".
- 04
Tool-Use HijackForged tool-call markup inserted into the prompt to trick the model into executing functions. E.g. fabricated function-call JSON or tool-use blocks.
- 05
Unicode Tag SmugglingInvisible Unicode tag characters (Plane 14, U+E0000–U+E007F) and bidi-override marks that hide instructions inside otherwise plain text.
- 06
Encoded PayloadBase64-style blocks whose decoded contents read as instructions.
- 07
Delimiter BreakoutMarkdown fences or triple-quotes used to break out of a quoted block and inject a new conversation turn. E.g. ``` followed by User:.
- 08
Indirect InjectionInstruction-shaped content embedded inside a quoted patient note, document, or context block — the classic supply-chain prompt attack.
- 09
Multilingual JailbreakOverride phrases in non-English languages (Danish, German, Spanish, French, Chinese, …) used to slip past English-only filters.
- 10
Length / Repetition AnomalySingle lines over 4 KB, or short tokens repeated to push the system prompt out of the context window.
Scoring is per-persona — clinical researchers get tighter thresholds than developer tooling that legitimately works with code. A Danish-language allowlist ensures clinical phrasings ("ignore the previous blood test, that was a measurement error") aren't falsely blocked.
Fail-Closed Architecture
CareProxy deploys 100% on-premise. Our Triage engine classifies and routes every request with zero data persistence. High-risk payloads are locked to your own AI models. Every routing decision is logged cryptographically — legal-grade evidence for CISOs, auditors, and regulators.
On-Premise Deployment
Deploys inside your hospital's own ISO 27001-certified datacenter. Docker/K8s. No cloud dependency. Full data sovereignty from the first call.
Sticky-Local Sessions
Once a session is classified as high-risk, it is locked to local AI models — including subsequent calls from the same session. No leakage via context.
Fail-Closed Default
On classification uncertainty, routing error, or model timeout, data stays local. Zero-trust is the default — never the exception.
Hash-Chained Audit Log
SHA-256 hash chain per request, Ed25519-signed, persisted to Postgres. Both prompt and response are hashed. One-click forensic export. Optional RFC 3161 timestamp anchoring.
Architecture & Security
Technical specifications
Three layers of verification — from database to external authority
The log isn't a JSON file in a bucket. Every row is hash-chained, Ed25519-signed, persisted to Postgres, and can be exported as a self-contained evidence bundle that an external investigator can verify without contacting CareProxy.
What is logged?
- Timestamp, session ID, decision, trigger rule, latency
-
SHA-256hash of the prompt (payload_hash) -
SHA-256hash of the model's response (response_hash) — proves what came back, not just what went in - AI-injection-firewall score and signals (if any)
How is the log protected?
- Each row is hashed together with the previous row's hash → hash chain
- Each row is signed with
Ed25519(private key lives locally, never in the cloud) - The chain is persisted to
Postgres— survives restart, can be audited independently from the database alone - Optional
RFC 3161timestamp anchor every hour at an externalTSA— proves the log existed before a given point in time, independently of your own signing key
How is evidence handed over?
- One click in the CISO dashboard produces a self-contained JSON file with the full chain,
signature, public key, and verification instructions - An external investigator verifies with stdlib crypto (
openssl, Python, Go) — no contact with CareProxy required
RFC 3161 timestamp anchoring is opt-in (TSA_URL env var). Most hospital networks block outbound HTTPS — turn it on once your network allows it.
From routing to attestation — the path to Confidential Computing
CareProxy is built in two stages. Today: zero-trust routing between cloud AI and your own on-prem models — built for hospital CAPEX reality, not per-hour cloud rent. Tomorrow: when frontier providers (OpenAI, Anthropic) finally expose hardware attestation, CareProxy automatically becomes the verifier for public cloud AI. The moment hospitals can use the world's smartest models with cryptographic proof that data stays inside a hardware-sealed enclave.
- Shipped 2026 · Stage 1 · Zero-Trust Routing
On-prem classification and fail-closed routing: low-risk to cloud AI, high-risk locked to your own local LLMs (e.g. Llama 3). AI-injection-firewall in front of every model. Hash-chained, Ed25519-signed audit log persisted to Postgres — both prompt and response hashed. One-click forensic export. RFC 3161 timestamp anchoring (optional). Deployed with pilot partners.
- 2027 – 2029 · Stage 2 · Frontier Model Attestation
Once OpenAI, Anthropic, and other frontier providers expose hardware attestation (TEE) via their public APIs, CareProxy automatically becomes the verifier for public cloud AI. Hardware-documented access to the world's smartest models — with the legal evidence in place.
Ready to take control of your AI infrastructure?
CareProxy is under active development. Join the waitlist to be notified as soon as pilot installations open.
Or reach out directly kontakt@careproxy.dk