Review Loam's deployment and data boundaries.
What installs, what leaves the device, where it is stored, who can access it, and how it is removed.
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.
| Question | Answer |
|---|---|
| Does it need admin rights? | DependsThe Marketplace extension does not require elevation. The PowerShell installer is currently documented to run from an elevated prompt and may install Node.js, Claude Code, and browser tooling when absent. |
| Does it install a service or driver? | NoNo Windows service, no kernel driver, no background daemon. Nothing runs unless VS Code / Claude Code launches it. |
| Does it scan repositories by default? | NoNo automatic repo scan or upload. Code reaches Loam only when a developer pastes it, attaches it, starts a workflow that needs it, or enables Workspace Indexing. |
| Does source code leave the machine? | Only when sharedOnly content supplied to a session or an enabled workflow leaves the machine. The provider account used depends on the workflow and trial state; the boundary is detailed below. |
| Is Workspace Indexing on by default? | OffOpt-in and off by default. When enabled it sends a project snapshot to assemble session context; that index is not persisted in Loam's database. |
| Is stored memory deletable? | YesPer team member, per project, or live account database deletion behind MFA. A team member’s memory is a single stored record: it is cleared in full or rewritten in place, so there is no per-entry delete. Generated server files and managed infrastructure follow separate cleanup boundaries. |
| Are credentials per-user? | SeparatedLoam IDE keys and customer Anthropic keys are scoped per account. Loam-managed model, communications, and infrastructure credentials are held separately as platform credentials and are not exposed to customer accounts. |
| Is there a customer-facing audit log? | RoadmapProvisioning and settings changes are logged server-side, but a per-user action log exposed to the account holder is planned, not yet shipped. |
| Is data export available? | RoadmapNo bulk export endpoint yet. A developer can read their own data through the interface; export-before-deletion is planned. |
| Is retention configurable? | RoadmapMost session, memory, and project data does not auto-expire. Fetched call audio clears on a 30-day schedule; full call records require account deletion or cleanup by an authorized Loam administrator. Configurable retention is planned. |
Green answers describe shipped controls. Amber answers mark limits or roadmap items so the review can separate what exists today from what does not.
Two runtime components. No Loam Windows service.
Loam consists of a VS Code extension and a user-profile MCP (Model Context Protocol) process. 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.
%USERPROFILE%\.docpro, registered in %USERPROFILE%\.claude.json and launched by Claude Code on demand.- 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 isAllSigned: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.
The VS Code extension is distributed through the VS Code Marketplace. Whether that path is allowed depends on your organization’s policy. The MCP server runs as a user-space Node process; it is not a signed Windows service. For policy-constrained environments, contact the team to review deployment options.
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.
- 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.
IDE session content, team memory, and project context are field-encrypted at rest with Fernet symmetric encryption — the same scheme that protects credentials. Session turns, memory text, temperature notes, and saved project context are stored as ciphertext; the key lives outside the database. Phone call transcripts, Reception work-order text, and delivered report files are not field-encrypted. Also in plaintext is the lookup metadata recall depends on: guest display names and the phone numbers used to match return calls, plus the keyword tags and one-line summaries the memory index searches against. Encrypting those would break search and recall, so they remain queryable and are protected by strict per-account isolation and access controls.
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, with explicit boundaries.
Developers can clear a team member’s memory, delete entire projects, or delete the live database records tied to their account. The account transaction cascades across 25+ tables and requires MFA confirmation; generated server files and managed infrastructure are separate.
- 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.
- Live account database deletion: Deletes the account’s Loam database records and stored credentials behind MFA. Generated server files require Loam-operated cleanup. Teardown, export, or transition of Loam-managed infrastructure is governed by the applicable plan or order and is not part of the self-service database transaction.
No data export: There is currently no endpoint to export a user's data before deletion. A developer can read their own data through the Loam interface, but bulk export is not available yet.
No per-order delete: account deletion deletes Reception work orders, their intake records, and delivered report files, but there is no control to delete a single order or its report.
No configurable retention policy: Most session, memory, and project data does not auto-expire. Fetched call audio is the scheduled exception; full call records require account deletion or cleanup by an authorized Loam administrator.
No customer-facing audit log: Provisioning events and settings changes are logged server-side, but there is no per-user action log exposed to the account holder or an IT administrator.
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.
| Destination | Protocol | Purpose |
|---|---|---|
loam.team |
HTTPS 443 | Installer and extension downloads, product pages |
docpro.cloud |
HTTPS 443 | API, account, sessions, memory, file delivery |
marketplace.visualstudio.com |
HTTPS 443 | VS Code extension install and updates |
api.anthropic.com |
HTTPS 443 | Anthropic Claude API — provider account depends on the editor workflow and trial state |
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.
Standard HTTPS proxying is supported. Runtime TLS inspection policies should account for loam.team, docpro.cloud, and api.anthropic.com. Installer prerequisites may require the additional vendor endpoints named above.
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.
- VS Code extension — installed in your user profile, no admin
- MCP server — Node.js, user space, no background service
- Claude Code CLI — uses the developer’s configured Anthropic account for supported editor workflows
- Session content — stored as session history
- Team memory — field-encrypted at rest, user-deletable
- Project context — field-encrypted at rest, user-deletable
- Source code — only if pasted, attached, or Workspace Indexing is on (opt-in, off by default)
- Call recordings (Meet the Team, Call Team, ReachOut) — transcript stored as plaintext for memory synthesis; audio recording, if fetched, stored in the database and cleared on a 30-day schedule. Full call records do not currently auto-expire; they remain until account deletion or cleanup by an authorized Loam administrator. Morning Read and Studio audio are server files that require Loam-operated cleanup after account deletion.
- Anthropic Claude API — developer account for supported editor work; Loam-managed key during active trials and for admin server-side work; customer key required for post-trial server-side work
- Gemini API — Build Mode image generation (Loam-managed provider key, server-side)
Paths, logs, and removal.
%USERPROFILE%\.vscode\extensions\docpro.docpro-app-{version}\ — installed by VS Code Marketplace into the user profile.%USERPROFILE%\.docpro; docpro-proxy registration in %USERPROFILE%\.claude.json; Loam environment values and managed Stop hooks in %USERPROFILE%\.claude\settings.json.{workspace}/.docpro/ — session ID, encrypted session prompt, and optional workspace index cache. Gitignored by default..docpro directory.To remove Loam: (1) uninstall docpro.docpro-app from VS Code; (2) remove only the docpro-proxy entry, and the installer-added playwright entry if it is not used elsewhere, from %USERPROFILE%\.claude.json; (3) remove Loam’s managed Stop hooks and DOCPRO_API_URL/DOCPRO_API_KEY values from %USERPROFILE%\.claude\settings.json; and (4) delete %USERPROFILE%\.docpro plus any workspace .docpro folder you no longer need. Preserve unrelated entries in both Claude configuration files.
The installer may also have added Node.js, the Claude Code CLI, npm cache entries, and Chromium under %LOCALAPPDATA%\ms-playwright. These can be shared by other tools and are not removed automatically; remove them separately only when you have confirmed nothing else uses them. Loam does not install its own Windows service, kernel driver, or background telemetry agent.
Open the Loam sidebar in VS Code → Settings → Regenerate IDE API Key. The old key is immediately invalidated server-side. Paste the new key in the sidebar Settings panel to restore access.
The VS Code extension is distributed and signed through the VS Code Marketplace (docpro.docpro-app) — that path is signed by Microsoft and is the one to use where a valid publisher signature is a policy requirement.
The PowerShell installer script is Authenticode-signed by Toast2IT, LLC under an OV certificate valid through April 2027, countersigned by a DigiCert timestamp authority so the signature outlives the certificate. Download and verify both facts before executing in restricted environments — the signature establishes the publisher, the hash proves the bytes reached you intact:
irm https://loam.team/api/ide/download/installer -OutFile docpro-install.ps1, then Get-AuthenticodeSignature docpro-install.ps1 (expect Valid) and Get-FileHash docpro-install.ps1 -Algorithm SHA256.
SHA-256: 38cd0ae6b08a0f316c7100ad443236de225bbc34172253b65cb1ec37c0ce4c58
Then run the file you checked. A stock Windows 10 or 11 machine refuses local scripts (“running scripts is disabled on this system”), so start it through a PowerShell process whose execution policy is AllSigned — that setting lives in this one process, changes nothing on the machine, and makes the signature you just verified the thing that lets the file run. From PowerShell as Administrator, in the folder where you saved it:
powershell -ExecutionPolicy AllSigned -File .\docpro-install.ps1
Windows asks whether to run software from the publisher Toast2IT, LLC. Answer R (Run once) or A (Always run, which adds the publisher to your Trusted Publishers); pressing Enter alone chooses Do not run.
Still refused? If PowerShell still says running scripts is disabled, or the publisher prompt never appears, a Group Policy or an application-control product (AppLocker, ThreatLocker, WDAC) is deciding, and no setting you make in a process overrides it. Allow the signed publisher in that policy, or use the Marketplace path, which runs no script.
No MSI or MSIX package is currently available. WDAC and AppLocker policies that allowlist by publisher should target the VS Code Marketplace signing certificate.
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.
Questions that aren’t answered here.
The Security page covers the developer-facing view: what's encrypted, how deletion works, and memory boundaries. This page covers the IT-facing view. If neither answers your question, reach the team directly.
The core deployment and security claims on this page were last checked against source on 2026‑07‑20. Reception, encryption-exception, and deletion disclosures were checked against source on 2026‑09‑13. Ask for a current verification packet before approval.