Trust & legal

Security Overview

This document describes how Milly Lab protects data, what third parties receive, and where the current limits are. It is for customers evaluating Milly Lab and for anyone assessing it on a customer's behalf.

Milly Lab holds no security certification. This is a statement of practice, not an audit result. No claim of SOC 2, ISO 27001, HIPAA or GDPR compliance is made anywhere in this document, because none has been verified.

#Authentication

• Sign-in is by email and password, or Google sign-in.
• Passwords are stored as one-way hashes. Milly Lab cannot read your password.
• Access tokens are valid 60 minutes; refresh tokens 30 days.
• Tokens are held in browser local storage.

Session revocation

Every token carries the account's revocation version. Signing out, changing a password, or resetting a password increments that version, and every token minted earlier stops working immediately — across all devices.

This matters because it means a stolen token has a bounded life that the user can end themselves. A password change is a genuine remedy, not a cosmetic one.

Deactivating an account takes effect at once: every authenticated request re-checks the account's active status.

#Data isolation

Every request resolves to an authenticated user, and every query for user-owned data is constrained to that user. Conversations, sessions, generated assets, usage records and workspace connections are scoped to their owner.

Team content is visible to team members by design. Anything shared into a team workspace is visible to everyone in it.

#Encryption

• In transit — HTTPS to Milly Lab, and to every third-party provider.
• Connected-workspace tokens — encrypted at rest with Fernet symmetric encryption, using a key held in the server environment rather than in the database.
• Database and object storage at rest — provided by Railway and Cloudflare R2 respectively.

In production the application refuses to start unless the workspace-token encryption key is configured and valid — the encrypted-at-rest statement above does not depend on deployment configuration.

#What third parties receive

Milly Lab cannot answer a prompt without sending it to a model provider. What you submit — prompts, conversation history, attachments, and the contents of files read from a connected workspace — goes to the provider of the model you selected.

The complete list, with what each receives and where it processes, is the Subprocessor List.

#Connected workspaces

The highest-risk surface, and the one with the most deliberate design.

Permissions

The GitHub position is disclosed plainly to users in the Connected Workspaces Guide and the Privacy Policy rather than glossed over.

The staged-write property

A run cannot modify a user's repository. Writes during a run go to a staging overlay attached to the session, never to the provider. Applying is a separate, explicit, user-initiated action.

This is the security boundary that matters most: a model that behaves unexpectedly — or that is manipulated by malicious content inside a repository it is reading — still cannot commit anything. The worst outcome is a bad proposal the user declines.

Supporting controls:

• Path confinement. File paths are validated at the tool boundary and re-validated at apply time, and percent-encoded when sent to the provider. A path attempting to escape the selected repository is rejected.
• Conflict detection. The version of each file when read is recorded. If it changed in the meantime, that file is reported as a conflict and left alone rather than overwritten.
• Apply claiming. Concurrent applies are rejected, so a double-click cannot produce duplicate commits. The claim self-expires so a failure cannot wedge the session.
• No apply mid-run. Applying while a run is still executing is refused.

#Other controls

• Server-side URL validation on user-supplied reference image and video URLs, so Milly Lab cannot be induced to fetch internal network addresses.
• Rate limiting on authentication and other sensitive endpoints.
• Spend gating. Every billable operation passes a metering gate before a provider is called, so a runaway or hostile client cannot generate unbounded cost against Milly Lab's provider keys.
• Idempotent webhook processing, so a retried event cannot be applied twice.
• Administrative audit logging. Privileged console actions, including impersonation, are recorded.
• Interactive API documentation is disabled in production.

#Reporting a vulnerability

Email pending.

Please do not test against other users' accounts or data.

#Known limitations, stated plainly

An evaluator will find these anyway. They are listed here rather than discovered.

1. No third-party security certification. No SOC 2, no ISO 27001, no penetration-test report.
2. The GitHub OAuth scope is broader than the access Milly Lab uses. Described above.
3. Account deletion is deactivation. It does not erase conversations, generated assets, usage records or stored workspace tokens; contact us to have data removed.
4. No data-retention schedule. Content is kept indefinitely; there is no automated deletion.
5. No self-service data export. Export requests are handled by contact.
6. Content sent to model providers cannot be recalled. Once transmitted it is governed by that provider's retention policy.
7. Access tokens are held in browser local storage, which is readable by JavaScript running on the page. The 60-minute lifetime and revocation-on-logout limit the exposure.
8. No formal incident-response plan is published.
9. Single hosted region and a single web process. No documented disaster-recovery position.
10. No SLA is offered.