ML.ai Code

Security and privacy

Where credentials live, what leaves the machine, and how the panel is architecturally kept from touching your filesystem directly.

Credentials

Your ML.ai access token is stored in VS Code's SecretStorage and passed only to the locally-launched engine process, through its environment. It's never returned to the panel after saving, never displayed again, and never included in copied diagnostics.

ML.ai requires its own access token. It does not migrate or reuse an existing OpenCode CLI credential already configured on the same machine: every install starts signed out.

The engine's network posture

The bundled engine listens on localhost only, behind a generated password. Every call the engine makes is checked against a central blocked-endpoint policy before the request goes out.

Architecture

Panel (React, presentation only)
  → editor message passing →
Extension host (Node: validation, secrets, filesystem, engine lifecycle, routing)
  → authenticated localhost HTTP/SSE →
Bundled engine
  → model provider / MCP servers / editor's language servers

The panel itself has no filesystem, process, or network access of its own. Every message it sends is validated on the extension-host side before anything happens. This boundary is enforced by an automated test, not by convention alone.

What actually leaves the machine

DataDestination
Prompts, selected file content, tool resultsThe configured model provider
MCP tool inputThe specific MCP server that tool belongs to
Everything elseNowhere

Blocked at the network layer

These are blocked by policy, not merely unused: a stray call, a future feature, or a compromised panel message can't reach them either.

RouteWhy
Terminal UI routesNot applicable to an editor extension
Interactive PTY routes (current and legacy)No user-facing surface this release
Engine self-upgradeThe engine is versioned together with the extension
Session sharing (create and revoke)Would publish prompts, file contents, and command output to a public URL. Verified against a live engine. Both directions are blocked so create can't be re-enabled through a working revoke path, or vice versa.

Two decisions that change your safety posture

Both are designed to be visible rather than silent:

  • Always on a permission prompt: creates a persistent rule, saved globally when the workspace isn't a Git repo. Mitigated by the saved-permissions list with per-rule revoke. See permission prompts.
  • Auto-approve: answers prompts immediately. Mitigated by being loud when on, off by default, never persisted, and answering once rather than durably. See auto-approve.