Threat Model

This document identifies who would attack the platform, where trust boundaries exist, what data crosses those boundaries, and what threats apply to each flow. For the platform’s security posture and controls, see Security Model.

Scope

In scope: Control plane, enclave, LLM proxy, agent containers, database, Redis, SSE event stream, and all data flows between them.

Out of scope: External IAM provider internals, upstream LLM provider (Anthropic API) internals, and the operator’s broader cloud/network infrastructure.

Assets

What an attacker actually wants, roughly ordered by blast radius:

Assumptions

• TLS is correctly configured and not intercepted at any boundary; several entries below (DF-2, DF-3) explicitly degrade to plaintext-secret exposure if this breaks (e.g. --insecure-skip-tls).
• The enclave/broker host OS and its Podman or Kubernetes control plane are not themselves compromised - the “Compromised Enclave” actor is analyzed as already holding enclave credentials, not as a host-level privilege escalation starting from nothing.
• The database and Redis (where deployed) are reachable only from platform services, never directly from agent containers or the public internet - the “Database Attacker” actor and the Redis threats in DF-14/DF-15 assume access came via a compromised service or leaked credential, not an open port.
• On the Kubernetes backend, kata-containers VM isolation (kata-clh) actually contains a container escape at the hypervisor boundary. Kata is mandatory for every agent pod, so DF-10 treats that VM boundary as the containment guarantee - there is no in-pod hardening layer behind it - and does not separately model a kata/cloud-hypervisor escape.
• Bootstrap and refresh tokens are stored only as specified (SHA-256 hashed at rest, single-use) and operators do not copy them into logs, tickets, or other systems outside the platform.

Threat Actors

Trust Boundaries

┌─────────────────────────────────────────────────────────┐
│                    Operator Network                      │
│                                                          │
│  ┌──────────┐     ┌────────────────┐     ┌───────────┐  │
│  │ dvx CLI  │────▶│ Control Plane  │◀────│    IAM    │  │
│  │(operator)│     │                │     │           │  │
│  └──────────┘     └───────┬────────┘     └───────────┘  │
│                           │ SSE + API                    │
│       ┌───────────────────┼──────────────┐               │
│       │                   ▼              │               │
│       │           ┌──────────────┐       │               │
│       │           │    Enclave   │       │               │
│       │           └──┬───────┬──┘       │               │
│       │              │       │          │               │
│       │      ┌───────┘       └────┐     │               │
│       │      ▼                    ▼     │               │
│       │ ┌─────────┐      ┌───────────┐  │               │
│       │ │  Agent  │      │ LLM Proxy │──┼──▶ Anthropic  │
│       │ │(untrust)│      │           │  │               │
│       │ └─────────┘      └───────────┘  │               │
│       │                                 │               │
│       │         Agent Network           │               │
│       └─────────────────────────────────┘               │
└─────────────────────────────────────────────────────────┘

Note: Boundaries B6 and B7 previously covered the web Operator Console (SPA ↔ Control Plane and Console ↔ IAM); the web console has been removed. Operators now use the dvx CLI, whose operator authentication is covered by B5 (and the OAuth2 device flow against IAM). The remaining boundary numbers are unchanged.

Note: The database and Redis are shared backing stores reachable from multiple services (Control Plane, IAM, Broker, LLM Proxy) and are not drawn as boxes in the diagram above to keep it legible - see boundaries B9 (database) and B11 (Redis), and data flows DF-14/DF-15.

The dvxir sidecar shares the agent’s trust domain

On Kubernetes, an agent pod has two containers: the dvxir sidecar (bootstrap, JWT refresh, tunnel, SSH) and the operator’s unmodified main container. They are one trust domain, not two - there is no trust boundary between them, and none is relied upon. Identity is delivered to the main container via shared volumes: the 5-minute JWT read-only (a tampered JWT fails ES256 validation at the enclave/proxy, so the worst case is self-DoS, not impersonation), and the dvxir binary at /opt/dvx/bin/dvxir. The longer-lived refresh token stays on a sidecar-only volume the main container never mounts and out of argv/env, so its exposure is no greater than the in-container model it replaces. shareProcessNamespace lets the sidecar enter the agent (for SSH), one-directionally; the agent gains only read visibility of the sidecar’s process list, never its capabilities. Moving the runtime into a sibling container therefore crosses no boundary and grants the agent nothing new.

