# 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 <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.
