trading-system-docs/red-queen-architecture/control-plane/cp2a2_2b/SECURITY.md

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 10000 / 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.