# Staff Access to User Content Policy

**Document type:** Internal control policy. Published for transparency.
**Owner:** Chief Medical Officer
**Reviewers:** Safety Officer · Privacy Officer · General Counsel
**Version:** 1.0.0
**Effective date:** 2026-06-11
**Review cadence:** Quarterly
**Public URL:** https://www.menthra.ai/downloads/staff-access-to-user-content.md

> Menthra publishes this internal control policy because the protections in it are part of the promise we make to users. Our public Privacy Policy and Consumer Health Data Privacy Notice reference this policy by name. This document carries the operational detail those references stand on — the role matrix, the trigger list, the access-logging requirement, the break-glass procedure, and the absolute limits in §8 that bind every Menthra staff member.

---

## 1. Purpose

To define who at Menthra may read user conversations, mood logs, clinical notes, and any other content created by a user in the course of using the platform ("**user content**"); under what conditions they may do so; how that access is logged and reviewed; and what they may **never** do with what they see.

The policy exists for three reasons:

1. **Trust.** Users tell Menthra companions things they have never told another human. That requires a discipline tighter than HIPAA's floor.
2. **Regulatory exposure.** Washington MHMDA, Nevada NHDPA, GDPR, DPDP, and HIPAA all require demonstrable role-based access controls. "We try to be careful" is not a control.
3. **Internal clarity.** Without a written matrix, individual staff make individual judgement calls. That is how the BetterHelp pattern starts.

---

## 2. Scope

Applies to **every Menthra employee, contractor, consultant, and intern** with technical access to any system that holds user content. Includes:

- Engineering and SRE
- Data, ML, and platform teams
- Care, Safety, and Clinical Quality
- Legal, Privacy, and Compliance
- Executive (CEO, CMO, COO, CFO, CTO, etc.)
- Customer Support
- Any vendor staff with delegated access under a signed BAA / DPA

Does **not** apply to:
- Licensed clinicians on the platform — they are bound by their own professional duties, scope of practice, and the Clinician Platform Agreement. Their access to their own clients' content is governed there, not here.
- Public-facing marketing or sales teams who never receive access to user content systems.

---

## 3. Definitions

**User content** — anything created by a user inside Menthra: chat transcripts (text, voice, video), mood and check-in logs, journals, AI Twin training inputs, payment records, profile information, support tickets, and inferences derived from any of the above.

**Trigger** — a specific, documented event that justifies access. No trigger, no access. Examples in §5.

**Reason code** — a short string the staff member selects when opening user content. Required at every access.

**Break-glass** — a documented emergency access path that bypasses normal approval. Used only in active crisis or where life-safety requires it. Every break-glass event is logged and reviewed within 24 hours.

---

## 4. Role-based access matrix

The default is **least privilege**: nobody has standing access to user content. Access is granted per-event, per-user, per-trigger.

| Role | Standing access? | What they can read on trigger | Approver |
|---|---|---|---|
| **CEO (Dinakara Nagalla)** | No | Anything, under a formal request with reason code. Used sparingly; logged and quarterly-reviewed. | Self-declared + CMO countersign |
| **Chief Medical Officer (Anjali)** | No | Clinical escalation cases · safety-flagged conversations · AI Twin accuracy review · quality audit samples · post-incident review | Self-declared as CMO; logged |
| **Safety Officer** | No | Safety-classifier-flagged sessions · formal user safety complaints · post-incident review · classifier accuracy audits | Self-declared as Safety Officer; logged |
| **General Counsel / Legal** | No | Subpoena / court order responses · litigation hold preservation · formal claims against Menthra · M&A under binding protections | Self-declared as Legal; logged. CMO must countersign for non-compelled access. |
| **Privacy Officer** | No | Data subject rights requests (access, deletion, portability) · regulator inquiries · breach investigations | Self-declared; logged |
| **Care team (on-call clinicians)** | No | Active crisis cases routed to them · sessions where a user is being escalated to human care | Crisis classifier trigger; logged automatically |
| **Clinical Quality team** | No | Sessions flagged by automated quality review · sampled audits (de-identified by default; re-identified only with CMO approval) | CMO; logged |
| **Customer Support** | No | The specific session a user has raised a support ticket about, AND ONLY after the user has explicitly authorized that session being reviewed | User authorization in-ticket; logged |
| **Engineering / SRE** | No | The specific session implicated in a reproducible bug, ideally with the user's consent. De-identified by default. Production debugging via raw user content requires Engineering Manager + Privacy Officer approval. | Eng Manager + Privacy Officer; logged |
| **Data / ML / Platform** | No | Aggregate, de-identified data only. Individual user content access requires the same approval path as Engineering. | Eng Manager + Privacy Officer; logged |
| **Marketing / Sales / Recruiting / People Ops** | **NO ACCESS — full stop** | Nothing. Even with approval. | N/A |

