February 22, 2026 · ~2,000 words · For health app developers and architects

Keep the Data Layer Local: An Architecture for AI + Health Data

The common pattern: you build a health app, you add AI features, you send user health data to an AI API. Depending on who you are, you may have just created a HIPAA compliance risk. This post makes the case for keeping the data layer local: the health records and the tools that read them stay on the user's machine. It also says plainly what that does not cover: if the agent uses a cloud model, what it reads is sent to that model.

Local-First Privacy HIPAA MCP Architecture

The Common Pattern

Here is how most health apps add AI features in 2026:

User opens the app.
App pulls health data from local storage or an EHR API.
App assembles a prompt with the health data and sends it to an AI API (OpenAI, Anthropic, Google).
AI API returns a response.
App displays the AI-generated summary or recommendation to the user.

This pattern is fast, easy to implement, and produces impressive demos. It is also, in most configurations, a significant compliance problem that is easy to underestimate until something goes wrong.

The question is not whether this pattern produces a bad user experience — it often produces a great one. The question is whether you have thought through the full compliance, liability, and user trust implications of transmitting health data to a third-party AI service. Most teams have not, because the default developer experience of AI APIs makes it trivially easy to skip that thinking.

Before you continue building

If you are sending health data to any third-party AI API today, ask yourself: Does your company have a signed Business Associate Agreement (BAA) with that AI provider? Do you know where the AI provider stores inference data? Do you know whether the AI provider uses API inputs for model training? If you cannot answer all three with certainty, you may have compliance exposure.

The Risks of Cloud AI + Health Data

⚠

BAAs are not automatic

If you are a HIPAA covered entity or business associate, HIPAA requires a Business Associate Agreement with a vendor that handles PHI on your behalf. Check whether your AI provider will sign one, and on what terms. Ask counsel.

⚠

Unclear data retention policies

AI providers retain inference data for varying lengths of time. Even when a provider says it does not train on API inputs, data may be retained for a period, for example for safety monitoring. Check each provider's current terms. Your users' health data is sitting in a third-party's infrastructure, subject to that provider's retention schedule, security posture, and potential legal process.

⚠

Vendor risk: terms of service can change

You build your product on an AI API's current terms of service. The provider changes those terms, or gets acquired, or changes its data handling policies. Your users' health data is now subject to a different data handling regime — one they never consented to and one you did not design for. GDPR's data minimization and purpose limitation principles are particularly relevant here.

⚠

Users have no control over their own data

Once health data is transmitted to a third-party AI provider, the user has lost meaningful control over it. They cannot delete it from the provider's systems. They cannot audit what the provider did with it. They cannot revoke access. That makes rights such as GDPR's right to erasure harder to honor.

The Local-First Alternative

The Cascade Protocol is designed around a different architecture: the health data and the tools that read it stay on the user's device or local server. Whether the AI model runs locally too is a separate choice.

[ Health Data Pod ] ——> [ Local MCP Server ] ——> [ AI Agent ]

The pod and the MCP server send nothing out. But if the agent uses a cloud model, what it reads is sent to that model.

The AI agent needs access to the user's health data to do useful work. The data does not need to be stored anywhere else for the agent to reach it. The Model Context Protocol (MCP) connects the agent to the pod over a local connection.

The key insight is that there are two separable concerns:

The AI model: The language model that does the reasoning. This can be a locally-running model (Ollama, LM Studio, etc.) or a cloud model accessed via a network connection. When using a cloud model, you are sending the model's context to the cloud, which includes whatever data you put in the prompt.
The health data: The structured health records in the user's Pod. These should never go in the prompt. Instead, the agent uses MCP tools to retrieve specific, relevant data in structured form, do its reasoning, and write results back. The data access happens locally; the reasoning happens wherever the model runs.

Wait — if the agent uses a cloud model and the MCP tools return health data, doesn't that data still end up in the model's context? Yes. This is the honest complexity of local-first health AI. We address it in the limits section below.

