We built a blockchain to keep ourselves honest

--

A founder’s note on what it means when your chat vendor says their audit logs are “secure,” and what we built to prove ours actually are.

So…

I run Mika, an AI chat tool used by therapists, dentists, and other practices that handle sensitive patient information. We have a feature called Privacy Mode that strips PII out of conversations before they touch our AI provider, optionally never writes the conversation to our database, and delivers leads through one-time-use encrypted links.

That’s the architecture. But the architecture isn’t the whole answer. The other half is: how do you prove the architecture actually ran the way you said it did?

So we built a blockchain.

The problem nobody talks about

Most chat vendors will tell you their data is “secure” and their audit logs are “encrypted at rest.” Both of those things can be true and still leave a gap.

Who stops the vendor from quietly editing their own audit logs?

Imagine: a patient sues. A lawyer subpoenas the chat transcript. The transcript shows something embarrassing, or shows that something was retained that shouldn’t have been. The vendor is on the hook.

What stops a vendor in that position from just… editing the record? Or quietly dropping a row from the audit log? Or rolling back the database to a state from before the embarrassing event?

The standard answer is “we have access controls and an audit log.” But the audit log is in the same database the rogue admin has access to. Encryption-at-rest doesn’t protect against an admin who has the keys.

That’s the gap. And it’s the gap we built our blockchain to close.

What we built, in plain English

Every action that happens inside Privacy Mode (every conversation started, every lead captured, every appointment requested, every escalation alert triggered) gets stamped into a chain.

Each entry in the chain has a cryptographic hash. The hash is computed from a few things, but the most important thing is: it includes the hash of the entry that came before it.

• So entry #1 has hash A, computed from its own contents.
• Entry #2 has hash B, computed from its own contents *plus* hash A.
• Entry #3 has hash C, computed from its own contents *plus* hash B.
• And so on. Each entry is locked to the one before it.

If anyone, including us, goes back and changes entry #2, even by one character, entry #2’s hash no longer matches what entry #3 is locked to. Entry #3’s hash no longer matches what entry #4 is locked to. The whole chain after the change becomes inconsistent.

To “fix” the chain after tampering, you’d have to recompute every hash from the modified entry forward. To do that, you’d need our cryptographic secret. And here’s the thing: customers can verify the chain at any time using a “Verify Integrity” button in their dashboard. If they checked yesterday and the chain was clean, and they check today and the chain is broken, they know exactly when something got tampered with.

This is the same fundamental data structure blockchains use. It’s the part of blockchain that does the actual tamper-detection work. We don’t have a distributed ledger or proof-of-work. Those add other guarantees that aren’t relevant here. What we have is the core math.

What it protects against, and what it doesn’t

It protects against:

- A rogue admin (ours or yours) editing a record after the fact.
- An honest mistake (a developer running an UPDATE query they shouldn’t have).
- A subpoena response where the vendor is tempted to “clean up” the record before handing it over.
- A breach where the attacker tries to cover their tracks by rewriting the log.

It also protects us, the vendor, from being asked to alter records under pressure. We genuinely cannot do it without breaking the chain. The chain is the proof.

I want to be honest about what it doesn’t do, because most vendors aren’t:

• It doesn’t protect against an attacker who reads the audit log without modifying it. Encryption-at-rest is the answer to that, and we have it.
• It doesn’t protect against us writing a deceptive record in the first place. If our code has a bug or a malicious developer ships code that logs the wrong thing, the chain just locks in the deceptive record. The chain proves nothing was changed *after* it was written. It can’t prove the original record was honest. Mitigation: open documentation about what we log, and code review on the writes themselves.
• It doesn’t protect against us recomputing the entire chain from scratch with a new secret. We’d have to do this knowing the customer would notice the next time they ran verification.

Mitigation: customers should run “Verify Integrity” regularly. The dashboard surfaces this.

A blockchain with distributed consensus would close some of these gaps.

