Security Profiles

Mentat implements a zero trust architecture at the infrastructure level. Every workload is assumed hostile and isolated accordingly. The platform provides four trust zones — each with explicit security boundaries enforced by the kernel, not by convention.

Zero Trust Runtime Model

FirecrackerDedicated kernel per workload (KVM/VT-x). Strongest isolation — used for Raft clusters and critical services
SandboxLinux namespace isolation (PID + mount + UTS + IPC) with cgroups v2 limits, pivot_root, and ALL capabilities dropped. No Docker daemon. 2MB overhead
Docker HardenedCompatibility path with read-only rootfs, no capabilities, no new privileges, restricted bind mounts
Docker LegacyMigration path for workloads not yet ready for strict policy
Exec InternalHost-level processes allowed only for trusted internal components

Recommended Profiles

security profiles
security:
  profiles:
    firecracker:
      driver: firecracker
      isolation: strong
      allow_privileged: false
      read_only_rootfs: true
      persistent_volumes: allowed
      network_policy: private-by-default
      intended_for:
        - public APIs
        - multi-tenant workloads
        - sensitive internal services

    docker-hardened:
      driver: docker
      isolation: medium
      run_as_non_root: true
      read_only_rootfs: true
      drop_capabilities: ["ALL"]
      no_new_privileges: true
      seccomp: strict
      apparmor: default
      docker_socket: forbidden
      bind_mounts:
        host_system_paths: forbidden
        service_data_paths: allowed
      intended_for:
        - nextjs SSR
        - node services
        - java application servers

    docker-legacy:
      driver: docker
      isolation: transitional
      run_as_non_root: preferred
      read_only_rootfs: preferred
      drop_capabilities: minimal
      no_new_privileges: true
      seccomp: default
      apparmor: default
      intended_for:
        - legacy containerized services
        - migration workloads

    sandbox:
      driver: sandbox
      isolation: strong
      namespaces: [pid, mount, uts, ipc]
      pivot_root: true          # NOT chroot
      capabilities: none        # ALL dropped
      no_new_privileges: true
      cgroups_v2:
        memory: enforced
        cpu: enforced
        pids: enforced
      init_binary: sandbox-init # 15KB static C binary as PID 1
      intended_for:
        - Next.js / React apps
        - Node.js services
        - static web servers
        - any workload that doesn't need a full VM

    exec-internal:
      driver: exec
      isolation: low
      host_access: direct
      allowed_nodes: ["internal-only"]
      internet_exposed: false
      intended_for:
        - agents
        - collectors
        - operational helpers

How To Use Them

The practical model: critical Rust services and Raft clusters go to Firecracker (dedicated kernel). Web apps and Node.js services go to sandboxes (namespace isolation, no Docker daemon). Existing containerized services stay in hardened Docker. Internal agents run as exec. Every layer enforces zero trust — no workload trusts another.

Service-Level Example

service.yaml
name: web-frontend
driver: docker
image: registry.example/web-frontend:latest
security:
  profile: docker-hardened
deploy:
  strategy: rolling

---
name: api-gateway
driver: firecracker
image: /opt/mentat/bin/api-gateway
security:
  profile: firecracker

---
name: web-app
driver: sandbox
config:
  rootfs: /opt/apps/nextjs-standalone
  command: /usr/bin/node
  args: ["server.js"]
  memory_mb: 256
  cpu_percent: 50
  max_pids: 32
security:
  profile: sandbox

---
name: node-agent
driver: exec
config:
  command: /opt/bin/node-agent
security:
  profile: exec-internal

What Hardened Docker Should Mean

  • Run containers as non-root whenever the workload allows it.
  • Use a read-only root filesystem by default.
  • Drop Linux capabilities aggressively, ideally all of them.
  • Enable no-new-privileges.
  • Apply strict seccomp and AppArmor or SELinux policy where available.
  • Forbid privileged containers and Docker socket mounts.
  • Forbid sensitive host paths such as /var/lib/docker, /var/log, and Mentat state directories.
  • Limit bind mounts to explicit service data paths.
  • Require a single non-privileged exposed port for ingress-managed hardened services.
  • Keep docker-legacy off public ingress entirely.
  • Apply CPU and memory limits at the platform layer.

Commercially Honest Framing

The value is not that every workload becomes a microVM overnight. The value is that Mentat can orchestrate mixed runtimes under one control plane while enforcing a clear security posture: strong isolation for critical services, hardened containers for existing applications, and a bounded path for legacy compatibility.