How It Works Technically

The Cascade local-first architecture has four components:

1. The Local Pod

Health data is stored in a local Pod — a directory of RDF/Turtle files on the user's device. Encryption at rest is optional: the CLI can encrypt a pod with a passphrase (AES-256-GCM; the specification is a draft). File names and sizes stay visible. The Pod directory contains all of the user's health records, organized by data type.

2. The Local MCP Server

Running cascade serve --mcp starts a local Model Context Protocol server that listens on a stdio or socket interface. This server exposes a set of tools that allow an AI agent to read from and write to the Pod in a structured way. All file operations are validated against the Pod boundary to prevent path traversal. There is no consent filtering: a connected agent can read the whole pod.

Critically, the MCP server runs entirely locally. It makes no outbound network connections. Its only communication is with the AI agent framework on the same machine via the MCP protocol.

3. The AI Agent Framework

Claude Desktop, and increasingly other AI clients, support MCP natively. You configure the Cascade MCP server in Claude Desktop's MCP configuration file, and Claude can then use the Cascade tools to read and analyze the user's health data in a conversational interface.

When Claude uses an MCP tool to read health data, that data flows: Pod files → MCP server (local) → Claude Desktop client (local) → Claude API (cloud, for the model inference). The model receives the data in its context window and generates a response. The response flows back: Claude API → Claude Desktop client → displayed to user.

4. Audit Logging

Every MCP tool invocation is logged to the Pod's audit trail at provenance/audit-log.ttl, so the user can see what the agent accessed through MCP and when. The log is a plain file and is not tamper-evident. Every agent write is tagged with cascade:AIExtracted provenance, distinguishing AI-written content from clinical data.

Your device

Health Pod → cascade serve --mcp → Claude Desktop

RDF/Turtle files — AES-256-GCM — stdio/socket — local process

↑ with a cloud model, what the agent reads is sent here for inference

Cloud: Claude API (for model inference, if not using a local model)

The Compliance Argument

✓

With a local model, no AI provider receives the data

If you use a local model, health data never reaches an AI provider. If you use a cloud model, it does: the provider receives what the agent reads. If you are a HIPAA covered entity or business associate, ask counsel about BAA requirements in that case.

✓

The audit log is local and user-controlled

The Pod's audit log is stored on the user's device, not in your cloud infrastructure. Users can read it, export it, and delete it. It records each MCP call in a standard RDF/Turtle file that any person or machine can read. It is not tamper-evident, and it does not cover reads made outside the MCP server.

✓

Data can be deleted trivially

GDPR's right to erasure requires that you be able to delete a user's data on request. With a local-first architecture, deleting the pod is straightforward: remove the Pod directory. There is no copy on your servers to coordinate. If a cloud model was used, the model provider may still hold what it received, under its own terms.

✓

Users see exactly what the agent accessed

Because the audit log is a user-accessible file in the Pod, users can read it directly. They can see every read and write the agent made through the MCP server, and what it wrote back.

Practical Example: Claude Desktop MCP Configuration

Setting up Claude Desktop to access a Cascade Pod locally takes about two minutes. Add the following to your Claude Desktop MCP configuration file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS):

{
  "mcpServers": {
    "cascade-health-pod": {
      "command": "cascade",
      "args": [
        "serve",
        "--mcp",
        "--pod", "/Users/yourname/health-pod"
      ]
    }
  }
}

With this configuration in place, Claude Desktop will start the Cascade MCP server as a subprocess when it launches. The MCP server provides Claude with the following tools:

cascade_pod_read — Return a summary of the Pod: profile, record counts, provenance sources
cascade_write — Write AI-generated observations and summaries back to the Pod, tagged with cascade:AIExtracted provenance
cascade_pod_query — Query the Pod for specific records or data ranges
cascade_validate — Validate Pod data against SHACL shapes
cascade_convert — Convert Pod data to FHIR R4 JSON for clinical system interoperability