We’re not running one of those. We chose this design because:

• The threats we’re guarding against are insider threats and subpoena-pressure tampering, not nation-state attackers.
• Distributed consensus would require either putting customer audit data on a public chain (privacy nightmare) or running a private consensus network (operational overhead with no clear benefit for our threat model).
• A cryptographic hash chain catches the realistic failure modes at very low operational cost.

Why this matters in healthcare

I started with healthcare because that’s where the architecture-vs-paperwork question is most asymmetric.

A small dental practice will spend three months evaluating an EHR vendor. BAA review. IT signoff. Encryption questions. The whole exercise.

Then they install a free chat widget on their site that asks patients for date of birth, insurance member ID, current medications. The data goes to a Gmail inbox at the front desk, sometimes to Mailchimp, sometimes back to the chat vendor’s own servers retained indefinitely. The free tier doesn’t have a BAA. The paid tier might, but the practice didn’t pay for it.

Same practice, same patient data, two completely different levels of scrutiny.

The chat is the lowest-friction surface where patients drop the most identifying information, and it’s the part of the stack nobody scrutinizes.

The blockchain doesn’t fix that asymmetry on its own. But it does answer one question that most chat vendors can’t: when something goes wrong, can you prove the audit log is real?

We are not HIPAA compliant

I want to disclose this clearly because it matters.

Mika does not sign Business Associate Agreements. We are not a HIPAA-covered entity. We are not a business associate.

What we are is a chat tool whose architecture, in Privacy Mode, doesn’t store visitor PII anywhere we can be subpoenaed for it. Names, phone numbers, insurance IDs get tokenized before reaching the AI provider. Conversations can be set to never write to our database. Lead notifications go through one-time-use links. Audit events are stamped into a tamper-evident chain.

That’s the architecture. It’s not a regulatory claim.

If you need a vendor that signs a BAA, we are not the right vendor. There are good ones that do.

If you’re evaluating a vendor that does sign a BAA, ask them what their audit log architecture looks like. Ask if they can demonstrate the log hasn’t been altered. Ask what happens if a customer asks for proof.

Most can’t show you anything. The BAA is the answer they have. The BAA is paperwork. Architecture is the thing that catches the actual failure modes.

What this means for practitioners

Two practical takeaways.

One. If you’re choosing a chat tool for a practice that handles sensitive data, the BAA isn’t the only question. It might not even be the most important question. Ask:

• Where does the conversation transcript live, and who can read it?
• If a patient asks for their data deleted, can the vendor actually delete it?
• What stops a rogue admin or a careless engineer from quietly editing a record after the fact?
• How would the vendor *prove* nothing has been altered if you needed them to?

If those answers take longer than ten minutes to find, that’s the answer.

Two. Run a free privacy scan on your current setup.

We built a tool at hiremika.com/tools/privacy-audit that scans any URL for what’s leaking: sensitive form fields, trackers, chat tools without BAAs on the plan you’re paying for. It takes 15 seconds and doesn’t ask for your email.

It will not solve your privacy posture. It will just show you what the asymmetry looks like for your own site.

Most practices I talk to have at least one finding they didn’t expect.

The bigger point

We built a blockchain because we hold patient data we don’t want to be trusted to alter. Even by ourselves.

The standard architecture in this industry is: trust us. The vendor’s database has access controls, the vendor has policies, the vendor has employees who signed NDAs. All of that is a series of human promises stacked on top of one another.

A blockchain is math. It works the same whether the vendor is honest, dishonest, or under subpoena. That’s the property we wanted.

If you build infrastructure that handles other people’s sensitive data, build it so that even you can’t cheat it. The peace of mind that comes from numbers nobody can fudge, including yourself, is worth more than any banner you can paste on a marketing page.

— -

Mika is an AI chat tool for businesses that handle sensitive customer information. Privacy Mode is a managed add-on for healthcare and other regulated practices. More at hiremika.com/secure-chat.