kap-server: fs/terminal/shutdown routes share the single bearer token — no per-route auth or kill switch

Summary

In 0.41.0, every kap-server route — including high-privilege ones like POST /api/v1/fs:mkdir, POST /api/v1/sessions/{id}/terminals, and POST /api/v1/shutdown — is guarded only by the single bearer token printed at startup and stored at ~/.kimi-code/server.token.

Why this matters

Any local process running as the user can read that plaintext token file and then drive the full REST surface on 127.0.0.1:

• GET /api/v1/fs:content?path=... reads arbitrary files (verified: config.toml returned 200 with full body)
• POST /api/v1/fs:mkdir writes into arbitrary directories (verified: created a directory inside a hooks-protected path, HTTP 200)
• POST .../terminals spawns shells; POST /api/v1/shutdown kills the server

The CLI's hook system (PreToolUse etc.) only gates tool calls inside the agent loop. Raw REST calls from an agent's Bash subprocess — or any other local process — bypass hooks entirely. For products embedding kap-server behind a restrictive proxy/whitelist, the official web UI escape hatch (or simple curl) re-exposes the full surface.

Suggestions (any one helps)

1. Per-route toggles, same pattern as the existing --debug-endpoints flag (e.g. --no-fs-write, --no-terminals, or an embedded/headless mode that mounts only session/prompt/transcript routes).
2. Scoped tokens (read-only vs admin).
3. Document the threat model explicitly so embedders know the token file is root-equivalent.

Happy to test any direction.

Start by tracing kap-server's authentication and route mounting for the listed fs, terminal, and shutdown endpoints, then compare it with the existing --debug-endpoints flag. Choose and scope one mitigation direction from the suggestions, and define done as high-privilege routes having the intended restriction or token scope, with the threat model documented and the behavior verified.