Claude can now ask questions like "Review my medication list and check for any potential interactions" and access the relevant records directly through the MCP interface. The records it reads are sent to Anthropic as part of the conversation, because that is where the model runs.

No code required

The above configuration is the entire integration. There is no application layer to build, no data pipeline to maintain, no API keys to manage for the health data access layer. The Cascade CLI handles all the structured data access, and the MCP protocol handles the agent-tool interface.

The Offline Assurance

There is a simple test you can perform to verify the local-first architecture is working as expected: disconnect from the internet, then use Claude Desktop to query your health Pod.

If you are using a local AI model (via Ollama or LM Studio), the entire workflow continues to work offline. The model runs locally, the MCP server runs locally, and the Pod is local. Zero network dependencies.

If you are using Claude Desktop with Anthropic's cloud API, the model inference will fail offline (Claude needs to reach Anthropic's servers for inference). But the MCP server and Pod access remain local — you can confirm this by watching network traffic: the Cascade MCP server makes no outbound connections whatsoever.

This offline test is a useful sanity check during development. If your AI + health data workflow does not degrade gracefully offline, it means health data is flowing out of your local environment during normal operation — which may not be what you intended.

For extra assurance

You can verify the absence of outbound connections from the Cascade MCP server at any time using a network monitor (Little Snitch on macOS, or lsof -i / Wireshark). The server process should show zero network connections during normal operation.

What Local-First Cannot Do

Honesty matters here. Local-first architecture has real limitations that are worth acknowledging explicitly.

Using a cloud AI model means health data enters the model's context

When Claude Desktop uses a Cascade MCP tool to read health data and includes it in a message to Claude (Anthropic's cloud API), that health data is being sent to Anthropic's servers for model inference. The MCP server itself is local and makes no outbound connections, but the data Claude retrieves via MCP tools does appear in the model context that goes to the API.

This is a fundamental architectural tension: you cannot use a cloud-hosted AI model and simultaneously guarantee that health data never leaves the device. The honest position is that local-first architecture with a cloud model significantly reduces the scope of data transmission (you only send what the agent explicitly requests, not a bulk dump), but does not eliminate it for the model inference step.

If this is unacceptable for your use case, use a locally-running model (Ollama, LM Studio) instead of a cloud API. The Cascade MCP server works identically with either. The tradeoff is model quality: current local models are capable but generally less capable than frontier cloud models for complex clinical reasoning tasks.

Local-first does not guarantee security of the device

Local-first means the pod and the MCP server do not send data off the device. It does not protect against a compromised operating system, malware with filesystem access, or physical access to an unlocked device. These are device-level security concerns outside the protocol's scope. Platform-level protections (iOS Secure Enclave, macOS FileVault, keychain access control) are what address these threats.

Collaborative health data sharing requires a different architecture

If your use case requires sharing health data between multiple parties — a patient and their cardiologist, a research participant and a study coordinator — the local-first Pod model needs to be extended with a sync and access control layer. The pod's file layout follows Solid conventions, but no sharing, sync or access control layer is built today.

Conclusion

The default path for adding AI to a health app is the easy path: send data to an API, get an answer, display it. It is easy, fast, and creates compliance problems that are invisible until they are not.

The local-first alternative requires a small amount of additional thinking: you need to understand MCP, you need to install the Cascade CLI, you need to think about what data the agent should have access to. But the result is an architecture where you can answer the compliance questions that matter: where is the data? who can access it? what did the agent do with it? can the user delete it?

For many health AI use cases — medication review, symptom tracking, visit preparation, trend analysis — a local Cascade Pod with an MCP client is simple to set up. With a local model, the data stays on the machine. With a cloud model, the provider receives what the agent reads; decide deliberately whether that is acceptable. For use cases that genuinely require cloud data sharing, build that deliberately, with appropriate consent, BAAs, and access controls — not because an API call was convenient.

Health data is among the most sensitive personal information that exists. It deserves an architecture that treats it that way.