# CP2A2.2B — L1 Red Queen Worker: Security-Dokumentation
# STRICTLY NON-AUTONOMOUS / NON-PRODUCTIVE. NO AUTONOMY. NO HEARTBEAT. NO SCHEDULER.

## 1. Zweck

Separate minimale L1 Worker Runtime (`l1-red-queen-worker`) als technische
Sandbox/Foundation fuer spaetere Read-only-Autonomie. In CP2A2.2B:
- KEINE Autonomie
- KEINE Mission Execution
- KEIN Heartbeat
- KEIN Scheduler
- KEIN autonomer Tick

Der bestehende interaktive Container `hermes-red-queen` bleibt UNVERAENDERT.

## 2. Security-Invarianten (permanent)

RED_QUEEN_TRADING_AUTHORITY=NEVER

Der L1 Worker darf niemals erhalten:
- Broker Credentials
- Broker APIs
- Trading Tokens
- Trading Execution Authority
- Trading Kill-Switch Authority

Trading ist eine separate Security Domain.

Zusaetzlich:
- MISSION != AUTHORIZATION
- COMMAND != AUTHORIZATION
- RQ_DECISION != AUTHORIZATION
- GATE_CHECK != CAPABILITY_GRANT

## 3. Credential Zero Policy

Im L1 Worker sind ABSENT:
- FORGEJO_WRITE_TOKEN, NOTION_API_KEY, TELEGRAM_BOT_TOKEN
- SAVE_TOKEN, DELETE_TOKEN
- SSH private keys, Git write credentials, .netrc, .git-credentials
- credential helpers mit Secrets
- Cloud Credentials, DB Credentials (produktive externe DBs)
- Service Account Credentials, Webhook Secrets, Generic Bearer Tokens
- Docker Credentials, Broker Credentials, Trading Credentials

Geprueft werden: ENV files, mounted secrets, process environment, config,
home directory, git config, credential helpers.

Report: NUR PRESENT/ABSENT. NIEMALS Secret-Werte ausgeben.

## 4. Container-Hardening

- non-root UID/GID: hermes-User (UID 10010 / GID 10000)
- read-only rootfs
- cap_drop ALL
- no-new-privileges
- kein privileged
- kein Docker-Socket
- keine Host-Root-Mounts
- keine Host-Namespaces
- keine Device-Mounts
- keine unnecessary Linux capabilities

Writable nur: worker-owned internal state volume + technisch zwingende tmpfs-Pfade.

## 5. Tool-Capability-Model

Der Worker darf NICHT haben:
- terminal, generic shell, execute_code
- write_file auf externe/shared Ziele, patch
- git push, SSH, Docker, cronjob, send_message, delegation
- arbitrary command execution

MAX_SUBAGENTS=0. Nur minimal erforderliche Read-only-Faehigkeiten.

Ground-Truth-Verifikation: prueft die tatsaechlich geladenen Toolsets,
nicht nur die Config.

## 6. Network-Model

KEIN allgemeiner Internet-Egress. Worker erreicht nur:
- A. Gate Evaluator (internal)
- B. Ollama (internal)
- C. Tolaria READ/Search (internal)

NICHT erreichbar:
- Telegram API, Notion API, Forgejo public Host
- Internet allgemein, Trading Networks, Broker endpoints
- Docker API, Host management interfaces
- SAVE executor, DELETE executor

Keine generische Proxy-/Relay-Loesung.

## 7. Gate Evaluator

Worker darf den bestehenden Gate Evaluator erreichen. CP1 bleibt unveraendert.
Aktuell: GLOBAL_AUTONOMY=OFF, PRODUCTIVE_MUTATIONS=OFF, SAVE=OFF, DELETE=OFF,
EMERGENCY_STOP=ON. Daher muss jeder produktive AUTONOMOUS_TICK_START weiterhin
DENY ergeben. KEIN State aendern, um ALLOW zu testen.

## 8. Tolaria

Nur READ/Search. Worker darf KEINEN Tolaria SAVE/DELETE Token erhalten.
NICHT produktiv schreiben. Keine Mutation als Test.

## 9. Ollama / LLM

Worker darf Ollama erreichen (fuer Hermes-Start erforderlich). Keine
Credentials noetig. Keine dadurch entstehende externe Mutation Capability.
KEINE autonome Mission ausfuehren.

## 10. Internal State Volume

Worker-eigenes persistentes State-Volume. Noch KEINE produktive A2-A5
Initialisierung. Erlaubt: leeres/verifiziertes State-Verzeichnis bzw.
Foundation-Struktur. Noch NICHT: missions.db produktiv initialisieren,
safety runtime starten, orchestration runtime starten, heartbeat starten,
tick loop starten. Worker State darf ausschliesslich vom Worker beschrieben
werden. Bestehende interaktive RQ darf dieses Volume NICHT schreiben.

## 11. Mission Transfer — NOT YET

In CP2A2.2B: KEIN Shared Mission Volume, KEINE Mission Queue, KEIN Mission
Broker, KEIN Mission Snapshot produktiv anbinden. Mission Transfer kommt
separat danach.

## 12. No Autostart Autonomy

Nach Host-Reboot, Docker-Reboot, Container-Restart, Compose-up darf NICHT
automatisch ein autonomer Tick beginnen. Worker Foundation darf existieren/
starten, aber autonome Mission Execution bleibt unmoeglich. Gate DENY allein
ist nicht die einzige Schutzschicht. Es darf noch gar kein autonomer
Scheduler/Loop existieren.

## 13. Resource Limits

Konservative Foundation-Limits (siehe docker-compose / deploy):
- CPU limit
- memory limit
- pids limit
- bounded tmpfs
- log rotation

Ein fehlerhafter Worker darf den Host nicht durch Ressourcenverbrauch
beeintraechtigen.