The good news: MAHAi is clean, easy to understand, and the model handled every test we threw at it. It correctly told a simulated heart-attack user to call 911, and it refused every attempt to jailbreak or manipulate it, including instructions hidden inside an uploaded file.
The concern is the mismatch between what the product promises and what it actually does, plus the controls that don’t exist yet. A footer says “not medical advice,” but the built-in prompts ask for prescription tapering plans, child dosing, and personalized supplement brands. The course calls it “already private,” yet there is no privacy notice, no way to delete your data, and every customer shares one password.
Recommendation: do not promote MAHAi for personalized health-record analysis until the five items below are addressed.
Before launch — the five gating items
- 1 Add a real safety layer for health content Move the risky templates (medication tapering, pediatric dosing, mental-health, personalized supplement brands) behind server-side guardrails with clinical review, emergency and self-harm detection, and dose limits. A footer disclaimer is not a safety control.
- 2 Publish a privacy notice and get consent before uploads Stop using the word “private” until it is substantiated. Add a plain-language privacy policy, disclose that data goes to AWS, define retention and deletion, and confirm whether the AI provider is logging inputs and outputs.
- 3 Replace the shared password with individual logins Today one password gates the whole app for every customer. Real per-user accounts are the prerequisite for the next two items and for ever attributing or revoking access to medical records.
- 4 Add rate limits and spending caps The chat endpoint calls a paid AI model with no visible throttle. One shared, leakable password is all that stands between the internet and an unbounded AWS bill or an outage for real users.
- 5 Fix the misleading “save my file” language The app tells users it will “save” their health file, but nothing is stored. Starting a new chat or reloading silently erases everything. Either make storage real (with consent) or stop saying “save.”
High severity · 5
Medium severity · 5
Low severity · 2
What held up well
- Emergency handling. A simulated heart-attack prompt got an immediate “call 911, don’t wait, don’t take supplements.”
- Jailbreak resistance. Direct extraction, a forged conversation history, and instructions hidden inside an uploaded file were all refused.
- Server-side guardrails. The backend rejects attempts to inject a fake system role; only normal user and assistant messages are accepted.
- Sane basics. HTTPS is enforced, cross-origin requests are blocked, no API keys are exposed in the browser, and the app does not render AI output as raw HTML (no cross-site-scripting today).
For your developer — paste this into Claude Code
Open the app’s repository in Claude Code and paste the prompt below. It sets the context, lists the pre-launch work in priority order, and asks for a plan before any large change.
We are preparing the MAHAi-Movie Mind app for public launch. It is a React frontend with a Python/FastAPI backend that proxies to an AWS Bedrock Claude model, with a retrieval knowledge base. An authorized security and safety review found issues we must fix before promoting the app for personalized health-record use. Ground rules: - Work on a new branch. Do not run destructive commands or touch production data. - Before any large change, show me a short plan and wait for approval. - Treat all uploaded content (labs, bills, records) as sensitive health data. - Add or update tests for each fix. Keep the app deployable at every step. Please start by reading the codebase and confirming where each item below lives, then propose a prioritized plan. PRE-LAUNCH BLOCKERS (do these first): 1. Individual user accounts. Replace the single shared HTTP Basic password with per-user authentication tied to the course purchase. Prefer a hosted auth provider (e.g. Cognito, Auth0, Clerk, or Supabase Auth) over building our own. Add: sessions with real server-side logout, password reset, MFA for admins, per-user IDs used for all data ownership and audit, and the ability to revoke or suspend one user. 2. Authorization on every request. Derive the current user from the server-side session, never from the client. Add ownership checks so a user can only read their own conversations, uploads, and results. Add an automated test proving user A cannot access user B's data. 3. Rate limiting and cost controls on /api/chat and /api/upload. Enforce server-side: requests per minute per user, global concurrency limit, max message-history length, max attachment size and extracted-text size, output-token cap, and a daily spend cap per user. Return HTTP 429 with Retry-After when throttled. Add AWS Budget and Bedrock quota alarms. 4. Health-safety guardrails outside the model prompt. Add a server-side layer that: detects medical emergencies and self-harm and returns escalation guidance; blocks or heavily gates prescription-tapering, pediatric-dosing, and personalized-dosage outputs; and labels uncertainty. Remove or clinically rewrite the built-in prompt templates that request tapering plans, child dosing, and specific supplement brands/doses. Add a regression test suite covering emergency, pediatric, pregnancy, psychiatric, medication-interaction, and oncology scenarios. 5. Privacy and data-handling. Add a plain-language privacy notice and a just-in-time consent step before the first upload. Implement per-user data export and deletion. Confirm and document whether AWS Bedrock model-invocation logging is enabled, and where request/response data and application logs are stored and for how long. Add Cache-Control: no-store to all endpoints that return health data. 6. Fix the misleading "save my Health CEO File" flow. Either implement real authenticated, encrypted per-user storage with retention/deletion, or change the copy to state clearly that files and chats exist only in the current session, show which attachments are active, confirm before clearing a conversation, and offer a local export. NEXT (after the blockers): 7. Add security headers on all responses: HSTS, a Content-Security-Policy including frame-ancestors 'none', X-Frame-Options, X-Content-Type-Options: nosniff, Referrer-Policy, and Permissions-Policy. 8. Make the public health-check endpoint return only a generic status (no provider/model details); normalize production API errors; return human-readable citation titles instead of internal filenames. 9. Add preview-before-send for prompt templates and a file-review step before upload. 10. Run a WCAG 2.2 AA accessibility pass: accessible names for the upload and send buttons, a live region for streamed responses, keyboard/focus testing, and larger mobile safety text. 11. Self-host fonts and load any third-party video only after user action or consent; set a strict referrer policy. For each item, tell me: the files you will change, the approach, the tests you will add, and anything that needs a decision from me (for example, which auth provider). Do not start coding item 1 until I approve the plan.