8.1 KiB

Raw Blame History

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:

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 <launcher internal token> 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-<date> 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.

8.1 KiB Raw Blame History