--- title: 'Zero-egress health AI: how a LifeCare node keeps raw data in place - LifeCare.ID®' description: 'Zero-egress health AI means the models run where the raw data lives and only interpreted outputs leave. How a LifeCare node enforces that in three layers: adapters that refuse non-local model endpoints, scoped access for every agent, and an API whose every response is a complete field whitelist screened numeric-free. What is kept, for how long, and how anyone can verify what a node runs.' canonical: https://lifecare.id/zero-egress generated: 2026-10-08 --- Zero-egress health AI: how a LifeCare node keeps raw data in place - LifeCare.ID® [LifeCare.ID®](https://lifecare.id/) Reference # Zero-egress health AI: how a LifeCare node keeps raw data in place Zero egress means the models run where the raw health data lives, and what leaves is interpretation: a score, a band, a sentence with no number in it. This page describes how a LifeCare node enforces that, in code, and how anyone can check that a given node runs the code that does. Published 4 September 2026, updated 30 September 2026 (the attestation paragraph). Describes the node software serving the LifeCare network; the API contract it refers to is published and drift-tested. ## What zero egress means, and the three places a model can run Every AI product that reads health data has to answer one question: where does the raw value go when the model needs it? There are three answers. - **To a cloud model.** The value is sent to a provider's inference service. This is what a memory layer or a chat assistant does when it puts your data in the prompt. Privacy rests on the provider's policy. - **To an attested remote enclave.** The value is sent, but to hardware that can prove what it runs and cannot retain what it sees. This is the confidential-computing answer, and at its best it is verifiable. - **Nowhere.** The model comes to the data. Inference runs on the machine that holds the raw values, and only interpreted outputs cross to anything else. This is zero egress. A LifeCare node is the third answer. The node is a machine, physical or virtual, owned and operated by the person's provider, holding that person's raw data under their consent. It runs the models. Its API serves apps, and the contract of that API is that no raw biometric value is ever served. The person's app, their weekly letter, their guardian's replies are all interpretation produced next to the data, not data sent away for interpretation. ## Three layers of enforcement A promise like "raw data never leaves" is only as good as the code paths it would have to leak through. On a node there are three, and each has its own gate. | Path | Gate | Where it lives | |---|---|---| | A model call | Model adapters refuse any endpoint that is not on the machine, and on a shared model server accept only the model ids declared in the manifests | The model runtime | | An agent's read | Agents never hold the data source; they hold a guarded accessor limited to declared scopes, and every read acquires a token and lands in the person's ledger | The data interfaces | | A response to an app | Every response is a complete field whitelist; prose is screened numeric-free before it is shown; inputs are acknowledged without echoing values | The API contract and the voice screen | ## Layer one: where models run The node's model runtimes are constructed with an endpoint, and the constructor refuses anything that is not a loopback address. The refusal is not a warning; it raises, with the reason in the message: inference must stay on the node. ``` refusing non-local model endpoint 'https://api.example.com' — inference must stay on the node (PHI boundary) ``` A loopback address is not enough on its own, because a model server on the machine can proxy to a cloud model behind a local port. So each model is declared in a manifest with its id, runtime, quantization, licence and the endpoint it is served from, and the adapter for a shared server is fenced to exactly the ids declared against it. A request for any other model on that server is refused, whatever the server's catalog offers. The rule in the design notes is one line: a local URL alone does not prove local inference. Today's node runs two open-weight models on an NVIDIA DGX Spark: a 14-billion-parameter reasoner for synthesis and a 30-billion-parameter mixture-of-experts model for the conversational guardian, both Apache-2.0 licensed, both served on loopback. Replacing either is a manifest change. The weights never live in the repository, and the licence is part of the manifest because the freedom to run the model anywhere is part of the sovereignty claim. ## Layer two: what an agent may read An agent on the node never receives the longitudinal data source. The runtime hands it a guarded accessor restricted to the data scopes its definition declares, from the same fixed vocabulary the [authorization server](https://lifecare.id/authorization-server) knows: `cgm`, `daily`, `labs` and the rest. A read outside the declared scopes fails with a permission error before any value is touched. Every read inside them acquires a token for the person, the scope and the agent's purpose, and writes an access event to the person's ledger. The agent is a requester like any app, with a narrower door. ## Layer three: what may leave The API contract lists, for every response, the complete set of fields that will ever appear. The weekly summary is representative: ``` GET /v1/users/{user_id}/summaries/weekly/latest { "user_id": "…", "kind": "muscle-preservation", "period_start": "2026-06-04", "score": 57, "band": "at-risk", "summary": "It sounds like this week was a bit of a challenge…", "components": { "protein_support": 0.0, "training_stimulus": 16.7, "loss_velocity": 25.0, "lean_mass_trend": 15.0 }, "generated_at": "2026-06-10T21:56:37Z" } ``` A score, a band, sub-scores on a fixed scale, a date and a sentence. The sentence contains no numeric value by contract. Three mechanisms hold that line: - **The voice screen.** Every generated sentence passes a screen before it is shown: numeric-free, free of internal vocabulary, inside the general-wellness boundary, and free of clinical language. A sentence that fails is sent back to the model with the reason as the retry instruction; a sentence that cannot pass falls back to authored copy, so unscreened model text is never served. - **The floors.** Below the screen, compose-time floors refuse specific values outright: a raw glucose reading, because the node never states one, so any such number is fabricated; kilograms, milliseconds, beats and hours on the same logic. The prompts order the model to spell counts as words, and the floors check the spelled forms too. - **Acknowledgement without echo.** When a person or their scale reports a weight, the acknowledgement returns the day it was recorded and whether a related value was estimated, and not the weight. When an app contributes an experience episode, its context and outcome must be categorical labels; a label carrying a digit is refused with 422. ## What the node keeps, and for how long - **Raw provider payloads** are held in a buffer for twenty-four hours and purged. The derived series the node computes from them are what it keeps. - **What the node remembers about a person** in words (the twin's facts and reflections) rejects any value carrying a digit at write time, and is encrypted under a per-person data-encryption key. - **Erasure is key destruction.** The person's key is destroyed, and every payload encrypted under it becomes unreadable, on the node and in any backup that holds a copy. Keys are stored wrapped under a node master key that never travels in a backup bundle. ## Where raw data enters Two ways, and neither passes through the consent layer. A source with a cloud API, such as a continuous glucose monitor's partner API, is fetched by the node under a token the person granted; the consent layer ran the connection handshake and holds the grant, and the bytes travel provider to node. A source that exists only on the person's phone or scale, such as a health-data store on the handset or a Bluetooth body-composition reading, is shipped by the person's own edge app directly to their node under an insights-scoped token. Device to node. In both cases the node is the first and last place the raw value is stored. ## Verifying a node Zero egress is a property of the code a node runs, so the node publishes what it runs. Every node exposes a signed attestation: a measurement over its identity, its role, the exact code commit, the loaded models with their licences, the active learned-parameter version and the twin recipe version, computed over exactly the published fields so anyone can recompute it from the response, and signed with the node's P-256 key using ES256. The [verify page](https://lifecare.id/verify) (explained on [the attestation page](https://lifecare.id/attestation)) fetches a node's attestation in your browser, recomputes the measurement, checks the signature against the key the response carries, compares that key with the keys LifeCare.ID® lists for the node, and shows you the commit and models. The attestation is the node's own report of what it runs; [what a pass proves and what it does not](https://lifecare.id/attestation#proves) is on the attestation page. ## What zero egress does not mean - **Not air-gapped.** A node fetches its sources, serves interpreted outputs to the person's app, and talks to the authorization server about tokens, receipts and the registry. Zero egress is a statement about raw values, not about network traffic. - **Not "no cloud models anywhere".** Frontier cloud models are used to develop the node's code, review it and plan it. They are never on the path that touches a person's data; the constraint is written into the engineering rules and enforced by the adapters above. - **Not a policy.** The properties on this page are code paths with tests pinned to them: the endpoint refusal, the allowlist, the field whitelists, the numeric-free screen and the floors. A policy can be quietly relaxed; a test fails. ## Why this is the right shape for AI on health data Models are becoming interchangeable. The thing that is not interchangeable is a person's longitudinal record and the ledger of what was recommended and what happened next. Keeping the model next to the data means the record never has to be copied to wherever the best model happens to live this year, and swapping the model is a manifest change rather than a migration of everyone's data. It also means the question "what did the AI see" has an answer a person can read: the ledger names every access, the receipt names every grant, and the attestation names the code. ## Further reading - [A zero-egress on-device clinical language model](https://arxiv.org/abs/2604.18302), the recent work that uses the term for the same property in a psychiatric decision-support setting. - [Apple Private Cloud Compute](https://security.apple.com/blog/private-cloud-compute/), the strongest public example of the second answer above: attested remote inference with a transparency log, for comparison. - [OpenMined SyftBox](https://openmined.org/syftbox/), compute that travels to the data owner's machine, the same philosophy for research data. - [The consent receipt](https://lifecare.id/consent-receipt) and [the patient-held authorization server](https://lifecare.id/authorization-server): the grant and the token behind every read described here. - [The paper: design and early operation](https://lifecare.id/paper), the preprint that puts the receipt, the tokens, the enforcement and the attestation in one document, with the design rationale and the limits. **Deployment note.** The shared model server on the current node also lists a catalog entry that proxies to a cloud model, used by operator tooling; it is outside the allowlist, so no agent can reach it, and moving it to a separate server so the allowlist becomes defence in depth is scheduled work. The hardware, model choices and buffer window are the current deployment and change by manifest and configuration; the three gates do not.