Arhas · Trust and security
Most security pages open with the badges. This one opens with the list of badges we do not have, because that is the list you cannot get anywhere else, and because a vendor who will tell you what they lack is the only kind whose claims are worth reading.
01 — The part nobody else prints
Five claims we could make today, that a buyer could not check, and that would probably close deals. Here is each one, refused, with the reason.
No external security certification of any kind, from any body. If a vendor tells you they are certified, ask which body issued it, on what date, and against what scope. We cannot answer those three questions, so we do not make the claim.
Our security artifacts are internal: hand-rolled encryption and audit libraries, an internal fixes register, static analysis in CI. Internal review is not an audit. We will not describe it as one, and we will not borrow the word "independent" for work we did ourselves.
MedOS has ABDM-ready architecture, sandbox-validated. HIP certification is in progress. It runs against the ABDM sandbox and no live patient data has passed through an ABDM endpoint. That sentence is longer and worse than the one our competitors use, and it is the one that is true.
NABH and NABL accredit hospitals and laboratories. They do not accredit software, so there is no certificate for us to hold. LabOS is built for NABL: it produces the hash-chained trail and the release controls an assessor will ask to see. The accreditation is the lab’s. Our job is to make it defensible.
Because we do not run a public status page, and a number with nothing to check it against is decoration. Nine-nines on a marketing page costs a vendor nothing. When there is a status page, there will be a figure, and it will link to the page that proves it.
None of this makes our software less secure than it was a paragraph ago. It makes the description of it accurate — and an accurate description is the only thing on a trust page that has any value at all.
02 — What we do have
A control that lives in a document can be skipped by anyone in a hurry. A control that lives in the request path cannot. Every item here is the second kind, and every item carries the file it was read out of.
AES-256-GCM with a random 96-bit IV per value, a 128-bit auth tag, HKDF-SHA256-derived subkeys and a key version in the envelope so keys rotate without a migration. Exact-match search runs against an HMAC-SHA256 blind index, not a plaintext column.
MedOS lib/security/encryption.ts · LabOS lib/security/encryption.ts
Every patient-data write, every authentication event and every privileged action is appended to a chain where each row carries a SHA-256 hash of the row before it. A retro-active edit breaks the chain, and the chain can be recomputed on demand.
LabOS lib/security/audit.ts — verifyAuditChain(db, labId)
The person who approves a result can never be the person who entered it. This is not a disabled button. The request is rejected server-side, with a 403, before anything is written.
LabOS api/results/route.ts:265-277 — rejected before any write
Fetal sex cannot be recorded in a radiology report. An expired medicine cannot be dispensed at the counter. HIV and mental-health records are segregated and excluded from bulk export. Nine Indian regulations†, blocked where the data is entered rather than flagged in an audit six months later.
MedOS api/regulatory/ · api/pharmacy/ · api/radiology/ — nine regulatory modules
Seven roles — admin, doctor, nurse, receptionist, lab technician, pharmacist, billing. A 30-minute idle logout, a 12-hour absolute session ceiling, and a limit of three concurrent sessions per user.
MedOS COMPLIANCE_AUDIT.md:146 (7 roles) · :128-131 (session limits) · api/staff/ · api/rbac/
No second engine, no signatures of its own, no "disable Defender" button, and it never registers itself as an antivirus — which would silently switch Defender off. If a status read fails, it says "status unavailable" instead of a frightening "unprotected". It ships no kernel driver and injects into nothing.
BRUTAL Services/DefenderService.cs · FrameStatsService.cs
† Nine is MedOS's own published count of the regulatory modules it ships, corroborated by those modules existing in the repository. We have not independently recounted them, so we do not call the figure audited, verified or counted — three words that would each be doing work we have not done.
One more admission, on the first card. In MedOS, the additional authenticated data that binds a ciphertext to its own row is about 95% retrofitted — rows written before v5.6 still decrypt through a legacy path with no AAD. The encryption is real. Its universality is not, and we would rather you read that here than discover it later. MedOS app/docs/security/known-gaps.md:126-146 — AAD retrofit at ~95%, DECLARED v5.28 The full list of what we are still finishing is on the engineering page.
03 — Where the data actually lives
"All your data is stored in Mumbai" is the standard line in Indian health software. For a Cloudflare-native deployment it is not true — not for us, and not for anyone else who says it. This is the version we can defend.
| What | Where | How precise we can honestly be |
|---|---|---|
| Application compute MedOS app/wrangler.jsonc:15-17 · LabOS app/wrangler.jsonc:14-16 — placement.region | Cloudflare Workers, placement region aws:ap-south-1 | A placement hint, not a contract. Cloudflare tries to run the Worker near Mumbai. It does not undertake to. |
| MedOS database MedOS app/src/lib/d1.ts:3 · COMPLIANCE_AUDIT.md:16 — Turso host medos-…aws-ap-south-1.turso.io | Turso (libSQL), ap-south-1 | In India. This is the one row in this table that is unambiguous. |
| LabOS database LabOS app/src/lib/db.ts:12 — LABOS_DATABASE_URL is a runtime secret: no region in any config | Turso (libSQL), region not published | We have not verified the region, so we are not printing one. Ask, and we will check before we answer. |
| Report PDFs, uploads LabOS app/wrangler.jsonc:29-35 — R2_REPORTS, bucket labos-reports | Cloudflare R2 (APAC) | Not India-guaranteed. LabOS report PDFs are served by signed URL and are never public, which is a different property from residency. |
| arhas.in itself package.json:14 — astro build && wrangler pages deploy dist | Cloudflare Pages, global edge | Static pages. No accounts, no forms, no personal data. Residency is not a question here. |
04 — Data, and who touches it
"We never share your data with third parties" is a sentence we are not allowed to write, because it is false for us and it is false for every hosted product that has ever printed it. A hospital's data reaches Cloudflare, because that is the compute and the object storage. It reaches Turso, because that is the database. It reaches Razorpay when a subscription is billed. It reaches Google when a clinic switches on the optional AI features, which is why those features are optional.
What we can say, and mean: we never sell data. Not to advertisers, not to data brokers, not to a pharmaceutical company, not to an insurer. The DPDP Act 2023 is one of the Indian regulations MedOS enforces in the code path, and the consent and erasure routes are part of the product rather than a policy page bolted onto it.
This website collects nothing. No analytics, no tag manager, no third-party fonts, no embedded video, no pixel, no cookie. There is no consent banner on arhas.in because there is nothing to consent to — which is a cheaper and more convincing way to describe a privacy posture than a page describing one.
05 — Reporting something
The machine-readable policy lives at
/.well-known/security.txt, and it
names the same mailbox as this page.
[security mailbox pending verification]
No monitored @arhas.in mailbox exists yet, so we publish a marker rather than an address that would bounce. A dead security contact is worse than none.
Anyone can buy a badge. Only a company that will tell you what it does not have is a company whose remaining claims mean anything.