### A note on "self-declared" approvals

For senior roles (CEO, CMO, Safety, Legal, Privacy), access is self-declared because requiring multi-party approval would in practice prevent timely safety and legal action. The trade-off is that **every self-declared access generates a quarterly review item** examined by a peer officer — CEO accesses reviewed by CMO, CMO accesses reviewed by Safety Officer, etc.

---

## 5. Triggers — what justifies access

No staff member opens user content without a trigger from this list:

1. **Safety classifier flag** — automated event, logged independently
2. **Active crisis routing** — user is being escalated to human Care
3. **Formal user safety complaint** — user has reported a concern about their experience
4. **Quality audit (random sample)** — pre-scheduled, de-identified by default, sample size and methodology documented
5. **Targeted quality review** — investigating a specific clinical, safety, or accuracy concern across a defined set of sessions
6. **Post-incident review** — after a documented incident (crisis event, harm event, near-miss, outage affecting a specific user)
7. **User-initiated** — the user has asked us to review a specific session (support ticket, rights request)
8. **Lawful compulsion** — subpoena, court order, regulator inquiry under statutory authority
9. **Litigation hold** — preservation obligation triggered; read access limited to those with case need-to-know
10. **Reproducible engineering bug** — and only when de-identified data is insufficient
11. **AI Twin accuracy check** — for a specific clinician's twin, requested or consented by that clinician
12. **Break-glass emergency** — active crisis or imminent life threat, no time for normal approval (see §7)

Anything else — including curiosity, demos, executive interest without a documented business reason, or "I just want to see how it's going" — is **not a trigger**, and access is not granted.

---

## 6. Access controls and logging

Every read of user content in production systems is logged with:

- Staff member identity (SSO user ID)
- Role at time of access
- User account ID accessed
- Reason code selected (corresponding to §5)
- Timestamp (UTC)
- Whether de-identified or raw
- For break-glass: the specific emergency justification

Logs are immutable, retained for **at least 7 years**, and accessible to the Privacy Officer and General Counsel for review at any time.

### Quarterly review

The Privacy Officer compiles a quarterly access report. Reviewed by:
- A peer officer (per the cross-review rule in §4) for executive accesses
- The CMO for clinical/safety accesses
- The General Counsel for legal accesses
- The CEO for any access patterns that look anomalous

The report covers: total accesses by role · reason-code distribution · break-glass events · accesses without a clear matching trigger · patterns suggestive of policy violations.

### Audit findings

Any access without a valid trigger, or a trigger that does not match the reason code, is investigated. Outcomes range from required re-training (first offense, good faith) to immediate termination (deliberate misuse).

---

## 7. Break-glass — emergency access

Active crisis or imminent life threat can require user content access faster than the normal approval cycle allows. The break-glass path:

1. The staff member selects the **"BREAK-GLASS — life-safety"** reason code.
2. Access is granted immediately. No upfront approval.
3. The event triggers an automatic notification to: CMO, Safety Officer, Privacy Officer, on-call Care lead.
4. Within **24 hours**, the staff member files a written justification with the Privacy Officer.
5. The CMO and Safety Officer jointly review every break-glass event. Justified events are recorded; unjustified events are treated as policy violations under §10.

