ClawdDotNet/docs/Security-Konzept.md

# Security-Konzept: Einschließen, Regeln, Überwachen

> **Rolle:** Bauplan. Stand 2026-09-19, entstanden aus dem Orchestrator-Vergleich
> (OpenClaw, Grok Bot, Claude Code/Codex, OpenHands, LlamaFirewall, CaMeL) und der
> Abstimmung mit dem Nutzer. Reihenfolge und Status stehen im Deploymentcenter, nicht
> hier.

## 1 — Das Ziel in einem Satz

**Ein bösartiger Agent — auch einer, der durch eingeschleusten Text übernommen wurde —
darf seinen Workspace nicht verlassen und nichts Schädliches tun.** Das muss auch dann
gelten, wenn Agenten eigene Skripte schreiben und ausführen.

## 2 — Der Grundsatz: das Modell ist nie die Grenze

Ein Überwachungsagent kann einen Ausbruch nicht verhindern, nur hinterher bemerken. Und
er ist selbst angreifbar: Er liest genau die Verläufe, in denen der eingeschleuste Text
steht. Deshalb vier Schichten, nach Kosten sortiert — die unteren drei sind
deterministisch und kosten keine Tokens, erst die oberste fragt ein Modell:

| Schicht | Was | Kosten | Verhindert / erkennt |
|---|---|---|---|
| 0 Einschließen | Sandbox-Runner für jede Codeausführung | keine Tokens | verhindert |
| 1 Regeln vor dem Aufruf | PermissionGate, Staging, Herkunftsregel, Netzprofil | keine Tokens | verhindert |
| 2 Regelbasierte Überwachung | Detektoren über das Audit, Köderwerte | keine Tokens | erkennt sofort |
| 3 Security-Agent | Einschätzung auf Anlass, Skriptprüfung, Stichprobe | gedeckelt | erkennt, bewertet |

So machen es die Systeme, die tragen: Claude Code und Codex setzen die Grenze im
Betriebssystem (bubblewrap bzw. Landlock + seccomp) und prüfen mit einem Modell nur
zusätzlich. OpenClaw zeigt die Gegenseite — dort ist die Sandbox *optional*, und die
Vorfälle mit ClawHub kamen genau daher.

### Warum das jetzt dran ist

Heute laufen alle Agenten **in einem Prozess unter einem Linux-Benutzer**. Die
Workspace-Grenze ist C#-Code in den Werkzeugen (`PathBoundary`); #373 hat gezeigt, wie
leicht sie bricht. Das trägt, solange Agenten keinen eigenen Code ausführen. Ein
Python-Skript fragt `PathBoundary` nicht — `open('/home/...')` geht am Werkzeug vorbei.
Und der Hauptprozess hält den entsperrten Hauptschlüssel.

**Regel, nicht verhandelbar: Fremder Code läuft nie im Hauptprozess.** Kein Skript,
keine Shell, kein MCP-stdio-Server ohne den Runner aus Schicht 0.

### Das Bedrohungsmodell wird um eine Klasse erweitert

Bisher: rein interner Betrieb; Schutz gegen Ordner-Kopieren und gegen Schadsoftware, die
nach Zugangsdaten sucht. Das bleibt. Neu: **Der Angreifer ist Inhalt, keine Person** —
eine Webseite, eine Mail, eine Chatnachricht, ein Tool-Ergebnis, das einen Agenten
umsteuert. Interner Betrieb schützt davor nicht, weil die Agenten Fremdinhalt lesen,
sobald sie ihre Arbeit tun.

## 3 — Schicht 0: Sandbox-Runner

