Confidential · Security & Safety Review

MAHAi-Movie Mind: Pre-Launch Review

An independent, authorized review of the app before it goes public. The AI itself behaves well. The gaps are in the platform around it: identity, abuse controls, privacy, and health-safety guardrails.

Target www.mahaimind.com Date August 4, 2026 Method Authorized black-box review
Overall risk: HIGH — not launch-ready as-is

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. 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. 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. 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. 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. 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

HighBehavior contradicts the “not medical advice” disclaimerClinical + Eng
WhyOne-click templates request diagnoses, prescription tapering, child-specific dosing, and an SSRI-alternative plan with no self-harm screening. These are personalized recommendations, not education.
FixServer-side clinical safety layer; remove or rewrite the high-risk templates; add a health-scenario regression suite.
HighPrivacy promises with no data-governance behind themPrivacy + Legal
WhyUsers are asked to upload bloodwork, DNA, medication lists, and children’s records, but there is no privacy policy, consent, retention or deletion. “Not persisted” cannot be proven from outside; logs and AI-provider logging may still capture everything.
FixPrivacy notice + just-in-time consent; document processors and logging; implement delete and export.
High“Save my Health CEO File” is technically falseEng + Product
WhyThe client keeps files in memory only. “New conversation” wipes everything with no confirmation, and a page reload loses it. Users think their medical context is remembered when it is not.
FixPick one model: honest ephemeral (drop “save,” confirm clears, offer export) or real per-user storage.
HighOne shared, weak credential is the whole access systemEng
WhyAll customers share a single, low-entropy password (currently a deliberate test gate). No accounts, revocation, quotas, or audit trail. One forwarded password exposes the entire service.
FixPer-user identity tied to the purchase; sessions, MFA for admins, revocation, audit IDs. Rotate the shared password at cutover.
HighNo observable rate-limiting or cost controlsEng
WhyEvery chat call hits a paid AI model. No throttle headers, no caps on message size or attachments, and attachments are re-sent every turn. Abuse cannot be attributed because everyone is the same user.
FixPer-user and global rate limits, size and token caps, spend caps, AWS budget and quota alarms, 429 responses.

Medium severity · 5

MediumConsequential actions fire instantly, with no previewProduct / UX
WhyClicking a template submits a long prompt; selecting a file uploads and sends it immediately; “new conversation” deletes state without confirmation. In a health app these are not harmless clicks.
FixEditable templates, a file-review step, an active-attachments view, and confirmation before destructive clears.
MediumMissing browser security headers; health responses cacheableEng
WhyNo HSTS, CSP, frame protection, or nosniff. The app is frameable (clickjacking), which matters more when one click can send a prompt or upload. The upload response has no no-store.
FixAdd the standard header set, frame-ancestors ‘none’, and Cache-Control: no-store on health-data responses.
MediumThird-party scripts load before any privacy disclosureEng + Privacy
WhyGoogle Fonts and a video script load with no referrer policy or notice, revealing to third parties that a visitor is on a health course.
FixSelf-host fonts, load video only on user action or consent, set a strict referrer policy, disclose processors.
MediumAccessibility gaps on key controls and safety textEng + Product
WhyUpload and send buttons have no accessible names, the streamed reply has no live region, and the mobile disclaimer shrinks to roughly 10.5px.
FixA WCAG 2.2 AA pass: labels, live regions, keyboard and focus testing, larger safety text.
MediumMarketing and course claims need substantiationLegal / Marketing
WhyClaims like “read every medical paper ever written,” “already private,” and adding “ten or fifteen healthy years” are objective health and privacy claims with no evidence shown.
FixAdvertising counsel and clinical review of every health, privacy, and longevity claim; remove absolutes.

Low severity · 2

LowPublic endpoint leaks the backend stack; verbose errorsEng
WhyA health-check URL returns, with no login, the AI provider and exact model in use. Malformed requests return detailed framework errors, and source citations expose internal filenames.
FixReturn a generic status publicly, normalize production errors, show citation titles rather than filenames.
LowUX does not support a long-running health workflowProduct / UX
WhyNo course progress or resume, no durable conversation list, no attachment manager or export. Prompt behavior is hidden until after it has been sent.
FixAdd progress and resume, conversation history, attachment context, and exportable summaries.

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.

claude-code-prelaunch-prompt.txt
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.
Before you share this link: a .pages.dev URL is public to anyone who has it. This page is set to no-index so search engines skip it, but the link itself is the only protection. For anything beyond a trusted recipient, put Cloudflare Access (free email-gated login) in front of it.