GeezerVison

Summary

• createV2ResourceConcealmentPolicy rewrites DelegatedWorkspaceAuthorizationError, NoWorkspaceAccessError, and WorkspaceApiKeyScopeAuthorizationError to a 404 on v2 single-resource routes. The internal routes reach the same application use cases and still answered 403, so the existence probe the v2 policy closes still worked from the other surface.
• Added createInternalResourceConcealmentPolicy (and concealCrossTenantResourceError for the raw withRouteHandler routes) beside the v2 factory, and renamed v2-resource-concealment.ts → resource-concealment.ts since it now owns both surfaces. The concealed failure is re-projected through each domain's existing base policy as a not_found orchestration error, so every body shape (success: false, the legacy workflow code field, the table 423 lock branch) is exactly what that route's real 404 already returns.
• Same-workspace denials are untouched: InsufficientWorkspacePermissionsError, PersonalApiKeysDisabledError, WorkspaceApiKeyAuthorizationError, and PrincipalKindAuthorizationError all stay 403 on both surfaces, and generic OrchestrationError('forbidden', …) is never classified by message.

Routes whose status changed (cross-tenant denial only: 403 → 404)

Deliberately left at 403

• Workspace-level list/create — GET/POST /api/knowledge name no resource, so a 403 there betrays nothing. Concealing them would turn a denied workspace into a phantom empty list.
• /api/mcp/**, /api/skills/**, /api/tools/custom, /api/logs/[id], workflow runs/execute/resume — the v2 routes for these use v2-only use cases with no internal counterpart sharing the symbol, so there is no asymmetry to close. Several of them are also where a flip would regress: hooks/queries/mcp.ts:92,127 and hooks/queries/workflow-mcp-servers.ts:60,130 swallow 404 into [], so a denied user would see a "no servers configured" empty state instead of an error, and deploy-modal/components/mcp/mcp.tsx:400 auto-recreates a tool on 404.
• GET /api/workspaces/[id]/host-context — untouched. workspace-host-provider.tsx:29 is the one surface that renders a dedicated <WorkspaceAccessDenied /> on 403; flipping it would drop a revoked user into a stale workspace tree.

UI impact of what did change

I swept hooks/** and app/** for 403/404 branching on the affected families. Nothing structural flips:

• knowledge/[id]/base.tsx:1233 already renders "Knowledge base not found" for both statuses.
• kb/knowledge.ts:113 rewrites 404 to "Document not found" — message-only change, same error layout.
• tables/[tableId]/error.tsx copy already hedges "deleted or you may not have permission".
• Table and custom-tool toasts render error.message verbatim, so a denied write now reads "Table not found" instead of "Insufficient workspace permissions".
• logs.ts:208 skips retry on 404 — one fewer retry before the same error state.

Type of Change

• Bug fix

Testing

bun run type-check, bunx vitest run app/api lib/api (342 files / 3257 tests), bun run lint, bun run check:api-validation — all green.

Tests pin the concealed status per policy and per route: resource-concealment.test.ts now covers every internal policy alongside the v2 ones, and route-level tests drive the real handlers for file rename/share/content, workflow PUT, and deployment-version PATCH. Table/group route tests assert the wiring. Verified they can fail — stubbing concealCrossTenantResourceError to a passthrough turns 60 tests red, and un-wiring a single table route fails its wiring assertion with expected { kind: 'plain' } to be { kind: 'conceal-import' }.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)