Security at Lumo

Lumo runs on Vercel. Workspace data is stored in a Neon Postgres database in the United States (AWS us-east-1).

All traffic to Lumo is served over HTTPS.

Our hosting, database and file storage providers encrypt stored data at rest.

Access tokens for the services you connect (GitHub, Slack, Figma, Google Drive, Sentry) are additionally encrypted by Lumo with AES-256-GCM before they are stored.

Security scans run in short-lived, isolated virtual machines (Vercel Sandbox). The repository is cloned with a read-only token for that one repository, which is revoked right after the clone; network access is restricted while the scanners run, and the machine is stopped when the scan ends.

Sign-in, accounts and sessions are handled by Lumo's own authentication service and stored in Lumo's database. Sign-in codes are sent by email, and you can also sign in with Google.

Each workspace has owners and members. Only owners can change data retention settings or delete the workspace.

API keys for the Lumo CLI are shown once, when they are created, and stored only as a SHA-256 hash.

To review pull requests for security issues, write summaries and build team memory, Lumo sends code, diffs and agent session records to AI models. Every request goes through the Vercel AI Gateway. Except for boundary-crossing triage (below), zero data retention is enforced on the request itself: the gateway only routes to hosting providers that have a zero-data-retention agreement, and if none is available the request fails instead of falling back to one that would keep your data.

Boundary-crossing triage is the one exception. When Lumo's rules flag an action an AI agent took, Lumo asks TypeSafe's Jev model whether it was a legitimate part of the task, sending the flagged command or file path (with credentials redacted), the rule that fired, the task's title and description, and the agent's own explanation. Jev's only host, DigitalOcean, does not train on the data but does not offer zero data retention. Turning off AI review in workspace settings stops this triage.

Neither Lumo nor these providers train models on your data.

OpenAI's zero data retention allows limited retention for abuse monitoring (safety retention).

Zero data retention is each hosting provider's own policy, and a provider can exclude specific models or features from it; Vercel's documentation states that the gateway does not fail such requests. Lumo sends only text and does not use the features our providers list as exclusions, such as stored conversations, file or image inputs, hosted tools or batch processing. Providers may still cache parts of a prompt to speed up repeated requests: OpenAI keeps this cache encrypted for up to 24 hours.

Open-weight models (the DeepSeek and GLM families) are run by the hosting providers listed below. The model authors' own APIs never receive your data.

AI requests are routed globally, so processing may take place outside your region. Zero data retention applies wherever they are processed, and we do not currently commit to a processing location.

The Lumo hooks record what your agents do in each session: prompts, commands, file paths, the contents of files they read or write, and command output. Credentials found in a session record are redacted before it is stored, whatever the retention setting. By default the rest is stored as recorded, code included, and every member of the workspace can view it.

Workspace owners can export a workspace from workspace settings. The export is a zip file with the workspace's projects, milestones, sprints, tasks, comments, ideas, documents (including members' private documents), tags, team memory and member list. Its download link works for 7 days. It does not yet include everything Lumo stores: agent activity, pull request and security scan records, document comments and history, test cases and their runs, activity history, and uploaded files and images are left out.

When an owner deletes a workspace, the deletion waits 48 hours, during which any owner can cancel it; after that, all of its data and uploaded files are permanently deleted. An owner can also run the deletion at once. Deleted tasks and documents first stay in the workspace's trash for 30 days, where they can be restored.

Workspace owners choose how long each kind of data below is kept, under Data retention in workspace settings; other members cannot change these settings. Cleanup runs automatically at least once a day, and cleared content cannot be restored.

Session records are kept for as long as the workspace exists, by default. An owner can instead have their content cleared 30, 90, 180, or 365 days after each event. Events of a task that is not done yet are kept until it is done, and events that are evidence for a boundary crossing are kept. When content is cleared, the event and its statistics (cost, active time, files touched) remain.

