Workspace enumeration via tool-layer 'not found' messages (connector-tools), follow-up to #17

[mgoldsborough]

Summary

After #17 collapsed workspace-resolution errors into a single generic 403 "Access denied to workspace." (no ID echo), several tool-layer paths still distinguish "workspace does not exist" from "exists but access denied" by echoing the workspace id in a not-found message. The clearest case is src/tools/connector-tools.ts, where install/management actions do:

const ws = await ctx.runtime.getWorkspaceStore().get(wsId);
if (!ws) return errResult(`Workspace "${wsId}" not found.`);
// ... then:
if (!isWorkspaceAdmin(ws, identity)) return errResult(/* admin required */);

An authenticated caller supplying an arbitrary wsId (tool arg) can distinguish:

• nonexistent workspace → Workspace "<id>" not found.
• existent but not-admin → admin-required error

That's the same enumeration shape #17 closed, one layer up. Multiple sites in connector-tools.ts follow this pattern (~lines 837, 1315, 1435, 1493, 1821, 1906, 1973).

Scope / severity

Lower severity than #17:

• Requires an authenticated session (not the unauthenticated HTTP data-path gate Use generic error messages for workspace resolution failures #17 addressed).
• Returns tool-result text, not an HTTP status code.
• workspace-mgmt-tools.ts CRUD paths that echo the id are gated behind an org-admin check first, so those are not a cross-tenant leak — this issue is specifically the connector-tools (and similar) paths that echo the id before/around the per-workspace admin check.

Suggested fix

For paths reachable with an attacker-suppliable wsId, return a single generic "access denied" result for both not-found and not-authorized, without echoing the id — mirroring the #17 resolution. Leave paths that operate only on an already-resolved/authorized workspace as-is.

Priority

P3 — information disclosure, minor (same class as #17).

[mgoldsborough]

Related surface surfaced during PR #19 review (deferred here on purpose):

src/api/mcp-server.ts:720/733 returns Unknown workspace "<id>" (reason: unknown_workspace) vs Access denied to workspace "<id>" (reason: workspace_access_denied) on the /mcp JSON-RPC endpoint, and src/orchestrator/error-mapping.ts:74 mirrors it for the REST /v1/chat surface. The caller controls the workspace id (it's embedded in the ws_<id>-<tool> tool name), so this is technically the same existence-vs-membership distinction #17 addresses.

Why it was NOT changed in PR #19: unlike the proxy route (which was an accidental inline reimplementation and got fixed there), this split is a deliberate, documented design. src/orchestrator/route.ts justifies it ("the former points at a buggy client / stale link; the latter at ... an attempted cross-tenant probe. Conflating them would hide both shapes"), and it's exposed as a structured data.reason discriminator that's part of the cross-workspace orchestrator contract. Genericizing the message alone wouldn't even close it — reason still distinguishes the two.

Collapsing it is an architectural decision (touches mcp-server.ts, error-mapping.ts, handlers.ts, and the documented data.reason contract) that should go through chief-architect review, not a drive-by message change. Filing here so it isn't lost.