I gave my OpenClaw agent my real medical records. Here's the guardrail layer I built so it can't screw up.

I set up to run OpenClaw on a Mac mini with a few personas. One of them, Sally, is basically my family's primary care assistant. She has my actual medical records, pulled from Epic through a consumer health connector. Real labs, real conditions, real blood pressure readings, over Telegram. Handing an LLM agent your actual health record is obviously a terrible idea, so I spent the last year building the layer that makes it not terrible. It's open source (MIT): HealthClaw Guardrails. What it does: it sits between any agent (OpenClaw, Claude, whatever speaks MCP) and health records, and enforces six things on every single request: - PHI (Name address info etc) redaction before data reaches the model (names become initials, identifiers masked, the agent can say "your potassium is normal" without ever holding your SSN) - an immutable audit log of every read and write, so you can see exactly what the agent saw - writes require a short-lived signed token, an agent can't modify a record as a side effect of a conversation - clinical actions get blocked with HTTP 428 until a human explicitly confirms - strict tenant isolation (my records and my kids' records can never bleed into each other) - medical disclaimers injected on everything clinical (You can technically send back data to your provider if you wanted to share it via a QR code link) The part I think this sub will actually care about: the safety is testable, not promised. There's a $conformance endpoint that probes a live deployment with synthetic data and grades it A through F across all six properties. It runs in CI, so if I break a guardrail, the build fails. You can run it against my prod right now. Where this got humbling: I recently did a hard audit of my own project with fresh eyes and found that my human-in-the-loop gate was partly theater. The MCP forwarding layer was stamping the "human confirmed" header itself. The HTTP gate was real but the agent's own toolchain could satisfy it. I'm fixing it properly right now: approval moves fully out of band (a card on your phone with the exact action, for a phone call the verbatim script and exactly which health details it will speak out loud, and an Approve button that is the only thing that can execute it). Posting this partly as accountability. What's next, and the voice angle: the same rail is getting real-world actions. The agent proposes calling my pharmacy about a refill, I see the exact script, I tap approve, an AI voice agent places the actual call, and I can read the transcript a minute later. It can only ever dial numbers I registered. Phone calls and SMS are landing first, auto-filled intake forms (the clipboard at every new doctor) right behind, appointment booking after that. Saw the OpenClaw Voice hardware post earlier and it got me thinking, local voice in, guarded voice out could be a fun pairing. Honest state of the project: it works, it runs my family's health data daily, it has about 1,000 tests, and almost nobody uses it. 26 GitHub stars. If you run OpenClaw and have ever thought about pointing it at your health data, I would genuinely love for you to try it and tell me where it breaks. The action layer is a small plugin interface (an executor is about 50 lines), so if you want to add a capability behind the confirmation gate, that's the easiest way in. I welcome all PR's and any feedback, the hard part has been getting anyone to use it and actually tell me what works and what doesnt. Hoping this will help! *first post on openclaw reddit Repo: https://github.com/aks129/HealthClawGuardrails Live conformance check: https://app.healthclaw.io/r6/fhir/$conformance Not a product pitch, there's nothing to buy. I just think agents are going to touch health data whether we like it or not, and I'd rather the safety layer be open source and community-owned than a black box inside some app. I believe Patients should own all their health data not some for profit vendor or health system!