Control plane ↔ IAM tables

IAM owns the iam_* tables (accounts, organizations, RBAC roles, OAuth2 clients), and other services normally only validate IAM-issued JWTs via JWKS - they do not mutate IAM data. The operator IAM-management surface (/api/v1/iam/*, boundary B5) is the documented exception: it lets the control plane write to iam_* tables - creating accounts, mutating organizations, assigning/revoking roles, and managing OAuth2 clients - making the control plane a second writer alongside dvx iam. These writes are gated by RBAC (members:*, org:manage, clients:manage) and are strictly org-scoped from the operator JWT claims - no route accepts a client-supplied organization id, including for platform-admin - so the blast radius of a leaked operator token stays confined to its own tenant. The control plane and IAM share one database and trust domain, so this is a write path within an existing boundary, not a new one.

Data Flows

DF-1: Agent Discovery

• Boundary: B1 (Agent → Enclave)
• Trigger: Agent startup
• Auth: None (unauthenticated)
• Data: Agent sends GET /v1/agent/discover. Enclave returns capabilities: service name, version, available endpoints.

DF-2: Agent Bootstrap

• Boundary: B1 (Agent → Enclave)
• Trigger: Agent first boot with bootstrap token
• Auth: Single-use bootstrap token in request body
• Data: Agent sends { token }. Enclave returns identity bundle: { agent_id, organization_id, agent_name, jwt, refresh_token, secrets (decrypted), config, config_hash }.

DF-3: Agent JWT Renewal

• Boundary: B1 (Agent → Enclave)
• Trigger: Every 4-5 minutes via agent refresh loop
• Auth: Refresh token in request body (single-use, family-rotated)
• Data: Agent sends { refresh_token }. Enclave returns { jwt (new), refresh_token (new, rotated), secrets, config, config_hash }.

DF-4: Agent Secret Access

• Boundary: B1 (Agent → Enclave)
• Trigger: Agent requests a credential on demand
• Auth: Platform JWT (Bearer token)
• Data: Agent sends GET /v1/agent/secrets/{name}. Enclave returns { name, value (decrypted) }. Also: GET /v1/agent/secrets returns name list (no values).

DF-5: Agent Config Access

• Boundary: B1 (Agent → Enclave)
• Trigger: Agent startup, drift detection
• Auth: Platform JWT (Bearer token)
• Data: Agent sends GET /v1/agent/config. Enclave returns merged config (platform → org → agent). Agent can also write agent-scoped config via PUT /v1/agent/config/{key}.

DF-6: Agent LLM Request

• Boundary: B2 (Agent → LLM Proxy), then B8 (Proxy → Upstream)
• Trigger: Agent makes an inference call
• Auth: Platform JWT (Bearer token) or x-api-key header
• Data: Agent sends Anthropic Messages API request. Proxy validates JWT, resolves the agent’s LLM API key from the database, injects it, forwards to upstream. Buffers the SSE response, runs audit interceptors, replays to agent.

DF-7: LLM Audit Logging

• Boundary: B9 (Proxy → Database)
• Trigger: Every LLM request/response pair
• Auth: Database connection credentials
• Data: Proxy writes to llm_audit_log: organization_id, agent_id, model, input/output tokens, full request body (JSONB), full response body (JSONB).

DF-8: Enclave SSE Event Stream

• Boundary: B3 (Enclave → Control Plane)
• Trigger: Enclave startup (long-lived connection)
• Auth: Enclave API key (Bearer token)
• Data: Enclave connects to GET /v1/broker/events with optional Last-Event-ID cursor. Control plane streams SSE events (e.g., agent.created with agent_id, name, org_id). Heartbeat every 30 seconds.

DF-9: Agent Provisioning (Podman)

• Boundary: B4 (Enclave → Podman)
• Trigger: Enclave receives agent.created SSE event
• Auth: Unix socket (implicit local trust)
• Data: Enclave generates bootstrap token, calls Podman REST API to create container with env vars: DVX_BROKER_URL, DVX_BOOTSTRAP_TOKEN (plaintext), DVX_AGENT_ID, DVX_AGENT_NAME, DVX_TLS_CA. CA cert bind-mounted read-only.

DF-10: Agent Provisioning (Kubernetes)

• Boundary: B4 (Enclave → Kubernetes API)
• Trigger: Enclave receives agent.created SSE event
• Auth: In-cluster service account token
• Data: Enclave creates namespace (labeled, PSA Privileged), applies NetworkPolicy, waits for the merged CA ConfigMap (trust-manager: public roots + interception CA), and creates a two-container pod - the dvxir sidecar plus the operator’s main image - with runtimeClassName: kata-clh, so the pod runs inside its own kata VM. Kata is mandatory, not a per-broker opt-in: with no kata-clh RuntimeClass configured, no agent pod is created at all. The in-pod security context is deliberately loose for every agent (the image’s own default UID including root, image-default capabilities, Unconfined seccomp, allowPrivilegeEscalation: true, and a root dvxir sidecar that drops all capabilities and adds nine back - five for s6-overlay init plus four for nsenter SSH), while automountServiceAccountToken: false still denies Kubernetes API access. Platform identity inputs (bootstrap token, client cert) go to the sidecar only; operator-set per-agent env vars are injected into the main container. The kata VM boundary, not the pod security context, is what contains a container escape (see DF-10 Elevation of Privilege).

DF-11: Operator API (Agent CRUD)

• Boundary: B5 (Operator → Control Plane)
• Trigger: Operator action via the dvx CLI
• Auth: IAM JWT (Bearer token, validated against JWKS)
• Data: Create, list, get, update, delete agents. Change agent status. Revoke tokens. Trigger re-provisioning. All scoped by organization_id from JWT.

DF-12: Operator API (Enclave Management)

• Boundary: B5 (Operator → Control Plane)
• Trigger: Operator action
• Auth: IAM JWT
• Data: Register enclave (returns API key once), list, get, delete, rotate API key. All scoped by organization_id.

DF-13: Operator API (Secrets Management)

• Boundary: B5 (Operator → Control Plane)
• Trigger: Operator action
• Auth: IAM JWT
• Data: Create/update secret (plaintext in, encrypted at rest with AES-256-GCM). List secrets (metadata only - name, agent, timestamps - no encrypted values returned).

DF-14: Broker-Local JTI Blacklist (Kill Switch)

• Boundary: B11 (Broker ↔ Broker-local Redis)
• Trigger: Operator issues an isolate/restore action via the broker kill-switch RPC; also consulted on every platform JWT validation
• Auth: None on the connection itself (local/in-network Redis, authenticated via requirepass/TLS if configured)
• Data: The broker adds/removes the agent’s JTI under a dvx:jti: key with a TTL (internal/redis/blacklist.go). Isolation and restoration are performed entirely enclave-side - agent_runtime.isolated_at, refresh-token revocation, and the JTI blacklist all live in the broker’s own Redis, distinct from the control plane’s. Every subsequent JWT validation (agentauth.Validator configured WithBlacklist) checks this store before accepting a token.

DF-15: Control Plane / IAM Redis (Sessions, Device Flow, Rate Limiting)

• Boundary: B11 (Control Plane/IAM ↔ Redis)
• Trigger: SSO login/logout, OAuth2 device authorization polling, login rate limiting
• Auth: None on the connection itself; Redis auth/TLS if configured
• Data: IAM stores SSO session blobs (iam:session:) and a per-account session index (iam:account-sessions:) - the same key format is written by both the IAM OAuth service and the control-plane operator service’s account-suspension revocation path (design doc 036), so they must stay in lock-step. It also stores OAuth2 device codes (5-minute TTL) for the device authorization flow, and sliding-window login rate-limit counters (iam:ratelimit:) keyed by IP/account.

DF-16: Event Publishing and Purging

• Boundary: Internal (Control Plane)
• Trigger: Agent creation with broker_id (publish), hourly timer (purge)
• Auth: None (in-process)
• Data: Events written to broker_events table with auto-incrementing cursor. In-process event bus notifies SSE handler. Purge deletes events already consumed by their enclave (cursor-based) or owned by deleted enclaves.

DF-17: Telegram Integration

• Boundary: B5 (Operator → Control Plane), then external (Control Plane → Telegram API)
• Trigger: Operator links a Telegram bot to an agent
• Auth: IAM JWT (operator), then Telegram bot token (validation call)
• Data: Operator sends bot_token. Control plane validates via Telegram getMe API. Token encrypted and stored as agent secret (telegram:bot_token). Integration record created. Agent receives decrypted token during bootstrap/renewal.

DF-19: Broker URL Announce & Discovery

• Boundary: B3 (Enclave → Control Plane) for the announce; B5 (Operator → Control Plane) for discovery
• Trigger: Broker (enclave) startup advertises its operator-reachable URL; operator later resolves an agent via the dvx CLI
• Auth: Broker JWT (POST /v1/broker/announce) for the announce; operator IAM JWT (agent GET) for discovery
• Data: The broker reports its configured operator-reachable URL (--operator-broker-url, falling back to --agent-broker-url) to the control plane, which records it trust-on-first-use (TOFU) in brokers.url, keyed strictly by the authenticated broker_id from its JWT (never client-supplied). The operator URL is intentionally distinct from the agent-facing URL in split topologies (in-cluster agents reach the broker by Service DNS; external operators reach it via an ingress/tunnel). The control plane cannot auto-detect it (the broker dials out, often from behind NAT). The control plane returns this URL as broker_url on the agent GET/list responses so the dvx CLI can reach the correct broker for SSH/port-forward/tunnel without an explicit --broker-url. The CLI sends the operator’s IAM JWT to this broker URL to obtain a short-lived SSH certificate (and for terminal/tunnel), so the URL governs where an operator credential is sent. Mitigations: the URL is pinned on first announce and a later announce with a different URL is rejected and logged as a tamper signal (a stolen broker credential cannot silently repoint operators at an attacker host after the legitimate broker has connected once); an operator can re-pin authoritatively via PATCH /api/v1/brokers/{id}; and --broker-url always overrides the discovered value. TLS verification of the broker endpoint remains mandatory on the CLI.

STRIDE Analysis

DF-1: Agent Discovery

DF-2: Agent Bootstrap

DF-3: Agent JWT Renewal

DF-4: Agent Secret Access

DF-5: Agent Config Access

DF-6: Agent LLM Request

DF-7: LLM Audit Logging

DF-8: Enclave SSE Event Stream

DF-9: Agent Provisioning (Podman)

DF-10: Agent Provisioning (Kubernetes)

DF-11: Operator API (Agent CRUD)

DF-12: Operator API (Enclave Management)

DF-13: Operator API (Secrets Management)

DF-14: Broker-Local JTI Blacklist (Kill Switch)

DF-15: Control Plane / IAM Redis (Sessions, Device Flow, Rate Limiting)

DF-16: Event Publishing and Purging

DF-17: Telegram Integration

DF-18: Execution-Time Policy Evaluation

• Boundary: B2 (Agent → LLM Proxy)
• Trigger: Agent’s LLM response contains tool_use blocks
• Auth: Platform JWT or netproxy-forwarded service-signed identity headers
• Data: LLM proxy inspects tool calls against execution-time policies (3-layer architecture: inspectors → policy engine → enforcers). Policy decisions are logged to policy_decisions. Actions requiring approval enter the approval workflow; denied actions are returned as tool_result(is_error).

DF-19: Broker URL Announce & Discovery