Clawdbot

What This Is

This document describes a production infrastructure where AI agents are not just tools — they are operators. Two AI agents collaboratively manage a three-machine environment: an office server, a GPU compute node, and a web hosting platform. Together, they handle system administration, user communication, email, calendar management, security monitoring, and more.

What makes this different

Most AI-in-operations setups use AI as an assistant: a human asks a question, the AI answers. This system inverts that model:

• Dakota — the user-facing agent, runs 24/7 on Telegram. Reads emails, manages calendars, performs research, writes code, sends voice messages — autonomously.
• Claude Code — the system administrator. Deploys containers, diagnoses issues, applies patches, maintains documentation — triggered by events, not prompts.
• A request broker enables asynchronous collaboration with human approval for consequential actions.

The human operator remains the decision-maker for anything consequential. But the day-to-day operational burden has shifted dramatically.

Architecture Overview

The infrastructure spans three machines with distinct roles, connected via SSH and managed by AI agents.

High-level: The Three Machines

Detail: Inside the Office Server

The Three Machines

The Physical Setup

The heart of the system is an ASUS NUC 13 mini PC — a compact, silent machine in an office. Despite its small footprint, it runs the entire AI agent stack: ~20 Docker containers, two AI agents, security monitoring, and acts as the control plane for two Azure VMs.

Containerization Philosophy

Every service runs in Docker, with one exception (Kodi media center). Containers are configured with:

• Read-only root filesystems where possible
• All capabilities dropped (cap_drop: ALL), with only necessary ones added back
• Non-root execution inside containers
• Memory, CPU, and PID limits to prevent resource exhaustion
• Isolated Docker networks — services can only communicate where explicitly configured

Dakota: The User-Facing AI Agent

Dakota runs inside the OpenClaw gateway — an open-source AI agent framework (Node.js) that connects LLMs to messaging platforms with sandboxed tool access. OpenClaw handles the full agent lifecycle: message routing, tool execution, session management, and provider integration.

How Dakota Works

Capabilities

The Sandbox Model

Dakota operates in a double-containerized environment:

• Sandbox tools (default): Isolated container, no network, dropped capabilities, memory limits
• Elevated tools (explicit): Host-level access only from allowlisted senders with permission checks

Even if Dakota's prompt is compromised, the blast radius is contained to the sandbox. Host-level access requires passing through application-layer permission checks that cannot be bypassed by prompt injection.

Claude Code: The System Administrator

Claude Code runs on the host as the system administrator. Full host access: Docker, SSH, configuration files, deployments.

How Claude Code Operates

Not a long-running daemon — invoked on demand:

Each invocation is a fresh Claude Code instance with appropriate tool permissions scoped to the task.

Multi-Agent Collaboration

The two AI agents serve different roles, have different access levels, and communicate through structured protocols.

The Bridge Protocol

Claude Code can message Dakota via a bridge CLI. One-way: CC → Dakota. Every message is HMAC-SHA256 authenticated with a shared secret and 5-minute replay window. This prevents:

• Telegram messages from impersonating bridge commands
• Replay attacks on previously sent instructions
• External parties from injecting messages into the agent pipeline

The Request Broker

When Dakota needs host access:

1. Dakota writes a structured JSON request to shared directory
2. systemd detects via inotify
3. Claude Code instance spawned to evaluate
4. Claude Code emails operator with summary
5. Operator replies in natural language
6. Claude Code interprets and acts
7. Dakota notified via bridge

Request Broker State Machine

The Web Platform

The Azure web server hosts public-facing services: 41 Docker containers across 17 isolated networks.

GPU Infrastructure

The Azure A100 VM serves as the GPU compute node for model inference and research.

Cached Models

Security Architecture

Security is designed as defense-in-depth: seven layers, from hard boundaries to probabilistic defenses. The key principle is that no single layer is trusted to be sufficient.

Threat Model

The system acknowledges the Lethal Trifecta (Simon Willison's formulation): AI agent with private data + untrusted content + external actions. Dakota sits squarely in this trifecta.

What Happens When LLM Guard Flags Something

LLM Guard operates in enforce mode — flagged content is blocked, not just logged:

1. The incoming message is rejected before reaching the Claude API
2. Dakota does not see or respond to the flagged message
3. The event is logged and triggers a Wazuh SIEM alert (level 10+)
4. The operator receives notification via email and Telegram

LLM Guard Technical Details

• Model: DeBERTa (Microsoft language model fine-tuned for classification)
• Execution: Runs locally on CPU via ONNX — no external API calls
• Threshold: 0.8 (raised from 0.6 to reduce false positives on voice transcriptions)
• Failure mode: Fail-open — Dakota continues if LLM Guard goes down (hard boundaries still active)

SIEM and Monitoring

The entire infrastructure is monitored by Wazuh SIEM (deployed on both office server and web server):

• File integrity monitoring on critical configuration directories
• Custom alert rules for AI-specific events: sandbox execution, elevated command usage, LLM Guard injection flags, bridge authentication failures
• Active response: automatic IP blocking on SSH brute force
• Daily digest reports emailed to the operator
• Real-time alerts for high-severity events (level 10+) via email and Telegram

Automated Operations

Three-tier automated maintenance on systemd timers:

Session Health Watchdog

AI session corruption is the hardest operational challenge. When the Anthropic API returns malformed responses during streaming (truncated JSON, merged SSE events), session history can become permanently corrupted.

The system runs a session health watchdog every 5 minutes that:

1. Scans the tail of all session files for corruption patterns
2. Backs up corrupted sessions before modifying them
3. Truncates to the last valid boundary
4. Automatically restarts the OpenClaw container on repair

Secret Rotation

A quarterly/semi-annual/annual rotation schedule covers all secrets, with:

• A systemd timer that checks which secrets are due each month
• Automated email reminders to the operator
• A documented post-rotation checklist

Data Flows

Telegram Message Flow

Calendar Aggregation Flow

Trade-offs and Design Decisions

What Works Well

What Requires Compromise

Risks

Technical Risks

What Survives a NUC Failure

If the office server goes down (hardware failure, power outage, disk failure):

Recovery: No automated disaster recovery. Git repos and Docker volumes are local-only — a disk failure without backup means total configuration loss. This is an acknowledged trade-off: simplicity and security (no cloud exposure) over resilience.

AI-Specific Risks

Opportunities

Near-term

• Local model fallback — A100 as backup when Anthropic unavailable
• Proactive monitoring — Trend analysis and preventive action
• Multi-agent delegation — Specialized agents for code review, security

Medium-term

• Self-healing infrastructure — Automatic failure detection and remediation
• Organizational knowledge base — Extend knowledge graph to decisions, policies

Long-term

• Replicable architecture — Reference architecture for small teams
• Federated agent networks — Cross-organization collaboration

Lessons Learned

Appendix: Service Inventory

Office Server (clawdbot)

Azure Web Server

Azure A100 VM