Break-glass is logged with the same fields as normal access plus the written justification.

---

## 8. What staff may never do with user content

Regardless of role or trigger, every staff member must observe these absolute limits. There are no exceptions:

- **Never share user content in any internal chat channel** (Slack, Teams, email threads) where the audience exceeds the people with a documented need-to-know on the specific event.
- **Never paste user content into prompts to external AI tools** (ChatGPT, Claude, Gemini, Copilot, any third-party model) for any reason. Internal tooling routed through our HIPAA-aligned AI infrastructure is the only acceptable path.
- **Never use user content in product demos**, sales pitches, fundraising decks, all-hands presentations, town halls, or any external communication — even anonymized or paraphrased. We use synthetic examples or explicitly consented user testimonials only.
- **Never use user content to train AI models** of any kind, ours or anyone else's. Training pipelines have separate, explicit, opt-in consent paths.
- **Never share user content with a user's employer, school, parent (for adult users), partner, or any other third party** outside the limited disclosures in the public Privacy Policy and Consumer Health Data Notice.
- **Never read your own family or friends' user content** without explicit written authorization from the Privacy Officer. Personal relationships create conflict-of-interest risk that overrides role-based access.
- **Never retain user content on a personal device** — laptops, phones, USB drives. Production access is in-platform only.
- **Never publish, post, or screenshot user content** for any reason. Internal documentation requires synthetic data.

Violation of any item in this list is grounds for termination.

---

## 9. Training and acknowledgement

Every Menthra staff member with access to user content systems must:

1. Read this policy as part of onboarding.
2. Sign a written acknowledgement (in HRIS) that they have read and understood it.
3. Re-acknowledge annually and whenever this policy is materially updated.
4. Complete a 30-minute training module covering the role-based access matrix, trigger requirements, and the absolute limits in §8.

The Privacy Officer maintains the acknowledgement register.

---

## 10. Violations

| Violation | First offense | Repeat |
|---|---|---|
| Access without a trigger (curiosity, no documented reason) | Written warning + re-training | Termination |
| Reason code mismatch (logged reason does not match actual purpose) | Investigation + corrective action | Termination |
| Sharing user content in unauthorized channels | Investigation; outcome depends on intent and harm | Termination |
| Sharing user content externally without authorization | Termination + legal action where warranted | — |
| Using user content for AI model training, marketing, or demos | Termination | — |
| Reading family/friend content without authorization | Termination | — |
| Failing to file break-glass justification within 24 hours | Written warning | Investigation |

The Privacy Officer escalates serious or repeated violations to the CEO. Where a violation may constitute a breach under HIPAA, MHMDA, NHDPA, GDPR, or DPDP, the General Counsel manages regulatory notification within statutory timeframes.

---

## 11. Cross-references

- **Public Privacy Policy** — `/legal/privacy`
- **Public Consumer Health Data Privacy Notice** — `/legal/consumer-health-data`
- **Public HIPAA Notice of Privacy Practices** — `/hipaa-notice`
- **Public Subprocessors list** — `/legal/subprocessors`
- **Clinician Platform Agreement** (clinicians' separate obligations) — internal contracts
- **Acceptable Use Policy** (covers staff use of the platform itself) — `/acceptable-use`
- **Information Security Policy** (logging infrastructure, retention) — internal `infosec/`
- **Incident Response Plan** (breach handling) — internal `infosec/`

---

## 12. Changelog

| Version | Date | Note |
|---|---|---|
| 1.0.0 | 2026-06-11 | Initial publication. Role-based access matrix · 12-trigger list · 24-hour break-glass justification · 7-year log retention · §8 absolute limits including no-external-AI-paste · quarterly cross-officer review. |

---

*This policy is reviewed quarterly. Material changes require sign-off from the CMO, Safety Officer, Privacy Officer, and General Counsel before taking effect. The Privacy Officer maintains the canonical version.*