Security
Introduction and Scope
1.
At Miller, security is a foundational requirement of the Service, not an afterthought. Miller is built to be a trusted home for the most personal data you create: the record of your daily thoughts, conversations, and work.
2.
This page explains how we approach security, the controls we have in place today, and where the program is headed as we move toward public launch.
3.
Operating entity. The Service is owned and operated by Memory Labs Inc., a corporation organized under the laws of the Republic of Korea.
Our Security Commitment
1.
Collect less. We capture only the information we need to deliver the Service.
2.
Protect what we hold. Your data is encrypted at rest and in transit, and we apply strict access controls to production systems.
3.
Stay transparent. We document our security practices publicly and update them as the Service evolves.
4.
Keep you in control. You own your data and can export, edit, or delete it at any time.
Data Protection
1.
Encryption in transit. Every connection between your device and the Service is protected by TLS 1.2 or higher.
2.
Encryption at rest. Data stored in our databases and object storage is encrypted with AES-256 server-side encryption from our cloud provider (AWS).
3.
Secrets management. API keys, credentials, and cryptographic material are stored in a centralized secrets manager and rotated on a regular schedule.
4.
Data minimization. Miller captures only what it needs to serve you. You control every capture source (voice, screen, calendar, and others) individually.
5.
No sale of your data. We do not sell your data, and we do not use it to train third-party AI models without your explicit consent.
6.
Control over your data. You can export your full record at any time, delete individual items or your entire account (permanent once the standard recovery window passes), and pause or turn off any capture source whenever you want.
Infrastructure Security
1.
Cloud provider. The Service runs on Amazon Web Services (AWS), in regions independently certified for SOC 2 and ISO 27001.
2.
Network isolation. Production workloads run in dedicated AWS Virtual Private Clouds (VPCs) with strict inbound and outbound controls. No production resource is exposed to the public internet without explicit allow-listing.
3.
Logging and monitoring. Production environments emit centralized logs and security telemetry. Automated alerts cover security-sensitive events, including authentication anomalies, configuration drift, and error-rate spikes.
4.
Backups and recovery. We back up production data on a regular schedule, with documented restoration procedures and periodic restore testing.
5.
Change management. We make infrastructure changes through version-controlled code (infrastructure-as-code), review them before merge, and apply them through auditable deployment pipelines.
Access Control
1.
Least-privilege access. Engineers get only the access their role requires. Production database and infrastructure access is limited to a small group of designated people.
2.
Multi-factor authentication (MFA). We require MFA on all critical internal systems, including AWS, GitHub, Google Workspace, and any service that holds production credentials.
3.
Quarterly access review. We review access to all in-scope systems at least every quarter and revoke anything unused or unnecessary.
4.
Offboarding. We revoke all access within our established SLA when an employee or contractor leaves, following documented offboarding checklists.
5.
User authentication. The Service supports modern authentication, including secure password storage (industry-standard hashing) and OAuth sign-in with trusted identity providers. Sessions use short-lived tokens with refresh, automatic expiry on inactivity, and forced sign-out on suspicious activity.
Secure Development Practices
1.
Code review. A second engineer reviews every change to production code before it merges.
2.
Dependency scanning. We continuously scan open-source dependencies for known vulnerabilities, with automated alerts and remediation tracking.
3.
Static and dynamic analysis. We scan the code base for common security weaknesses using industry-standard tooling built into our continuous-integration pipeline.
4.
Pre-launch security review. Before any feature involving sensitive data ships, it goes through a documented security review.
5.
Secret hygiene. We scan source repositories for accidental secret exposure and follow documented rotation procedures whenever an exposure occurs.
Compliance and Certifications
1.
SOC 2 (AICPA, USA). A Type 2 audit is actively underway, targeting completion before public launch.
2.
PIPA (Republic of Korea). Memory Labs Inc. operates under Korea's Personal Information Protection Act. Our data handling, retention, and breach response practices are designed to align with PIPA requirements.
3.
AWS underlying compliance. The Service runs on AWS, which maintains SOC 1, SOC 2, SOC 3, ISO 27001, ISO 27017, ISO 27018, and other certifications, each independently audited by third parties.
Incident Response
1.
Documented plan. We maintain a written Incident Response Plan that defines roles, communication protocols, and steps for containment, recovery, and post-incident review..
2.
User notification. If a security incident affects your data, we will notify you without undue delay, in line with applicable law, including PIPA timelines.
3.
Post-incident review. After every material incident, we complete a written root-cause analysis and a documented set of corrective actions, reviewed by company leadership.
4.
Tabletop exercises. We periodically run internal exercises against simulated incidents to test the plan and the team's readiness.
Privacy and User Rights
1.
Privacy Policy. Our Privacy Policy explains what personal data we collect, how we use it, and the rights you have. Read it at trymiller.com/privacy.
2.
Purpose limitation. We process personal data only for the purposes described in the Privacy Policy.
3.
Your rights. You have the right to access, correct, delete, and port your personal data, in accordance with applicable law.
4.
No sale to advertisers or data brokers. We do not sell your data to advertisers or data brokers.
5.
Honoring requests. We honor verified user requests in accordance with PIPA and applicable US state law where relevant.
Third-Party Services and Sub-Processors
1.
Vendor curation. The Service is built on a curated set of trusted third-party services. Before we engage a sub-processor, we assess its security posture and contractual commitments.
2.
Main categories. Our main sub-processors cover cloud infrastructure (AWS), AI inference providers, communication and collaboration tools, and operational tooling.
3.
Sub-processor list. A current sub-processor list is available on request, and we will publish it at trymiller.com/security at commercial launch.
Responsible Disclosure
1.
How to report. We welcome reports of potential security vulnerabilities from researchers and users. Send reports to contact@trymiller.com.
2.
Acknowledgement. We will acknowledge your report within 5 business days.
3.
Validation and response. We will work with you to validate, reproduce, and respond to the report, and we will keep you updated on remediation status.
4.
Good-faith protection. We will not take legal action against researchers who act in good faith and follow this process.
5.
What we ask of researchers. Please (a) don't access or modify data that isn't yours, (b) don't run attacks that could degrade service for other users, and (c) give us reasonable time to remediate before disclosing publicly.
Contact
1.
Security questions and vulnerability reports: contact@trymiller.com
2.
Privacy questions and data requests: contact@trymiller.com
3.
General inquiries: contact@trymiller.com
4.
Operating entity (Korea): Memory Labs Inc., Seoul, Republic of Korea
5.
Parent entity (USA): Memento AI Inc., Delaware, United States of America