Ein gemeinsamer Runner für alles, was Code ausführt: Shell (#196), freigegebene Skripte
(Abschnitt 7), MCP-stdio-Server (#197) und die heutigen `yt-dlp`/`ffmpeg`-Aufrufe des
`SocialMediaManagerTool`.

Garantien, jede mit einem Test, der den Ausbruch versucht:

- **Dateisystem:** Nur der Workspace des Agenten ist beschreibbar und sichtbar; System
  schreibgeschützt, `$HOME`, Instanzverzeichnis, Schlüsselbund und die Workspaces anderer
  Agenten sind nicht vorhanden (eigener Mount-Namespace, nicht bloß gesperrt).
- **Erbe:** Keine Umgebungsvariablen, keine offenen Dateideskriptoren, keine Secrets des
  Hauptprozesses. Was ein Skript braucht, bekommt es ausdrücklich übergeben.
- **Netz:** Standardmäßig kein Netz (eigener Netz-Namespace). Freigabe nur über den
  Egress-Proxy, siehe Abschnitt 5.
- **Grenzen:** Laufzeit, Speicher, Prozesszahl, Ausgabegröße; seccomp-Filter; kein
  Rechteerwerb (`no_new_privs`).
- **Umsetzung:** `bwrap` unter Linux. Ein eigener Linux-Benutzer je Agent ist die
  spätere Stufe, falls die Namespace-Trennung einmal nicht reicht.

- **Nichts, was der Hauptprozess liest, ist in der Sandbox beschreibbar.** Task-Dateien,
  Skills, Identity/Soul, Skript-Manifeste, Gedächtnis-Importe und jede Konfiguration
  liegen außerhalb des beschreibbaren Bereichs oder sind dort schreibgeschützt
  eingebunden. Das ist die Lehre aus CVE-2026-25725 bei Claude Code: Code in der Sandbox
  legte Hooks an, die beim nächsten Start mit vollen Rechten liefen. Eine Sandbox, die
  Dateien schreiben darf, die draußen ausgeführt oder als Anweisung gelesen werden, ist
  keine Grenze, sondern ein verzögerter Ausbruch. Ein Test gehört dazu: Die Sandbox
  versucht jede dieser Dateien zu schreiben.

Unter Windows gibt es keinen Runner und damit **keine Codeausführung** — die Funktion
fehlt dort, statt schwächer zu sein.

*Gebaut am 2026-09-25 (#654), geprüft unter Ubuntu 26.04 mit bwrap 0.11.1 auf der
Test-VM.* Was beim Bau dazukam und in keinem Handbuch steht:

- **Die Wurzel der Sandbox ist beschreibbar**, wenn man nichts tut: bwrap baut sie als
  eigenes tmpfs. Erst `--remount-ro /` nach allen Einbindungen macht daraus „nur `/work`
  und `/tmp`“. Der Ausbruchstest hatte unter `/etc` eine Datei angelegt.
- **Der seccomp-Deskriptor wird weitergereicht.** bwrap liest den Filter über fd 3 und
  lässt ihn im Programm offen; die innere Shell schließt ihn vor dem Start.
- **Die Prozessgrenze** (RLIMIT_NPROC) wird *innerhalb* des eigenen User-Namensraums
  gesetzt. Dort zählt sie nur die Prozesse der Sandbox, nicht die Threads der Instanz
  (auf der VM über tausend unter demselben Benutzer). Das ist mit einem Gegenfall
  belegt: 5 von 10 gehen, 12 nicht. dash kennt dafür `ulimit -p`, bash `ulimit -u`.
- **`--die-with-parent` hängt am Thread, nicht am Prozess.** Das Elternsterbe-Signal
  des Kernels feuert, wenn der *Thread* endet, der den Prozess gestartet hat. .NET
  startet aus einem Threadpool-Thread, und unter Last baut der Threadpool Threads ab.
  Folge auf der VM: bwrap bekam mitten im Lauf SIGKILL, und starb er noch im Aufbau,
  lebte das Innere als Waise weiter. Alle Sandboxen starten deshalb aus einem eigenen,
  dauerhaften Thread. Zum Beenden wird der ganze Baum unter bwrap aus `/proc`
  eingesammelt und getötet, samt PID 1 des Namensraums, dessen Tod den Rest mitnimmt.
- **Erster Nutzer ist ffmpeg** im SocialMediaManager, weil es heruntergeladene Medien
  zerlegt. yt-dlp braucht Netz und kommt mit dem Egress-Proxy (#655) in die Sandbox; bis
  dahin läuft es wie bisher und das Protokoll sagt es.

## 4 — Schicht 1: Regeln vor dem Aufruf

Vorhanden: PermissionGate (Werkzeug je Agent), Staging mit Plan-Freeze, `PathBoundary`,
`UrlGuard`, `SqlGuard`. Neu:

### 4.1 Herkunftsregel

Vorbild CaMeL, in der einfachsten Form. Sobald ein Lauf **Fremdinhalt** gelesen hat —
WebFetch, Mail, Chat, eine Datei, die nicht der Agent selbst geschrieben hat, das
Ergebnis eines MCP-Servers —, gilt der Lauf als *belastet*. Ab dann ist jede Aktion mit
**Außenwirkung** freigabepflichtig, egal was die Policy sonst sagt: Mail senden, posten,
FTP-Upload, Schreiben in die Datenbank, Nachricht an andere Agenten, Task an andere
Agenten.

Das kostet nichts und nimmt einer übernommenen Anweisung genau die Wirkung, um die es
geht: Sie kann lesen und vorschlagen, aber nicht handeln. Welche Werkzeuge Fremdinhalt
liefern und welche Außenwirkung haben, erklärt jedes Werkzeug selbst (wie
`StagingAktion` seit #609). Die Freigabe-Nachricht (#644) nennt die Quelle, die den Lauf
belastet hat.

**Freigabemüdigkeit ist der eigentliche Gegner dieser Regel.** Der Sicherheitsvergleich
vom 2026-09-19 hat sie als realistischstes Einfallstor ausgemacht: Fast jeder Agent liest
Fremdinhalt, fast jeder Lauf wird belastet, und wer 40 Freigaben am Tag abnickt, ist
selbst der Umgehungsweg. Deshalb gehört zur Regel:

- **Feste Ziele sind ausgenommen.** Außenwirkung an Ziele, die ein Mensch vorab
  eingerichtet hat — die eigenen Kanäle, `@human`, fest hinterlegte Empfänger je Agent —
  bleibt ohne Freigabe. Eine Injection kann dorthin schreiben, aber niemanden erreichen,
  den der Betreiber nicht selbst ausgewählt hat.
- **Muster-Freigabe auf Zeit.** Ein wiederkehrender Aufruf (gleicher Agent, gleiches
  Werkzeug, gleiches Ziel) kann für eine begrenzte Frist freigegeben werden, statt jeden
  Einzelfall zu bestätigen. Nie für hohe Risiken, nie ohne Ablauf.
- **Die Freigabequote wird sichtbar** (Abschnitt 10). Wer 100 % durchwinkt, hat keine
  Kontrolle mehr, sondern eine Verzögerung — das soll man sehen, nicht vermuten.
- **Die Vorschau zeigt Herkunft.** Argumente, die Daten aus sensiblen Quellen tragen
  (Gedächtnis, Datenbank, Dateien außerhalb von `out/`), werden in der Freigabe
  hervorgehoben — sonst geht ein Abfluss, versteckt in einem langen Argument, durch die
  Freigabe hindurch.

### 4.2 Schutz vor Amoklauf

Rate-Limits je Werkzeug und Agent, Circuit-Breaker bei gehäuften Fehlern oder
Ablehnungen — der Übergang zur Quarantäne (Abschnitt 6). Aus dem
[Erweiterungskonzept](Orchestrator-Erweiterungskonzept-2026.md).

### 4.3 Belastung wandert mit

Die Lücke, die der Vergleich aufgedeckt hat und die kein anderes Konzept schließt: Ein
belasteter Lauf schreibt einen Gedächtniseintrag, einen Skill-Entwurf oder einen Task.
Ein *späterer, unbelasteter* Lauf lädt ihn — und die eingeschleuste Anweisung wirkt
jetzt ohne Herkunftsmarke. Die Herkunftsregel wäre über einen Umweg ausgehebelt.

Deshalb: **Was ein belasteter Lauf hinterlässt, trägt die Marke weiter** — Gedächtnis,
Skill-Entwürfe, Tasks und Task-Kommentare, Dateien im SharedWorkspace. Die Engine
stempelt sie, nicht der Agent. **Wer einen markierten Eintrag lädt, wird selbst
belastet.** Ein Mensch kann einen Eintrag nach Prüfung entlasten; das steht im Audit.
Skill-Entwürfe aus belasteten Läufen sind in der Freigabe (#198) ausdrücklich markiert.

## 5 — Netzprofil je Agent

Ein Agent hat **drei getrennte Wege ins Netz**. Sie werden oft in einen Topf geworfen,
sind aber verschieden gefährlich und brauchen eigene Schalter.

| Weg | Wer ruft auf | Wer wählt das Ziel | Heute | Einstellung |
|---|---|---|---|---|
| **Modell** | die Engine, zu OpenRouter | niemand — immer OpenRouter | fest | Modell-Netzprofil (5.1) |
| **Werkzeuge** | der Hauptprozess (WebFetch, Mail, MCP …) | der Agent, im Rahmen der Allowlist | WebFetch mit Domain-Allowlist, muss je Agent freigegeben werden | bleibt je Werkzeug |
| **Sandbox** | ein Skript oder Shell-Befehl | der Code | gibt es noch nicht | aus; Freigabe je Skript (5.2) |

Der Weg zu OpenRouter ist **kein** Internetzugang des Agenten: Die Engine spricht mit
genau einem Ziel, der Agent kann weder Adresse noch Inhalt der Verbindung bestimmen. Er
wird aber dann zum Internetzugang, wenn das *Modell selbst* suchen darf.

### 5.1 Modell-Netzprofil (je Agent, in den Modelleinstellungen)

- **Websuche des Modells:** OpenRouter kann dem Modell eine eigene Websuche geben (Plugin
  `web` oder das Suffix `:online` am Modellnamen). Das ist ein Netzweg, an dem weder
  Staging noch Audit vorbeikommen. **Voreinstellung aus**; ein Modellname mit `:online`
  wird abgelehnt, solange der Schalter aus ist.
- **Datennutzung beim Anbieter:** `data_collection: deny` als Voreinstellung (das Feld
  ist in `ProviderPreferences` schon vorhanden, wird aber noch nicht gesetzt); optional
  nur Anbieter ohne Datenspeicherung.
- **Anbieter-Allowlist und Ausweichen:** Welche Anbieter ein Agent nutzen darf, ob auf
  andere ausgewichen werden darf (`allow_fallbacks`).
- `require_parameters` bleibt an (#550).

### 5.2 Sandbox-Netz

Standard: kein Netz. Braucht ein Skript Netz, **deklariert es die Ziele in seinem
Manifest** (Abschnitt 7), und die Freigabe des Skripts umfasst diese Ziele. Durchgesetzt
wird es vom Egress-Proxy: nur die deklarierten Domains, nur HTTPS, jeder Abruf im Audit.
Ein Skript, das etwas anderes erreichen will, scheitert und erzeugt einen Befund.

*Der Egress-Proxy ist gebaut (2026-09-25, mit #712), die Anbindung an Skript-Manifeste
noch nicht (#655, #695).* So umgesetzt:

- **Die Sandbox teilt nie das Netz des Hosts.** Mit geteiltem Netz sähe sie alles, was der
  Host auf Loopback anbietet, darunter den Port der Weboberfläche und eine Datenbank. Sie
  sähe außerdem abstrakte Unix-Sockets wie ein X11-Display, denn die gehören zum
  Netz-Namensraum, nicht zum Dateisystem. Die Sandbox behält ihr Netz mit nur Loopback. Ein
  Starter in der Sandbox (die Anwendung mit `--sandbox-launch`) lauscht dort auf
  `127.0.0.1:3128` und reicht jede Verbindung an einen Unix-Socket weiter. Der Socket ist
  eingebunden, dahinter steht der Proxy im Hauptprozess.
- **Nur `CONNECT host:port`**, also ein TLS-Tunnel. Klartext-HTTP wird abgewiesen. Der Host
  muss auf der Liste stehen (`host`, `host:port`, `*.domain` nur für Subdomains).
  Adressliterale stehen nie auf der Liste.
- **Namen löst der Proxy auf, nicht die Sandbox.** Löst ein gelisteter Name auch nur
  teilweise auf eine nicht-öffentliche Adresse auf, wird er ganz abgewiesen. Das betrifft
  Loopback, private Netze, CGNAT, Link-Local (Metadaten-Dienste), Multicast und
  IPv6-Hüllen wie 6to4 und NAT64. So kommt kein DNS-Rebinding auf die Instanz.
- Jede Verbindung und jede Abweisung steht im Log. Im Audit steht sie noch nicht, das kommt
  mit den Manifesten.

Geprüft unter Linux in der echten Sandbox (`SandboxLaunchTests`): Ein gelisteter Host
antwortet, ein anderer bekommt 403, `--noproxy` findet kein Netz, und ein Dienst auf dem
Loopback des Hosts ist nicht erreichbar.

## 6 — Befunde und Quarantäne

### 6.1 Zwei Stufen

| Stufe | Beispiele | Reaktion | Aufheben |
|---|---|---|---|
| **Niedrig** | gehäufte Ablehnungen, Kostensprung, neue Zieldomain, Änderung an Identity/Soul | Nachricht über den Kanal (#644) mit Quarantäne-**Vorschlag** — per Button bestätigen oder verwerfen | im Messenger oder in der Oberfläche |
| **Hoch** | Köderwert in einem ausgehenden Aufruf, Ausbruchsversuch aus der Sandbox, Zugriff auf fremde Workspaces, Skript weicht vom freigegebenen Hash ab | **sofortige Quarantäne**, Nachricht über den Kanal **ohne** Schaltfläche | **nur in der Oberfläche**, nach Prüfung |

Warum hoch nicht per Messenger: Der Messenger ist ein Kanal, über den auch Fremdinhalt
kommt, und ein Telefon geht leichter verloren als der Zugang zur Oberfläche. Wer einen
Agenten nach einem Köder-Treffer wieder freilässt, soll die Belege vor sich haben.

### 6.2 Was Quarantäne heißt

- Der Agent nimmt keine neuen Läufe an (Scanner überspringt ihn, Chat wird abgewiesen).
- Ein laufender Lauf endet beim nächsten Schritt; Sandbox-Prozesse des Agenten werden
  beendet.
- Alle ausgehenden Nachrichten des Agenten werden zurückgehalten.
- Seine offenen Freigabe-Vorschläge werden gesperrt, nicht gelöscht.
- Alles ist umkehrbar und steht im Audit. Nichts wird gelöscht.

### 6.3 Ausnahmen für bekannte Befunde

Damit dieselbe Meldung nicht jeden Tag wiederkommt:

- Jeder Befund hat einen **Fingerabdruck** aus Detektor, Agent, Werkzeug und normalisiertem
  Ziel. Gleiche Fingerabdrücke innerhalb eines Zeitfensters werden zu einem Befund mit
  Zähler zusammengefasst, statt neu gemeldet zu werden.
- Eine **Ausnahme** gilt für einen Fingerabdruck, trägt Begründung, Urheber und ein
  **Ablaufdatum** und steht im Audit. Ausnahmen ohne Ablauf gibt es nicht.
- Ausnahmen für niedrige Befunde gehen auch im Messenger („nicht mehr melden, 30 Tage"),
  für hohe nur in der Oberfläche.
- **Nie ausnehmbar:** Köder-Treffer und Sandbox-Ausbruchsversuche.

## 7 — Skripte, die Agenten selbst schreiben

Vorgabe: Freigegebene Agenten dürfen eigene Skripte schreiben. Ausgeführt wird nur, was
geprüft ist; **jede Änderung, auch ein Bugfix, braucht eine neue Prüfung.**

- **Wer darf:** nur Agenten mit der Fähigkeit „Skripte schreiben". Standard aus.
- **Form:** Das Skript liegt im Workspace unter `scripts/`, daneben ein Manifest: Zweck,
  Interpreter, Eingaben, Ausgaben, Netzziele (5.2), Laufzeitgrenze.
- **Bindung:** Die Freigabe gilt für den SHA-256 von Skript **und** Manifest **und** die
  Interpreter-Fassung — nach dem Vorbild von OpenClaws Exec-Freigaben, die an Befehl,
  Arbeitsverzeichnis und Datei-Hashes gebunden sind. Ändert sich ein Byte, passt der Hash
  nicht mehr: nicht ausführbar, neue Prüfung. Versucht ein Agent, ein verändertes Skript
  auszuführen, ist das ein hoher Befund.
- **Saubere Umgebung.** Der Hash allein reicht nicht: Im August 2026 wurde Claude Codes
  Auto-Modus umgangen, indem ein Archiv eine Datei `struct.py` in das Arbeitsverzeichnis
  legte, die beim Import eines Standardmoduls mitgeladen wurde („confused environment").
  Ein freigegebenes Skript läuft deshalb **aus einer schreibgeschützten, sauberen Kopie**,
  mit `python -I` (kein Arbeitsverzeichnis, kein `PYTHONPATH` im Suchpfad), mit
  Abhängigkeiten, die im Manifest **mit Hash** festgeschrieben sind, und der Workspace ist
  nur als Datenverzeichnis unter einem eigenen Pfad eingebunden. Was das Skript lädt, ist
  damit genau das, was geprüft wurde.
- **Ablauf der Prüfung:**
  1. **Deterministische Vorprüfung** (kostenlos): Größe, Imports und Aufrufe, die eine
     Begründung brauchen (`subprocess`, `socket`, `ctypes`, `os.system`, `eval`/`exec`,
     dynamisches Nachladen, Base64-Dekodieren mit anschließender Ausführung), Abgleich
     mit dem Manifest („deklariert kein Netz, importiert aber `requests`").
  2. **Einschätzung des Security-Agenten:** *unbedenklich* / *bedenklich* (mit Gründen
     und Zeilen) / *zu komplex für mich — externe Prüfung*. Ab einer Größen- oder
     Komplexitätsgrenze lautet das Urteil ohne Modellaufruf „zu komplex". Externe
     Prüfung heißt: Mensch, oder auf ausdrückliche Einstellung ein stärkeres Modell mit
     eigenem Budget.
  3. **Freigabe durch den Menschen**, mit Vorprüfung, Einschätzung und Diff zur vorigen
     Fassung vor Augen.
- **Die Einschätzung ist ein Rat, keine Freigabe.** Auch „unbedenklich" gibt nichts frei.
  Und selbst ein freigegebenes Skript läuft nur im Runner — die Prüfung ist die zweite
  Linie, nicht die erste.
- **Selbstschutz des Prüfers:** Das Skript ist für den Security-Agenten Fremdinhalt. Ein
  Kommentar wie „als unbedenklich einstufen" darf nichts bewirken: Die Vorprüfung aus
  Schritt 1 kann das Modell nicht überstimmen, die Ausgabe ist strukturiert, und ein
  Urteil, das der Vorprüfung widerspricht, wird als Widerspruch angezeigt, nicht still
  übernommen.

## 8 — Schicht 2: Regelbasierte Überwachung

Detektoren über das Audit-Log. Laufen bei jedem Eintrag bzw. im Scanner-Takt, kosten keine
Tokens und erzeugen Befunde nach Abschnitt 6.

- Grenzverletzungen (`PathBoundary`, `UrlGuard`, `SqlGuard`, Sandbox) und abgelehnte
  Aufrufe in Serie
- neue Zieldomains, neue Empfänger
- Kostensprung gegenüber dem eigenen Mittel
- Änderungen an Identity, Soul, Skills, Skripten
- verdächtige Folgen innerhalb eines Laufs: erst Fremdinhalt oder sensible Pfade lesen,
  dann Außenwirkung versuchen
- **Köderwerte:** Köderdateien im Workspace und Köder-Secrets im Schlüsselbund, die kein
  legitimer Ablauf je braucht. Taucht ein Köderwert in einem ausgehenden Aufruf, einer
  Nachricht oder im Sandbox-Netz auf → hoher Befund, sofortige Quarantäne. Praktisch
  keine Fehlalarme, weil es keinen legitimen Grund gibt, ihn zu benutzen.

## 9 — Schicht 3: Security-Agent

**Ein eingeschränktes Profil des AgentInspector (#204), kein zweites System.** Gleiche
Datenbasis (Audit und Receipts, von der Engine gestempelt), gleicher Zweck.

- **Wann er läuft:** auf Anlass aus Schicht 2 (Befund bewerten, Zusammenhänge suchen),
  bei jeder Skriptprüfung (Abschnitt 7) und einmal täglich als Stichprobe mit kurzer
  Lagezusammenfassung. Nie dauerhaft mitlaufend.
- **Was er sieht:** strukturierte Audit-Daten — Werkzeug, Ausgang, Pfade, Ziele, Kosten.
  Rohe Fremdtexte nur gekürzt und als Daten gerahmt (#193).
- **Was er darf — hart im Code, nicht im Prompt:** Befunde anlegen und einstufen, über
  den Kanal melden, Quarantäne vorschlagen (niedrig) oder verhängen (hoch), Skripte
  einschätzen. **Nie:** freigeben, Quarantäne aufheben, Ausnahmen anlegen, Regeln oder
  Einstellungen ändern, Werkzeuge mit Außenwirkung benutzen.
- **Kosten:** günstiges Modell, eigenes Tagesbudget im Budget-Guard mit hartem Deckel.
  Ist der Deckel erreicht, laufen Schicht 0 bis 2 unverändert weiter, nur Einschätzungen
  bleiben aus — und das wird im Sicherheitsbereich angezeigt. Planbar wird es durch den
  Deckel und dadurch, dass Schicht 2 vorfiltert.

## 10 — Sicherheitsbereich in Oberfläche und WebUI

Eigener Menüpunkt auf Instanzebene, in Avalonia und in der Weboberfläche gleich
aufgebaut:

- **Freigabequote** je Agent und Werkzeug: wie viel wird freigegeben, wie schnell, wie
  oft abgelehnt. Eine Quote nahe 100 % bei hoher Zahl ist selbst ein Befund.
- **Lage:** Sandbox verfügbar, Schlüsselbund dicht, Agenten in Quarantäne, offene
  Befunde, offene Skriptprüfungen, Kanalzustand (#645), Budget des Security-Agenten.
- **Befunde:** Liste mit Stufe, Fingerabdruck, Zähler, Beleg aus dem Audit; Quarantäne
  aufheben (hoch: nur hier), Ausnahme anlegen.
- **Skripte:** ausstehende Prüfungen mit Vorprüfung, Einschätzung und Diff; freigegebene
  Skripte mit Hash und Freigabe-Datum.
- **Richtlinien je Agent:** Netzprofil (Abschnitt 5), Herkunftsregel, Skript-Fähigkeit,
  Sandbox-Grenzen.
- **Ausnahmen:** mit Ablauf, Urheber, Begründung.
- **Selbstprüfung auf Drift:** „Sandbox konfiguriert, aber nicht verfügbar", „Modell mit
  `:online` bei ausgeschalteter Websuche", „Agent darf Skripte schreiben, Runner fehlt".
  Vorbild `openclaw security audit`; die Prüfungen gehören zu den Bausteinen von #648.

Zwei Regeln:

- **Agenten kommen an diesen Bereich nicht heran** — auch AgentEditor und ein
  Personalmanager-Agent nicht. Seine Einstellungen liegen außerhalb dessen, was ein
  Werkzeug schreiben kann.
- **Wer eine Regel lockert, bestätigt ausdrücklich**, und die Änderung steht im Audit.
  In der Weboberfläche verlangt das eine erneute Anmeldung.

## 11 — Zugangsdaten: der Agent sieht sie nie

*Ergänzt am 2026-09-22 nach einem Vorschlag des Nutzers.*

Heute bekommt ein Werkzeug seine Zugangsdaten aus der Konfiguration des Agenten. Wo ein
Agent eine fremde API bedienen soll, steht der Schlüssel in Reichweite dessen, was in
seinen Kontext geraten kann.

**Der Vorschlag: eine Zugangsdatenverwaltung in ClawdDotNet.** Der Agent bekennt nie
einen Wert zu sehen, sondern schreibt einen Platzhalter; ClawdDotNet setzt ihn im
Werkzeug ein, kurz bevor der Aufruf hinausgeht.

```
Agent:          DirectAPI, Header: { "Authorization": "Bearer {{secret:amazon-sp-api}}" }
ClawdDotNet:    ersetzt beim Aufruf, protokolliert die Benutzung, nie den Wert
Antwort:        wird auf dem Rückweg maskiert, bevor sie in den Kontext geht
```

Das ist der richtige Ansatz, und er löst ein echtes Problem. Er löst aber nicht so viel,
wie er auf den ersten Blick verspricht — und die Lücken dazwischen sind die eigentliche
Arbeit.

### Wo es klemmt

**1. Ein Platzhalter darf nicht überall ersetzt werden.**
Ein stumpfes Suchen-und-Ersetzen über alle Argumente wäre die größte Falle: Dann schreibt
ein Agent `{{secret:amazon-sp-api}}` in einen Dateiinhalt, in ein SQL-Statement, in eine
Nachricht oder in eine URL — und der Wert landet dort, wo ihn jeder lesen kann. Die
Ersetzung gehört an **benannte Stellen je Werkzeug** (etwa `DirectAPI.headers`,
`Database.connection`), nie an beliebige Zeichenketten.

**2. Der Platzhalter schützt den Schlüssel, nicht das Ziel.**
Auch mit (1): Ein Agent, der den Schlüssel im Kopf `Authorization` verwenden darf, kann
die Anfrage an eine beliebige Adresse richten — und schickt das Geheimnis dorthin. Die
Verwaltung muss deshalb **jedes Geheimnis an ein Ziel binden**: „dieser Schlüssel gilt nur
gegen `sellingpartnerapi.amazon.com`". Ohne diese Bindung gibt der Platzhalter ein
falsches Gefühl von Sicherheit. Das Netzprofil je Agent (Abschnitt 5) ist die Hälfte
davon; die andere gehört an den Eintrag selbst.

**3. Die Antwort kann das Geheimnis enthalten.**
Manche Dienste spiegeln Token in Fehlermeldungen zurück, manche Bibliotheken schreiben
die Verbindungszeichenfolge in die Ausnahme (`Password=…`). Dann steht der Wert im
Werkzeugergebnis, im Kontext und im Transkript. **Die Maskierung auf dem Rückweg ist
keine Zugabe, sondern die zweite Hälfte des Mechanismus** — der allgemeine Fall ist #192,
der Anfang steht in #660.

**4. Was gilt als Verwendung durch einen Fremden?**
Ein Agent, der nie den Wert sieht, kann ihn nicht verraten — aber er kann ihn *benutzen*,
und dazu lässt sich ein Agent überreden. Der Platzhalter schützt gegen **Diebstahl der
Zugangsdaten**, nicht gegen **Missbrauch der Befugnis**. Dagegen helfen die Zielbindung,
die Freigaberegeln und die Herkunftsregel (#651) — nicht der Platzhalter.

**5. Die Verwaltung erbt die Schwäche des Hauptschlüssels.**
Eine Zugangsdatenverwaltung ist ein Tresor. Solange **#190** offen ist — der Hauptschlüssel
liegt unter Linux im Klartext —, legt man damit mehr Eier in einen Korb, von dem man
weiß, dass er offen steht. Der Tresor macht den Betrieb ordentlicher, die Sicherheit
verbessert er erst nach #190. Reihenfolge entsprechend.

**6. Nicht verraten, was es gibt.**
Fragt ein Agent nach `{{secret:buchhaltung-bank}}`, das ihm nicht zugeteilt ist, muss das
Werkzeug abweisen — **ohne zu sagen, ob dieses Geheimnis existiert**. Dieselbe Überlegung
wie beim Hinweis auf den anderen Arbeitsbereich (#662).

**7. Zuteilung ist eine Rechteänderung.**
Wer welches Geheimnis benutzen darf, entscheidet ein Mensch, nie ein Agent — auch keine
Abteilungsleitung. Die Zuteilung gehört an die Einheit (siehe Organisation-Konzept,
#683/#692), damit sechs Einkäufer sie einmal bekommen und die Buchhaltung den
Marktplatzschlüssel nicht sieht.

### Was der Tresor dafür zurückgibt

- **Eine Stelle zum Wechseln.** Ein rotierter Schlüssel wird einmal geändert, alle Agenten
  arbeiten weiter.
- **Benutzungsspuren.** Wer hat wann welches Geheimnis gegen welches Ziel verwendet —
  im Audit, ohne den Wert. Ein nie benutzter Eintrag kann weg; ein plötzlich viel
  benutzter ist ein Befund.
- **Ein sauberer Weg für Skripte.** Ein freigegebenes Skript (#657) bekommt sein
  Geheimnis als Umgebungsvariable vom Läufer, deklariert im Manifest — nie im Quelltext,
  nie im Aufrufprotokoll (#696).

### Urteil

Bauen, ja — aber mit Zielbindung und Rückweg-Maskierung von Anfang an, und nach #190.
Ein Platzhalter allein verschiebt das Geheimnis nur von der Agentenkonfiguration in die
Werkzeugkonfiguration.

## 12 — Reihenfolge und Items

| Item | Vorhaben | Abschnitt |
|---|---|---|
| #651 | Herkunftsregel, mit Ausnahmen für feste Ziele, Muster-Freigabe und Herkunft in der Vorschau | 4.1 |
| #659 | Belastung wandert mit (Gedächtnis-Vergiftung) | 4.3 |
| #652 | Befunde und Quarantäne mit zwei Stufen, Ausnahmen | 6 |
| #653 | Regelbasierte Detektoren und Köderwerte | 8 |
| #654 | Sandbox-Runner | 3 |
| #655 | Netzprofil je Agent | 5 |
| #656 | Sicherheitsbereich in Avalonia und Weboberfläche | 10 |
| #657 | Skriptprüfung | 7 |
| #658 | Security-Agent (Profil von #204) | 9 |

1. **#651 mit #659, #652, #653** — größter Nutzen je Aufwand, braucht nur das Vorhandene und die
   Messenger-Freigabe (#644).
2. **#654** — harte Vorbedingung für Skripte, Shell (#196) und MCP-stdio-Server (#197);
   steht deshalb vor beiden.
3. **#655** und **#656**.
4. **#657** — mit #198, weil Skripte mit den Skills kommen.
5. **#658** — zuletzt, auf #204 aufbauend. Bis dahin prüft bei Skripten der Mensch
   allein, mit der deterministischen Vorprüfung.