# Sicherheitsmodell

## Netzgrenze

- Open WebUI und Router veröffentlichen keinerlei Host-Ports.
- Ein dedizierter WireGuard-Container stellt auf seiner VPN-Adresse nur 8080
  und 8081 bereit.
- Die egressfähigen Docker-Netze verwenden eigene Routingtabellen.
- Heimnetz- und optionaler Internetverkehr laufen über WireGuard.
- Die Tabellen zeigen ausschließlich zum Gateway-Container und besitzen keine
  Route über das Standortgateway. Das ist der Fail-Closed-Mechanismus.
- Der Host ist kein Router zwischen Universitäts- und Heimnetz.

Da keine KI-Ports publiziert werden, kann Docker die Host-Firewall an dieser
Stelle nicht umgehen. SSH bleibt davon getrennt und schlüsselbasiert auf der
physischen Schnittstelle erreichbar.

## Containergrenzen

- llama.cpp: read-only, keine Capabilities, Modelle read-only, keine Ports.
- Router: unprivilegierter Benutzer, kein Docker-Socket, feste API-Oberfläche.
- Profile Controller: einzige Socket-Ausnahme; feste Profile und nur
  List/Start/Stop, keine frei wählbaren Images, Befehle oder Mounts.
- Open WebUI: einziges persistentes Chat-Volume.
- MCP-Fachcontainer: intern, getrennte Secrets und keine Host-Ports.
- TinySearch/SearXNG: intern, Suchanfragen ohne Chatverlauf.

llama.cpp bekommt weder MCP-Konfiguration noch HA-, ARR- oder Unraid-Secrets.
Open WebUI kennt nur interne MCP-URLs; Authentisierung zu den Zielsystemen
findet im jeweiligen Fachcontainer statt. Externe MCP-Clients werden erst über
einen authentifizierten WireGuard-Gateway zugelassen.

Ein Docker-Socket bleibt grundsätzlich privilegiert. Der Controller reduziert
die erreichbare Funktion stark, ersetzt aber keine zusätzliche Socket-Proxy-
Sandbox. Er ist klein, testbar und nicht von Clients direkt erreichbar.

## Secrets und private Daten

- Keine Secrets in Git, Prompts, MCP-Schemas, Logs oder Screenshots.
- Installer-Konfiguration und `/etc/mike-ai/*` haben restriktive Rechte.
- Router-, Controller- und WebUI-Schlüssel sind getrennt und zufällig.
- Das Modell bekommt keine Schlüsselwerte zurück; spätere Integrationen nutzen
  lokale Broker/Environment-Dateien.
- Open-WebUI-Volume kann Chats enthalten und wird nur verschlüsselt gesichert.

## Werkzeugprofile

| Modus | Erlaubte Werkzeuge |
|---|---|
| Standard | lokale Websuche, harmlose Hilfsfunktionen |
| Home Assistant | eigener begrenzter HA-MCP |
| ARR | Sonarr/Radarr, zuerst read-only |
| Unraid Diagnose | Status und eng begrenzte Logs |
| Administration | Vorschau, Approval-Ticket, Verifikation |

Allgemeine Shell, beliebiges SSH/SCP, freies `curl`, Docker-Administration und
freie Dateisystemsuche gehören nicht ins Standardprofil. Für die Athena-
Plattform existiert genau ein Operator-MCP. Seine unprivilegierte Fassade sieht
nur einen lokalen Unix-Socket; ein rootseitiger Executor besitzt die für
Repository, Docker, Modelle, Git und Recovery notwendigen Rechte. Er bietet
keinen beliebigen Befehl an, sondern strukturierte Operationen mit Vorschau,
Inhaltsbindung, Ablaufzeit und späterer exakter Freigabe. SSH-, Netzwerk-,
WireGuard-, Firewall-, Boot-, Kernel-, Treiber-, Partitions-, Reboot- und
Shutdown-Änderungen liegen außerhalb seiner API.

## Schreibaktionen

Persistente oder destruktive Änderungen folgen immer: Bestandsaufnahme,
exakte Vorschau, an die Vorschau gebundene Freigabe, unveränderte Ausführung,
anschließende Verifikation.

## Vor jedem Push

- Private-Key-, Token-, Passwort- und API-Key-Muster suchen.
- Keine `.env`, Zertifikate, Logs, Bilder, Audio oder Modelle einchecken.
- Beispiele enthalten nur Platzhalter; interne Hostnamen nur wenn bewusst.
- Änderungen am Controller und Netzwerkguard mit Tests und Review versehen.