Loam is built on memory — the team remembers you so it can do real work across sessions. That only earns trust if you can see exactly what's stored and remove it on demand. This is the straight version: what we do, what we don't, and where the line is. No varnish.
Before the detail below, here is the short version of who can see your data, what protects it, and where the honest gaps are. Every line is expanded further down the page.
Can another user see my data?
No. Every request is scoped to your account. The system won't even confirm whether another account's data exists — cross-account access returns not found, not forbidden.
What if the database is breached?
Your credentials, conversation content, team memory, and project context are field-encrypted at rest (Fernet), with the key held outside the database. Passwords are bcrypt-hashed, never stored in the clear.
Does my source code leave my machine?
Only what you hand over. Loam does not scan or upload your repository by default. Workspace Indexing, which sends a snapshot, is opt-in and off by default.
Who runs the AI, and is my data sold?
Anthropic Claude (your own key) and Gemini (your key, server-side) perform the work. Your content is never sold, used for ads, or used to train Loam-owned models.
Can I get it all back out, or delete it?
Deletion is fully in your hands — one member, one project, or your whole account behind a phone code. A one-click export isn't built yet; we say so plainly below.
What happens if I leave?
Account deletion runs as one all-or-nothing transaction across your memories, sessions, projects, settings, and credentials. It is permanent — no recovery.
To remember your project and pick up where you left off, Loam stores the working material of your sessions. All of it lives in our database, scoped to your account:
Your conversation content, team memory, and project context are field-encrypted at rest with the same Fernet encryption that protects your credentials — stored as ciphertext, with the key held outside the database. What we leave in plaintext is the lookup metadata recall needs to work: display names, the phone number we match a return call against, and the keyword tags and short summaries the memory index searches. Encrypting those would break search and recall, so they stay queryable behind strict per-account isolation. We'd rather tell you exactly where that line sits than imply more than we do.
The whole picture in one table — what each kind of data is, whether it's stored, whether it's encrypted at rest, whether it stays searchable, and whether you can delete it.
| Data type | Stored? | Encrypted at rest? | Searchable? | User-deletable? | Notes |
|---|---|---|---|---|---|
| Account basics (email, name, phone) | Yes | No | Yes | Yes | Phone is used for sign-in codes and team calls. Removed on account deletion. |
| Password | Hash only | bcrypt + salt | No | Yes | Never stored in the clear. We cannot read it. |
| Session transcripts | Yes | Field-encrypted (Fernet) | No | Yes | Includes documents, code, and audio produced in the session. |
| Team memory & project context | Yes | Field-encrypted (Fernet) | Index only | Yes | Content is ciphertext; only the keyword tags / short summaries the index searches stay plaintext. |
| Recall metadata (names, phone-match, tags, summaries) | Yes | Plaintext | Yes | Yes | Left queryable on purpose so search and return-call matching work; protected by per-account isolation. |
| Credentials (API keys, GitHub/OAuth tokens) | Yes | Field-encrypted (Fernet) | No | Yes | Decrypted only for the moment an action runs; key lives outside the database. |
| Call transcripts | Yes | Plaintext | No | Yes | Stored as plaintext for memory synthesis (not field-encrypted like session content). Full call record deleted at 90 days, or on account deletion. |
| Call recordings (audio) | If fetched | No | No | Yes | Stored only for calls that completed (non-voicemail, with a conversation ID). Cleared from the database after 30 days; status becomes “expired.” Full call record deleted at 90 days, or on account deletion. |
| Source code | Only if shared | As session content | No | Yes | No default repo scan. Reaches Loam only via paste, attach, a workflow that needs it, or Workspace Indexing (opt-in, off by default). |
| Payment-card details | No | — | No | — | Handled by our payment processor. We keep only a customer reference. |
Each voice feature follows its own storage model. The table below shows exactly what’s retained, how long, and whether records expire automatically.
| Feature | Transcript | Audio storage | Audio cleared | Record cleared | Notes |
|---|---|---|---|---|---|
| Meet the Team | Plaintext | Database (binary, if fetched) | 30 days | 90 days | Recording stored as nullable binary. Cleared automatically; status becomes “expired.” User-deletable via account deletion. |
| Call Team | Plaintext | Database (binary, if fetched) | 30 days | 90 days | Same model as Meet the Team. Trigger = manual; source = ide. |
| ReachOut | Plaintext | Database (binary, if fetched) | 30 days | 90 days | Automated and on-demand triggers share the same model and retention schedule as above. |
| Morning Read | — | Server file (path in database) | Account deletion | Account deletion | No auto-expiry. Email download links expire after 48 hours. In-app download requires an active session. |
| Studio | — | Server file (path in database) | Account deletion | Account deletion | No auto-expiry. Email download links expire after 72 hours. In-app download requires an active session. |
When you connect a service like GitHub, that token is encrypted at rest and decrypted only for the moment an action runs — never cached between operations.
Right now, the team provisions and runs your infrastructure under Loam's AWS and Cloudflare accounts — the AWS line in your plan is paid to us, in good faith, for the pipes that run your work. You never hold the keys, and you never get a surprise cloud bill. Bring-your-own AWS and Cloudflare API keys are planned for September 2026 — run it all under your own accounts and your own billing, whenever you choose to switch.
Most of your data doesn’t auto-expire — your memories, session content, and project context stay until you remove them, because continuity is the whole point. The exception: audio recordings from phone calls (Meet the Team, Call Team, ReachOut) are cleared from the database after 30 days, and the full call record is deleted at 90 days. A one-click data export isn’t built yet; it’s on the roadmap. Until then, deletion is fully in your hands through the controls above.
Account deletion is permanent with no recovery. Once your account is erased, the team cannot restore it. Infrastructure backups exist for disaster recovery only and are not used to restore individual deleted accounts. Disaster-recovery snapshots may contain deleted data until those snapshots expire. Current backup retention window: 7 days.
Loam does not scan or upload repositories by default. Source code reaches Loam only when you paste it, attach it, start a workflow that requires it, or enable Workspace Indexing. Workspace Indexing is opt-in and off by default.
| Workflow | Reads local files? | Sent to Loam? | Stored? | Default |
|---|---|---|---|---|
| Normal session | Pasted or typed content only | Yes, if you provide it | Session history | On |
| Build Mode | Files required for requested milestone | Yes, via session context | Session history | User action |
| Code Review | Diffs and review anchors | Yes, via session context | Review findings and anchors | User action |
| Workspace Indexing | Full project tree and file contents | Yes, to assemble session context | Not persisted in Loam's database | Off by default |
A future version of Loam will support organizational accounts where memory is institutional and shared across team members. That model is in development and does not exist today. All memory is currently per-user and isolated.
Loam uses external model APIs to perform coding, review, synthesis, memory, and voice-related workflows. Depending on the feature, session content, code snippets, documents, prompts, or generated outputs may be sent to those providers to complete the requested task.
Loam does not sell customer data, use customer content for advertising, or train Loam-owned models on customer content.
Provider retention and training behavior is governed by each provider's API terms and Loam's account configuration with that provider. Customers should review those provider terms as part of any security or procurement review.
That the team knows your name, your project, and the decision you made last quarter is the product, not a side effect. The deal is simple: it's yours, it's isolated to your account, and you can wipe it whenever you want. If anything here raises a question, ask — a real person answers.
Claims on this page were last checked against the source on 2026‑07‑20, in the team's 60th code‑review pass. We stamp the date rather than tell you it is current — if the platform has moved since, this page has not yet been re‑verified.