Review Loam's deployment and data boundaries.

The ten questions, answered first.

If you have two minutes, this is the whole review. Each row links to the detail below. Every answer reflects the platform as it runs today — roadmap items are labeled as such.

Two standard components. An optional collaboration helper.

The standard Loam setup consists of a VS Code extension and a user-profile MCP (Model Context Protocol) process. Optional Codex collaboration is a separate, explicitly approved helper. Neither is a kernel driver or Loam Windows service. The optional PowerShell installer is a separate setup path and may require temporary elevation to add prerequisites.

• Marketplace path: Install the VS Code extension from the Marketplace without running any external script. This is the lowest-friction, least-privileged path.
• Signed PowerShell installer: Currently documented to run from an elevated prompt. It installs the plugin tree and dependencies, registers the MCP server and hooks, and may add Node.js, Claude Code, Chromium, and Playwright tooling when absent. Inspect it before running: irm https://loam.team/api/ide/download/installer -OutFile docpro-install.ps1, then verify the Authenticode signature and published SHA-256. Then run the file you checked through a PowerShell process whose execution policy is AllSigned: powershell -ExecutionPolicy AllSigned -File .\docpro-install.ps1. The publisher prompt, and what to do if the file is still refused, are under Installer signing below.
• Windows only today: The automated installer is Windows-only. macOS is under development.

Per-user keys. Server-side revocation.

Access is controlled by API keys scoped to individual accounts. Keys start with dp_ and are generated in the Loam settings panel. Authorized Loam administrators can revoke access by disabling a user’s account; organizational customer-admin controls are not shipped today.

• JWT authentication: 8-hour expiry, server-side token version revocation. A revoked session cannot reconnect even if the JWT has not yet expired.
• Account lockout: Repeated failed login attempts trigger lockout stored in the database (not in-memory, enforced across all server workers).
• MFA on sensitive operations: Account deletion and phone number changes require multi-factor authentication.
• Phone orders: Caller ID selects the account, then a text code and email phrase verify it. Enrolled callers can use Duo approval as the second factor on Meg’s line. Codes go only to registered contact details, with server-enforced attempt limits. Email orders are matched to the account before work is accepted.
• Quiet hours: On by default and controlled only by the account holder. Ordinary outbound calls and texts are held outside 8 a.m.–9 p.m. in the recipient’s time zone; an explicitly requested callback or message can honor that request outside the window. A call the team marks urgent — something went wrong with your work, or a password or key may have leaked — can also come through; a text never does. Turning quiet hours off permits any hour and retains the consent requirement.
• Credential separation: Loam IDE keys and customer Anthropic keys are per-account. Loam-managed provider and infrastructure credentials are platform credentials held separately from customer accounts.

Customer access is isolated per account.

Customer-facing queries scope records to the authenticated account, so one customer cannot read another customer’s data. Authorized Loam administrators can access cross-account call logs and transcripts for service operation and support.

• No customer-to-customer reads: Team memory, project context, and session data are scoped to the authenticated account. Organizational customer-admin access is not shipped today.
• Credential encryption: API keys, OAuth tokens, and SSH keys stored by Loam are encrypted at rest with Fernet symmetric encryption. The encryption key is an environment variable on the server, not stored in the database.
• Passwords: Hashed with bcrypt. Never stored in plaintext.

What leaves a developer’s machine.

Developers interact with Loam through its full workspace, compact VS Code sidebar, and Claude Code. Here is what transmits to Loam's servers during a session:

• Session content: The text of what a developer types or pastes into a Loam session — described tasks, questions, context they provide. This is stored as session history.
• Project context: Descriptions of the project a developer is working on, saved by the team across sessions. Not automatic file scanning — only what a developer explicitly shares.
• Team memory: Team observations across sessions — preferences, architecture decisions, corrections noted by the AI team. Developer-controlled and deletable.
• API key (for setup): The Loam API key (dp_ prefix), entered once during install and stored in the local MCP configuration.
• Source code is not scanned or uploaded by default. Loam does not scan or upload repositories by default. Source code reaches Loam only when a developer pastes it, attaches it, starts a workflow that requires it, or enables Workspace Indexing. Workspace Indexing is opt-in and off by default. When enabled, it scans the local project and transmits an index to Loam to assemble session context; the index is not persisted in Loam’s database.
• No telemetry or analytics agents: The VS Code extension and MCP server do not send usage telemetry, keystroke logging, or file access data to Loam.

Granular deletion, with explicit boundaries.

Developers can clear a team member’s memory, delete entire projects, or delete the live database records tied to their account. Account deletion requires MFA and also removes Reception report and attachment files. Generated audio and managed infrastructure have separate cleanup boundaries.

• Delete a team member’s memory: Each team member’s memory is one stored record and is cleared in full, per team member. Removing a single line means rewriting that memory without it — there is no per-entry delete.
• Delete individual projects: Remove a project and its associated context.
• Account deletion: Deletes the account’s Loam database records and stored credentials behind MFA, including Reception work orders and intake and backlog records. The account’s Reception report and attachment files are then removed from Loam’s server. Generated audio requires Loam-operated cleanup. Teardown, export, or transition of Loam-managed infrastructure is governed by the applicable plan or order; copies delivered to an inbox or customer repository remain there.

Where Loam runs today.

Loam is hosted on AWS Lightsail in the us-east-1 region. The backend is a Python/FastAPI application behind nginx. Infrastructure is managed by Loam; developers do not have access to the underlying servers.

What Loam reaches out to.

All traffic is outbound HTTPS. No inbound ports are required. Some live session features use WebSocket or SSE over TLS — environments that block WebSocket/SSE traffic should allow it for loam.team and docpro.cloud.

Gemini API calls for image generation originate from Loam’s backend servers, not the developer’s machine. No Gemini traffic allowlisting is required on developer workstations.

The table above covers runtime destinations. The PowerShell setup path may additionally require Microsoft Marketplace or winget endpoints, the npm registry, and Playwright browser-download hosts. Confirm the enterprise allowlist against the exact installer version being approved.

What crosses the boundary — and what doesn’t.

Three zones: your machine, Loam, and the providers reached server-side. Everything past the first arrow is outbound HTTPS only — nothing reaches back in.

Paths, logs, and removal.

What’s on the roadmap for IT.

• Bring-your-own cloud: Planned, not shipped. Current hosted work runs in Loam-managed AWS and Cloudflare accounts.
• Data export: A mechanism for users to export their data before deletion. Planned but not yet available.
• Retention policies: Automatic expiry or archival of session data on a configurable schedule. Planned.
• Customer-facing audit log: A per-user action history (sessions, settings changes, deletions) exposed through the Loam interface. Planned.

A separate, explicitly approved local helper.

Codex collaboration is off by default. Updating the extension does not install Codex, install or start the helper, or authorize delegation. Connect Codex opens a new Codex conversation for the registered Loam project after any required helper setup is approved. Send any word in that tab; Codex and the Loam chat confirm the connection before the card reads Connected. The connection lasts for that Loam session. Connecting and assigning work are separate choices.

Loam also adds %LOCALAPPDATA%\Loam\bin to your PATH so the Codex command line can be found. The Codex extension bundles it but does not put it there.