Security

What lnk-deepseek installs and runs, beyond what Link's sandbox guarantees every harness (Link's Agents Security page).

Installing it

  • DeepSeek Harness has no installer script: this adapter downloads Node from nodejs.org, checked against the SHA-256 in its source, and installs @deepseek-ai/dsh from npm at a pinned version. npm checks that package against the registry's hash; its dependencies are resolved at install time, since it ships no lockfile, and some run install scripts (node-pty's, which only sets a file executable).
  • A new dsh release comes with a release of this adapter.

Running it

  • Its own sandbox and approvals are off. Link's sandbox confines it instead, with the same rights as any harness: its home and the files folder, the network through its proxy.
  • Nothing goes to DeepSeek. Link's settings layer turns off the session log and plugin list dsh attaches to requests to DeepSeek's API, its telemetry (also DSH_TELEMETRY_DISABLED), and its web search, which uses DeepSeek's API.
  • Its endpoint answers only on loopback, and only a request with the key Link hands it at each start (Authorization: Bearer).
  • It proves it's the endpoint before Link's channels send it that key or a message: it answers their random challenge with an HMAC of it made with the key, never the key itself (proof in its contract). A program that took its port while it started or restarted can't, and gets neither.
  • The model's key is in dsh's store of keys, ~/.deepseek/home/.credentials.yaml (600), a placeholder when it's on the wire, which it is by default. The store wins over a .env in the files folder, which dsh also reads keys from.
  • Known gap: another key in that .env, such as DEEPSEEK_API_KEY, reaches dsh too. Link's settings send nothing that uses one.