A guardrail layer is only worth as much as the people who maintain it.
So this page says who does, under what rules, and what is not covered. It is deliberately specific about the limits.
Who
HealthClaw Guardrails is built and maintained by Vestel AI LLC, a limited liability company organised in the Commonwealth of Pennsylvania. The maintainer is Eugene Vestel.
Longer-form writing on the thinking behind the project: Building a New, Empowered Health System and How I Build My Personal OpenClaw.
The rules this is built under
Most of what makes a guardrail layer trustworthy is process, not code. These are enforced in CI, not stated as intentions.
- Every deployment grades itself. Seven safety properties, checked against synthetic data the probe creates, A–F, live and public. A pull request that drops the grade cannot merge.
- Nobody merges their own work. A maintainer approves. That gate is the point of having it.
- Failures get written up in public. When something breaks, the retrospective goes in the repository next to the fix, including the ones caused by the maintainer.
- Demos use synthetic data only. The public MCP endpoint is pinned server-side to a synthetic tenant. It cannot serve real records even if asked.
- A control that cannot answer must say so. "No data" and "could not check" are different answers, and the second is never rendered as the first.
The security posture page covers what the grade does and does not cover.
What this is not
Stated plainly, because finding it out on a procurement call wastes your time and mine.
- Not a large team. This is maintained by one person with clinical and standards advisors. That is fine for a reference implementation and a design partnership. It is a real risk if you need a vendor with a support rota, and you should weigh it.
- Not a covered entity or business associate under HIPAA. An organisation running this against real patient data owns its own compliance, agreements, and controls.
- Not certified. There is no SOC 2 report and no HITRUST certification today.
- Not a medical device, and not medical advice. Every clinical read carries a disclaimer, enforced rather than written into a style guide.
Working together
Three ways, depending on what you need. All of them start at support@healthclaw.io.
MIT licensed. Run it locally in ten seconds, point it at your own FHIR server, or install the plugin into Claude Code. If a guardrail is missing for your case, an issue or a pull request is the fastest path.
If you are putting an agent near clinical data and need the permission, redaction, and audit layer to be someone else's problem, this is the layer. Useful when you want FHIR and MCP expertise applied to your surface rather than rebuilt in-house.
Say what you are building and where it touches patient data. A short technical call is usually enough to tell whether this fits.
Read the security posture first. If the gaps listed there are disqualifying for your procurement process, they will be disqualifying in month three as well, and it is better to know now.
Where a pilot does work: a scoped evaluation against synthetic or de-identified data, with the conformance grade as the acceptance criterion, and a written account of what the guardrails did and did not cover.
Advisors
Clinical and standards advisors review the parts of this that make claims about care. Named here once they have agreed to be.