# AI Workspace Security Audit 2026-06-20 Status: prototype hardening report. Scope: AI Workspace Assistant, public AI Hub relay, remote Codex worker, local Launcher, local Engine, local Ops Gateway, ontology-core assistant actions. ## Current architecture The safe local test topology is: ```text local Engine / local Ops UI / local Launcher -> local AI Workspace Assistant -> public AI Hub relay -> remote Codex worker -> public AI Hub assistant action relay -> local AI Workspace Assistant -> local Launcher / local Engine / local Ops Gateway ``` The public AI Hub is transport only in `NODEDC_ENV=local`. It must not become the owner of Launcher, Engine, Ops, Authentik, or product-app data. Product reads and writes return to the local Assistant and then go through local app-owned adapters. ## Profiles `local` - Business apps are local: Launcher, Engine, Ops/Gateway, Tasker, databases, fixtures. - AI Workspace Assistant is local. - The only allowed deployed URL class is the AI Hub relay: `https://ai-hub.nodedc.ru` / `wss://ai-hub.nodedc.ru/api/ai-workspace/hub`. - Production product hosts are forbidden in local downstream config: `hub.nodedc.ru`, `engine.nodedc.ru`, `ops.nodedc.ru`, `id.nodedc.ru`, `ops-agents.nodedc.ru`. - Remote worker receives a scoped run profile and calls assistant actions through the relay, not through product apps directly. `deploy-host` - Business apps and AI Workspace services run in the deployed stack. - Public worker-facing relay is still `ai-hub.nodedc.ru`. - Internal service URLs must be container/network URLs, not localhost and not developer-machine URLs. - This profile is architecturally described but not fully proven yet. It still needs a clean deploy verification run before it can be treated as release-ready. `tunnel-local-e2e` - Explicit escape hatch for Tailscale/ngrok-style testing. - Must be opt-in through `NODEDC_ENV=tunnel-local-e2e`. - No local config may silently fall back to private/tunnel addresses. ## Trust boundaries Browser and local app backends trust only local service tokens and the current application session. AI Workspace Assistant owns assistant orchestration: - builds run profiles; - resolves app grants; - exposes the assistant action gateway; - performs preview/execute routing; - calls app-owned adapters. Remote Codex worker is an executor: - it receives only the run profile and tool/action gateway information; - it must not own product app credentials; - it should not call Launcher, Engine, Ops, Authentik, or product DBs directly in local profile. Ontology Core owns assistant action policy: - registered action catalog; - risk levels; - route allowlists; - no hard-delete guardrails; - preview/confirmation/execute contract. App adapters own their app-specific state changes: - Launcher adapter mutates only guarded Launcher admin routes. - Ops adapter calls the Ops Gateway tool API. - Engine graph edits stay in NDC Agent Core / Engine-owned workflow tools. ## Transport and tokens Confirmed controls in current code: - Assistant API requires an internal token via `Authorization: Bearer ...` or `X-NODEDC-Internal-Token`. - Hub internal API requires `Authorization: Bearer ...`. - Constant-time token comparison is used for Assistant and Hub internal API checks. - Public relay traffic uses HTTPS/WSS. - Assistant action relay forwards only user owner headers, not arbitrary incoming headers. - Launcher admin action adapter sends `Authorization: Bearer ` plus assistant actor headers. - Ops action adapter obtains or uses an Ops run token and sends it to Ops Gateway as `Authorization`. - Write routes require an idempotency key. - DELETE is blocked at execution-plan validation. Current token classes: - `NODEDC_INTERNAL_ACCESS_TOKEN`: service-to-service internal token for local stack. - `AI_WORKSPACE_HUB_TOKEN`: public Hub internal API token. - `NDC_LAUNCHER_INTERNAL_ACCESS_TOKEN`: Launcher admin adapter token. - Ops entitlement token: lets Assistant ask Ops Gateway for a scoped run token. - Ops run token: downstream authorization for Ops tool routes. - Assistant action confirmation token: digest over action, actor, request body/path, and idempotency key. ## Assistant action safety model Read actions: - do not require confirmation; - must still resolve to a registered action; - must be scoped by owner context and app-owned adapter policy. Write and privileged actions: - must resolve to a registered action; - must pass risk policy; - must pass route allowlist; - must include idempotency key; - must produce a preview; - must require explicit user confirmation; - must execute only with the preview confirmation token. Destructive actions: - are forbidden for assistant execution; - hard-delete users, files, DB rows, production state, archives, backups, and runtime/storage records must stay outside assistant action routing. ## Prototype status Tested behavior: - local Assistant action gateway can preview Ops card creation; - public relay can route preview requests to local Assistant via `relayId=local-dev`; - Engine UI can ask the remote worker to create an Ops card; - write creation requires preview and explicit confirmation; - confirmed Ops test card creation succeeded through the UI; - Launcher pending access read works through assistant action routing; - Engine NDC Agent Core tools are visible for selected agent node operations; - Engine chat polling jitter was addressed by stable remote message merge logic. Not yet proven: - complete deploy-host profile after a fresh deployment; - cross-user relay isolation under multiple simultaneous local developers; - one-time confirmation token storage; - token TTL enforcement for every downstream run token; - full stop/cancel behavior for long remote Codex runs; - full browser UI regression pass across Launcher, Ops, and Engine. ## Findings P0 fixed in current prototype: - Product app calls no longer need to be tested by deploying raw product changes first. Local profile routes product reads/writes back to local services. - Ops card create path now works through Assistant -> Ontology Core -> Ops Gateway with preview/confirmation. - The remote worker is treated as executor, not as product credential owner. P1 hardening required: - Confirmation tokens are deterministic digests and currently have no TTL or server-side one-time consumption store. If preview output and token leak, the same request can be replayed until downstream idempotency suppresses duplicates. Add server-side confirmation records with TTL, actor binding, single-use consumption, and audit trail. - `local-dev` relay id is too generic for repeated multi-user work. Use unique relay ids per developer/station/environment, for example `local-dc-mac-` or configured stable machine id. - Public relay is bearer-token protected but not mTLS-bound. Treat Hub token leakage as critical and rotate tokens after exposure. - The worker receives `assistantActionGatewayToken` in the run profile. This is necessary for the current bridge, but it is a bearer secret. Keep it short-lived or derive a per-run action token instead of reusing broad service tokens. - Stop/cancel behavior needs an automated smoke check with a deliberately long remote run. P2 hardening required: - Add audit correlation ids across Engine request, Hub request, worker run, Assistant action, Ops/Launcher adapter call. - Add negative tests for forged owner headers through the public relay. - Add negative tests for forbidden DELETE route, destructive action, missing idempotency, wrong confirmation token, wrong actor, and wrong project id. - Add dashboard visibility for selected run profile, action ids, relay id, and downstream profile without exposing tokens. ## Security conclusion The prototype is usable for controlled local testing and internal proof-of-flow. It is not yet release-grade security. The main architectural boundary is now correct: local product state stays local, the public AI Hub is a relay, and writes go through registered ontology actions with preview and confirmation. Before production rollout, the confirmation and relay-token model must be hardened with TTL, single-use confirmation records, unique relay ids, short-lived action tokens, and expanded negative tests.