What you need to know before you approve this.

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 components. Both user-space.

Loam consists of a VS Code extension and an MCP (Model Context Protocol) server. Neither installs system services, modifies kernel drivers, or requires permanent elevated rights.

• 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: Installs Node.js dependencies and registers the MCP server. For managed or security-reviewed environments, inspect before running: irm https://loam.team/api/ide/download/installer -OutFile docpro-install.ps1, then verify the Authenticode signature and the SHA-256 hash published below. The convenience one-liner is on the Get Started page, after the verification steps.
• 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. Administrators can revoke access by disabling a user's account.

• 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.
• No shared credentials: API keys are per-account. There is no shared service account or team-wide key.

Per-account isolation enforced at every query.

Every database query that returns user data filters by user_id. Attempting to access another user's data returns 404, not 403 — this prevents account enumeration.

• No cross-account reads: Team memory, project context, and session data are scoped to the authenticated account. There is no admin query surface that exposes one user's data to another user.
• 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 the 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 down to full erasure.

Developers can delete specific memories, entire projects, or their full account. Account deletion cascades across 25+ tables and requires MFA confirmation.

• Delete individual team memories: Each team member's memory can be deleted item by item, or cleared entirely per team member.
• Delete individual projects: Remove a project and its associated context.
• Full account erasure: Deletes the account and cascades across all associated data — sessions, memories, projects, credentials, voice settings, meeting history, provisioned infrastructure. Requires MFA.

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.

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.

• BYO cloud (September 2026): Bring your own AWS account. Loam provisions and manages the infrastructure under your account, not ours. Your data stays in your AWS environment.
• 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.