Running OpenClaw in a HIPAA environment: what you actually need
HIPAA requirements for AI agents are simpler than vendors make them sound. Here is what you actually need, what is overkill, and what people miss.
HIPAA is not as scary as your compliance vendor wants you to think
Every time I talk to a healthcare dev team about deploying AI agents, the conversation stalls at HIPAA. Not because they don't understand the regulation, but because the compliance industry has wrapped it in so much FUD that people think they need a $200k assessment and six months of prep before they can run an agent that reads appointment notes.
HIPAA has real teeth. Violations are expensive. But the actual technical requirements are specific and finite. Let me walk through what you need if you're running OpenClaw agents in an environment that touches Protected Health Information.
The three things HIPAA actually requires
HIPAA's Security Rule breaks down into administrative, physical, and technical safeguards. For AI agents, the technical safeguards are where the work lives.
1. A Business Associate Agreement (BAA)
If your agent sends any PHI to a third party -- an LLM API, a logging service, a cloud provider -- you need a BAA with that party. This is non-negotiable and it's the thing people screw up most often.
Your agent calls Claude or GPT-4 with a prompt that includes a patient's name and diagnosis? Anthropic or OpenAI is now a business associate. You need a BAA with them. Some providers offer BAAs on enterprise plans. Some don't offer them at all. Check before you build, not after.
The workaround is stripping PHI before it leaves your environment. If the LLM never sees the patient's name, SSN, or medical record number, there's no PHI transfer and no BAA needed for that specific interaction. This is what ClawPine's compliance proxy does -- it strips identifiers before the API call and rehydrates the response afterward.
2. Encryption everywhere
HIPAA requires encryption for PHI at rest and in transit. For AI agents, this means:
In transit: TLS 1.2+ for all API calls, webhook callbacks, and internal service communication. This is table stakes in 2026. If you're not already doing this, you have bigger problems than HIPAA.
At rest: Any data store that might contain PHI needs encryption. This includes the obvious ones (your database, file storage) and the less obvious ones: agent memory files, conversation logs, skill execution traces, and temporary files written during task processing. I've seen teams encrypt their database but leave plaintext conversation logs in /tmp. That's a violation.
AES-256 is the standard. Most cloud providers handle this at the storage layer. If you're running on-prem, you need to configure it yourself. Don't roll your own encryption. Use your platform's built-in encryption at rest.
3. Audit logs
Every access to PHI must be logged. Every. Access. This includes:
- When the agent reads a patient record
- When a user views an agent's response that contains PHI
- When PHI is transmitted to an external service
- When anyone (human or system) accesses the audit logs themselves
The logs need to be tamper-proof, which in practice means append-only storage with integrity verification. Write them to a separate system from your main application. If an attacker compromises your app server, they shouldn't be able to edit the audit trail.
Include timestamps, user/system identity, the action performed, and what data was accessed. You don't need to log the PHI itself in the audit trail -- just enough to identify which records were touched.
Access controls that matter
HIPAA requires access controls based on "minimum necessary" -- people and systems should only access the PHI they need for their specific role. For AI agents, this translates to:
Skill whitelisting. Your appointment-scheduling agent doesn't need access to lab results. Define which data sources each agent can reach. ClawPine's skill whitelisting makes this declarative -- you list the allowed skills and data sources in the agent config.
Role-based access. Different users interacting with the agent should see different data. A nurse might get full patient records. A billing clerk gets demographics and insurance info. The agent needs to respect these boundaries, which means your agent architecture needs to know who's asking.
Session isolation. Agent conversations about Patient A should never leak into conversations about Patient B. This sounds obvious but it's easy to get wrong with shared memory or context. If your agent uses persistent memory, partition it by patient context.
What's overkill
Some things I see teams waste time on that HIPAA doesn't actually require:
Air-gapped infrastructure. HIPAA doesn't require air gaps. Cloud hosting is fine as long as you have a BAA with the provider, encryption is configured, and access controls are in place. AWS, GCP, and Azure all offer HIPAA-eligible services.
Running your own LLM. You don't need to self-host a language model to be HIPAA compliant. You need a BAA with the model provider, or you need to strip PHI before the API call. Self-hosting is a legitimate choice for other reasons (cost, latency, data sovereignty) but it's not a HIPAA requirement.
Certifying the agent itself. There's no HIPAA certification for software. HIPAA is about how you deploy and operate, not what software you use. Your compliance posture depends on your infrastructure, processes, and agreements, not on whether OpenClaw has a "HIPAA certified" badge.
What people miss
The stuff that actually causes HIPAA violations with AI agents, based on what I've seen:
Conversation logs going to non-BAA services. You're logging to Datadog or Sentry for debugging. Great. Does your BAA with them cover PHI? If not, and your logs contain patient information, that's a breach.
Dev/staging environments with real data. Your production setup is airtight but your staging environment has a copy of the production database and no encryption. Developers are testing agents against real patient data on their laptops. This is the most common HIPAA violation I've encountered in practice.
Memory and context leakage. The agent processes Patient A's record, stores some context in memory, and then surfaces it during Patient B's session. This is both a HIPAA violation and a product bug. Test for it explicitly.
Backup and retention. You encrypted your database. But your nightly backups go to an unencrypted S3 bucket with a 90-day retention policy. That bucket now contains 90 days of PHI. HIPAA applies to backups too.
A practical checklist
If you're starting from zero, here's the order I'd do things:
- Map your data flow. Draw every path PHI takes through your system, including logging, backups, and error reporting.
- Get BAAs in place for every service that touches PHI.
- Enable encryption at rest on every data store in the flow.
- Implement audit logging before you process real PHI.
- Set up access controls and skill whitelisting.
- Strip PHI from any data leaving your controlled environment (or confirm you have a BAA for the destination).
- Test with synthetic data first. Don't use real patient data until the above is done.
ClawPine handles items 3-6 as middleware. You still need to do the data mapping and BAA legwork yourself. No tool can do that for you.
Stay compliant, automatically
ClawPine monitors your agents for GDPR, SOC 2, and HIPAA compliance in real time.