172 lines
8.1 KiB
Markdown
172 lines
8.1 KiB
Markdown
# 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.
|