An owner can also choose to discard session records once they are used up. In this mode code is not stored: file contents, command output and other tool input and output are replaced by their size and a SHA-256 fingerprint, while file paths, commands (heredoc bodies removed, up to 500 characters), prompts and agent messages with any code removed, edits to test files and error messages from failed commands (up to 2,000 characters) are kept. The rest is discarded 7 days after it is used up, that is, after its task is done or after 30 days with no agent activity. A completed task's records may be held for up to 30 days after completion while Lumo finishes reviewing the task, and records that are evidence for a boundary crossing are held until every such crossing has been dispositioned, plus 7 days.

A stricter session record setting applies only to records stored after the change. Records already stored keep the setting they were stored under.

Security scan evidence (the code a scan quoted, call chains, AI-written finding text and the pull request summary) is cleared 7 days after the pull request is merged or closed, by default. An owner can choose 0, 7, 14, or 30 days instead; with 0 it is cleared as soon as the scan finishes. If a pull request stays open, a scan's code is cleared 30 days after that scan finished. Each finding keeps its rule, file, line, severity and dispositions.

The original command, diff line and explanations behind a boundary crossing are replaced by a description without code 7 days after the crossing is dispositioned, by default; an owner can choose 7, 30, or 90 days. The category, severity and disposition are kept. A shorter period applies only to crossings dispositioned after the change.

When a pull request comment cannot be synced after all retries, Lumo keeps the GitHub webhook payload (comment text and diff context) for troubleshooting. By default it is removed 7 days after the failure; an owner can choose 7, 30, or 90 days. The event, pull request and error are kept.

Uninstalling the Lumo GitHub App, or removing a repository from it, clears the code stored with the affected security scans straight away, whatever the retention setting. The findings keep their rule, file, line, severity and dispositions.

Lumo uses AI to turn agent sessions into team memory, session summaries and run summaries. This is on by default. Before any of it is stored, code blocks and lines of code are removed and credentials are redacted. An owner can turn it off under Data retention: from then on no new memories or summaries are generated, and tasks reaching Done get no AI-written task claim (an agent's own report on its work is still kept). Each turn in a session record still gets a one-line summary, also stored without code. Content already generated is kept for as long as the workspace exists unless an owner deletes it; the retention periods above do not apply to it.

An owner can also delete what has been generated, after re-typing the workspace name. This deletes every memory in the workspace, including memories added by hand, together with its search embedding, and clears all session summaries and run summaries, the task claims generated from them and the explanations written for claim faithfulness checks. An agent's own report on its work is kept, and session records, tasks and documents are not affected. A deletion cannot be undone.

Scan evidence, crossing originals and failed-sync payloads stored before these rules were introduced are not yet cleared automatically.

Lumo records sensitive actions in each workspace in an audit log: member role changes and departures, invitations, changes to workspace, security and data retention settings and to the workspace logo, workspace exports and deletion requests, deletion of AI-derived content and session records, task template changes, connecting or disconnecting integrations (including personal GitHub, Figma and Google Drive connections and Sentry project mappings), creating and revoking personal API keys, changes to a document's visibility or public link, permanently deleting items from the trash, rulings on boundary crossings, security findings and test case defects, and exports of the audit log itself. Each event records who acted (or that Lumo itself did), when, from where (web, CLI or API, webhook or system), the IP address and user agent, and what was affected; invitation events also record the invitee's email address. Events hold identifiers and setting values, never the content of tasks, documents or code, and detected credentials are redacted before they are stored.

Audit events are deleted automatically 365 days after they are recorded, and with the workspace when it is deleted. They are included in the workspace export.

Only workspace owners can view the audit log, in workspace settings or with the Lumo CLI, and download it as a CSV file.

Lumo does not yet offer a workspace export that includes every record, encryption with a separate key for each workspace, or security certifications such as SOC 2.

The third parties that process customer data so that Lumo can run.

If you believe you have found a security vulnerability in Lumo, email hello@uselumo.ai with steps to reproduce it. Please give us reasonable time to fix it before disclosing it publicly.

The same contact is published in machine-readable form at /.well-known/security.txt.