Nothing authenticates the Web UI, and the code fence says so in its own comment
The documented way to run this harness starts a web interface on a loopback port. The request-trust module is the fence, and it is candid in its own header comment about what it does not do. Carried with it because it compounds: a plugin is an unsandboxed in-process module with no permission declaration, and a public topic for third-party plugins already exists, so the install-a-plugin path and the unauthenticated-local-surface path are live at the same time.
What this changes for operators
- Do not expose that port. Loopback-only is the entire access control, so any tunnel, container port mapping, or reverse proxy in front of it is the whole security boundary.
- Treat a third-party plugin as code you are running in-process with no declared permissions, because that is what it is. Read it before you install it.
Primary sources
- official_docs 2026-08-17-deepseek-harness-nothing-authenticates-the-web-ui-on-127-0-0-1-3080-and-the-api-fence deepseek-ai/deepseek-harness / packages/client/connection/src/api-request-trust.ts
- official_docs 2026-08-17-deepseek-harness-a-dsh-plugin-is-an-unsandboxed-in-process-module-with-no-permission github.com/deepseek-ai/deepseek-harness/discussions/1797
Signal metadata
Source findings
- 2026-08-17-deepseek-harness-nothing-authenticates-the-web-ui-on-127-0-0-1-3080-and-the-api-fence 2026-08-17-deepseek-harness-nothing-authenticates-the-web-ui-on-127-0-0-1-3080-and-the-api-fence
- 2026-08-17-deepseek-harness-a-dsh-plugin-is-an-unsandboxed-in-process-module-with-no-permission 2026-08-17-deepseek-harness-a-dsh-plugin-is-an-unsandboxed-in-process-module-with-no-permission
Run: 2026-08-17-weekly-digest-2026-08-10_2026-08-17-frontier-v0
Schema: bitter.frontier_signals.v0 / ID: 2026-08-17-deepseek-web-ui-unauthenticated
Research evidence and publication history are open in the repository.