Security Overview

Security at MHLE

MHLE uses a defense-in-depth approach to protect account information, educational content, institutional records, and service operations. This overview describes current control categories without exposing credentials, private infrastructure details, or information that could weaken security.

No security program can eliminate every risk. Controls are reviewed and updated as the application, vendors, threats, and legal requirements change.

Application and Hosting Architecture

MHLE is delivered as a Python/Flask application behind a production WSGI server. Persistent application data is stored in a managed relational database. Redis supports rate limiting and selected cache or progress functions. Managed object storage is used for designated documents and assets. Third-party AI and business services are disclosed in the Subprocessor List.

The production hosting platform terminates HTTPS connections. Application responses add security headers, restrict cross-origin access to configured origins, and limit framing except where approved LMS/LTI embedding is required.

Identity and Access Management

Current identity controls include:

• Passwords stored using one-way password hashing rather than plaintext.
• Signed, time-limited authentication tokens for application sessions.
• Server-side authorization checks for user, instructor, coach, parent, organization, partner, external API, and administrator functions.
• Multi-factor authentication capability for privileged administrative access.
• Rate limits on authentication and application endpoints.
• Account-state checks, parental-consent restrictions, and role-aware access gates.
• Audit records for selected privileged, consent, sharing, subscription, and compliance actions.

Customers are responsible for maintaining authorized user rosters, removing access when no longer needed, and protecting credentials and connected LMS or Google accounts.

Data Protection

MHLE applies data-protection controls that include:

• HTTPS encryption for data transmitted between supported clients and the service.
• Managed-provider protections for database and object-storage infrastructure.
• Application-level encryption for selected sensitive fields and secrets.
• File-type, file-size, and content validation for supported uploads.
• HTML sanitization and safe rendering for user- and AI-generated content.
• Data minimization and role-scoped access for education records.
• Account, organization, and privacy-request deletion workflows.
• Backup and restoration testing for recoverability.

Detailed retention and deletion terms are described in the Privacy Policy, Transparency Notice, and applicable DPA.

Secure Development and Change Management

The repository contains automated tests and security-focused controls covering areas such as authentication, parental consent, privacy rights, sharing, migrations, document integrity, moderation, and recovery. Security practices include:

• Dependency and vulnerability review.
• Credential and secret scanning.
• Database migration integrity testing.
• Code review and regression testing before release.
• Feature flags for controlled rollout of selected AI capabilities.
• AI model inventory and quality evaluation.
• Documented vulnerability remediation and exception tracking.

The scope and depth of testing vary by release. Passing automated tests is one input to risk management and is not a guarantee that the software is vulnerability-free.

Monitoring and Incident Response

MHLE records application errors, requests, selected administrative actions, email delivery, usage events, and security/compliance findings. Health checks and scheduled reviews support operational monitoring.

The incident process is intended to:

1. Receive and triage reports.
2. Contain and investigate suspected events.
3. Preserve relevant evidence.
4. Assess affected systems and data.
5. Remediate and restore service.
6. Notify customers, individuals, regulators, or other parties when required by contract or applicable law.
7. Record lessons learned and corrective actions.

Vendor and AI Security

MHLE relies on hosting, database, cache, email, payment, identity/integration, and AI providers. Vendors that process customer data are tracked in the subprocessor inventory and reviewed according to the vendor-management process.

For AI-enabled features, MHLE sends the provider the content needed to perform the requested operation. The service applies input safeguards, output handling, model selection, and usage or cost tracking. Users should independently verify important AI-generated claims.

Assurance Status

• MHLE maintains internal control mappings and an evidence repository.
• SOC 2 readiness work is in progress; this page does not claim that MHLE currently holds its own SOC 2 Type II report.
• An independent penetration-test report should not be represented as available until the planned engagement is complete and evidence is on file.
• Infrastructure-provider certifications do not automatically certify MHLE's application or operating controls.

See the Compliance Status Page for the current public posture.

Reporting a Security Issue

Report suspected vulnerabilities to contact details withheld pending approval and follow the Responsible Disclosure Policy. Do not include student data, passwords, API keys, or unnecessary personal information in an initial email.

Review Note

This document remains Draft pending validation of hosting details, contact inboxes, control ownership, and approval by MHLE leadership.