Architecture

Daevix has three main components: the control plane, one or more enclaves, and agents. They communicate in a strict hierarchy - and the most important rule is that agents never talk directly to the control plane.

┌──────────────────────────────────────────────────────────────────┐
│                        Control Plane                             │
│                       (Daevix-hosted)                            │
│                                                                  │
│   Identity · Policy · Audit · Operator API · Hooks · Secrets     │
└──────────────────────────────┬───────────────────────────────────┘
                               │
                               │ TLS (enclave ↔ control plane)
                               │
                ┌──────────────┼──────────────────┐
                ▼              ▼                  ▼
        ┌────────────────┐ ┌────────────────┐ ┌────────────────┐
        │  Enclave       │ │  Enclave       │ │  Enclave       │
        │  (Org A)       │ │  (Org B)       │ │  (Org C)       │
        └───────┬────────┘ └────────────────┘ └────────────────┘
                │
                │ provisions + manages agents
                ▼
        ┌──────────────────────────────────────────────────┐
        │  Agent hosts                                     │
        │  ┌───────────┐  ┌───────────┐  ┌───────────┐     │
        │  │  Agent 1  │  │  Agent 2  │  │  Agent 3  │     │
        │  └───────────┘  └───────────┘  └───────────┘     │
        │                                                  │
        │  Agents only talk to the enclave                 │
        │  (never directly to the control plane)           │
        └──────────────────────────────────────────────────┘

What you operate today: nothing in this diagram. Daevix runs the control plane and the enclave as a managed service, and you create and manage agents through the dvx CLI. The architecture still matters - it’s what makes the platform’s security guarantees hold - but there’s no infrastructure for you to stand up.

Communication topology

A key architectural constraint: agents never communicate directly with the control plane. The enclave is the agent’s sole point of contact with the platform.

Control Plane ◄────► Enclave ◄────► Agent
                       ▲
                       │
              Agents only know
              about the enclave

This design provides:

• Simpler agent networking - Agents only need network access to the enclave, not to an external endpoint. The enclave sits close to the agents.
• A strong security boundary - The enclave mediates all communication. An agent cannot reach the control plane or manipulate it directly.
• Offline resilience - If the control plane is temporarily unreachable, agents keep operating. The enclave caches policy, queues audit logs, and serves credentials from local state.
• Reduced attack surface - Compromising an agent does not hand an attacker a path to the control plane. The enclave is the choke point, and it validates every request.

Component responsibilities

Control plane

The central management layer. It holds the canonical state of your fleet and is where policy, identity, and audit live.

Enclave

The on-premises component that sits next to your agents. It is the agent’s sole platform touchpoint.

LLM proxy

The LLM proxy sits on the enclave side, between agents and LLM providers:

Agent ──JWT──► LLM proxy ──API key──► LLM provider (Anthropic, etc.)

It authenticates the agent’s JWT, injects the provider credential (the agent never sees the API key), enforces content policy, and logs every request and response for audit.

Agent

The agent process runs on a Linux host and is untrusted by design:

• Boots with only an enclave URL and a single-use bootstrap token.
• Exchanges the token for an identity bundle (JWT + refresh token + secrets).
• Runs a renewal loop to keep its short-lived identity current.
• Communicates only with the enclave - never with the control plane.

Daevix ships its own identity runtime (dvxir), but the platform’s identity and security model works regardless of what code runs inside the host. See Agent Lifecycle for the full flow from creation to decommission.

Bringing your own agent image

You bring an arbitrary, unmodified OCI image - the platform does not require you to rebuild it to run as an agent. Daevix manages the agent’s identity automatically: bootstrapping, credential renewal, and secure outbound connectivity all happen without any change to your image or its entrypoint.

To make that possible, the platform provides and manages a few things inside your container:

• A short-lived platform JWT, kept current by the platform as it expires.
• The dvxir CLI, which your image can use to fetch its own secrets and config from the enclave.
• The platform’s CA bundle, so outbound connections are trusted.

Longer-lived credentials - notably the refresh token used to renew that JWT - are never exposed to your image. You can also configure per-agent environment variables at provision time to adapt an unmodified image - for example, pointing a runtime’s CA variable at the delivered bundle, or adding the delivered CLI to PATH.

The identity runtime is not a security boundary. It runs in the same trust domain as your agent image - it doesn’t grant your agent anything it did not already have. All enforcement stays at the enclave, the proxies, the relay, and the backend’s pod and node isolation. See the Security Model.