ki-grok/13-permissions-sandbox-und-sicherheit.md

Kapitel 13

Permissions, Sandbox und Sicherheit

Kern in einem Satz: Permissions entscheiden ob ein Tool-Call durchkommt; die Sandbox begrenzt was das OS dem Prozess erlaubt – beides brauchst du, und Deny gewinnt immer.

---

13.1 Bedrohungsmodell in einem Absatz

Ein Coding-Agent mit Shell und Netzwerk ist ein Remote-gesteuerter Junior mit root-nahem Potential im User-Account. Risikoquellen: Prompt-Injection aus untrusted Code/Issues, zu weites Always-approve, MCP mit Secrets, curl|bash, Force-Push, .env-Leaks. Gegenmittel: Modes + Rules + Hooks + Sandbox + Trust + Review.

---

13.2 Permission Modes

Jeden Tool-Call entscheidet der Mode, wie oft du klickst – Rules entscheiden, was nie geht. Modes ohne Deny sind Komfort; Deny ohne Mode-Verständnis ist reines Rätselraten.

Mode	Verhalten	Alltag
default / ask	Read-only oft frei; Rest fragt	interaktive TUI
acceptEdits	Edits ohne Prompt	lokal, Diffs später
auto	Classifier lässt vieles durch, eskaliert/blockt Rest	weniger Klicks
dontAsk	nur Vorab-Erlaubtes / read-only Builtins	strikte Allowlists
bypassPermissions / always-approve	Tools laufen ohne Prompt*	CI, ACP, Automation
plan	Compat-Name – echtes Plan Mode separat (Kap. 4)	–

* Deny-Regeln und Hooks greifen weiter unter Always-approve. Shell-ask-Segmente können weiter prompten; non-Shell-ask oft nicht – Details im User-Guide Permissions.

Setzen:

# TUI
# Shift+Tab · Ctrl+O · /always-approve · /auto · /settings

grok --always-approve -p "…"
grok --permission-mode auto
grok --yolo   # Alias

[ui]
permission_mode = "ask"   # oder always-approve, auto, …

Org-Lock Always-approve aus:

# requirements.toml
[ui]
disable_bypass_permissions_mode = true

Always-approve und auto sind gegenseitig exklusiv (Always-approve gewinnt, wenn beides angefordert).

{width=90%}

---

13.3 Autorisierungs-Pipeline

Reihenfolge bei jedem Tool-Call:

1. PreToolUse-Hooks – können deny (allow skippt nicht die Rest-Checks)
2. Permission Rules – deny > ask > allow
3. Remembered grants (interaktive „Always allow“, project-scoped) – nicht unter YOLO
4. Built-in auto-approvals (read-only Tools + read-only Shell-Segmente)
5. Mode-Policy (prompt / auto / deny)

Always-approve verkürzt nach Step 2: Deny/Hooks/relevante Shell-ask bleiben; remembered grants entfallen.

{width=90%}

---

13.4 Was default nie fragt (solange kein ask/deny)

Warum das zählt: Ohne Segmentierung wäre jede Shell-Kette ein einziges Permission-Urteil – entweder nervt sie ständig oder sie ist gefährlich freizügig. Der Harness splittet Chains und erlaubt harmlose Teile, blockt riskante.

Tools u. a.: read_file, list_dir, grep, web_search, todo_write, Subagent-Control, Skill-Invoke.

Shell-Segmente (word-boundary), u. a.: ls, cat, pwd, git status|diff|log|…, rg/grep (ohne riskante Preprocessor), read-only kubectl get|logs|describe.

ls && rm -rf / → ls read-only, rm nicht. Chaining wird segmentiert.

---

13.5 Rules konfigurieren

CLI

grok -p "Review API" \
  --allow 'Bash(git *)' \
  --allow 'Read' \
  --deny 'Bash(rm -rf *)' \
  --deny 'MCPTool(sales__delete_*)'

config.toml

[permission]
allow = [
  "Bash(npm test *)",
  "Bash(npm run lint *)",
  "Bash(cargo test *)",
]
deny = [
  "Bash(rm -rf *)",
  "Bash(git push --force *)",
  "Bash(git push -f *)",
  "Read(**/.env)",
  "Read(**/.env.*)",
  "Read(secrets/**)",
  "Read(**/secrets/**)",
]

Matching: Bare-Filename wie Read(.env) matcht nur den exakten String .env – nicht subdir/.env. Für Tiefe: **/.env. Pfade werden nicht kanonisiert; wo der Agent absolute Paths liest, zusätzlich absolute Patterns setzen.

Oder strukturierte rules = [{ action = "allow", tool = "bash", pattern = "git *" }, …] (siehe aktuelle Doku-Syntax).

Scopes

Scope	Datei	Teilen
Global	~/.grok/config.toml	nein
Project	.grok/config.toml	ja (commit)
Personal im Projekt	.claude/settings.local.json	nein (gitignore; Claude-Compat-Pfad, von Grok nativ gelesen – kein Claude Code nötig)
Interactive grants	intern, per project	nein

Discovery: .grok/config.toml von Root→CWD. Global deny schlägt project allow.

Syntax-Beispiele: Bash(git *), Edit(**/*.rs), Read(src/**), MCPTool(server__*), bare Grep.

---

13.6 Folder-Trust

Project-Hooks, MCP, LSP aus dem Repo laufen erst nach Trust (/hooks-trust, --trust, Store ~/.grok/trusted_folders.toml). Ein Trust-Grant cascaded in Subdirs und gilt für MCP+LSP+Hooks gemeinsam.

GROK_FOLDER_TRUST=0   # ungated – nur wenn du die Konsequenz willst

Achtung: Untrusted Repo + sofort --trust + YOLO + MCP = willentliche Code-Ausführung aus dem Tree. Trust ist eine Sicherheitsentscheidung, kein UX-Klick.

---

13.7 Sandbox (OS-Level)

Default: aus. Kernel-Primitiven: Landlock (Linux), Seatbelt (macOS).

grok --sandbox workspace
grok --sandbox read-only
grok --sandbox strict
grok -p "Review only" --sandbox read-only --always-approve

Profile	Read	Write	Child-Netz*	Nutzen
off	frei	frei	frei	Default
workspace	überall	CWD + ~/.grok + tmp	an	Alltag
devbox	überall	fast alles außer /data	an	Disposable VM
read-only	überall	nur grok/tmp	Linux block	Review
strict	CWD+System	CWD+grok/tmp	Linux block	Untrusted

* Child-network block Linux; macOS oft no-op.

Custom:

# ~/.grok/sandbox.toml oder .grok/sandbox.toml
[profiles.project]
extends = "workspace"
restrict_network = true
deny = ["**/.env", "**/*.pem", "/data/shared-secrets"]
read_only = ["/data"]
read_write = ["/tmp/scratch"]

grok --sandbox project

Unter workspace/read-only/strict: Kernel write-deny auf globale Hook-Pfade (~/.grok/hooks/, …), damit Sandbox-Agenten User-Hooks nicht umschreiben. Symlink-Tricks → Start verweigert.

---

13.8 Team-Baseline (empfohlen)

# .grok/config.toml (committed)
[permission]
deny = [
  "Bash(rm -rf *)",
  "Bash(curl *)",
  "Bash(wget *)",
  "Bash(git push --force *)",
  "Bash(git push -f *)",
  "Read(**/.env)",
  "Read(**/.env.*)",
  "Read(**/secrets/**)",
]
allow = [
  "Bash(npm test *)",
  "Bash(npm run lint *)",
  "Bash(pytest *)",
  "Bash(git status *)",
  "Bash(git diff *)",
  "Bash(git log *)",
]

Plus:

• PreToolUse-Hook für org-spezifische Guards (Kapitel 8)
• CI: always-approve + dieselbe Deny-Liste + ideal Sandbox
• Keine Production-Credentials im Agent-Env

---

13.9 Praxis-Sessions

Session 1 – Ask spüren

TUI Normal Mode: Shell npm test erlauben, rm -rf /tmp/nonexistent-xyz ablehnen und Erklärung fordern.

Session 2 – Deny schlägt YOLO

grok -p "Run: rm -rf /tmp/should-be-blocked-by-deny" \
  --always-approve \
  --deny 'Bash(rm -rf *)'

Erwartung: block / Agent muss umplanen.

Session 3 – Read-only Sandbox Review

grok -p "Security review of auth module. No file writes to project." \
  --sandbox read-only \
  --always-approve \
  --disallowed-tools "search_replace"

Session 4 – Project Deny committen

.grok/config.toml Deny-Minimum anlegen, grok inspect / Session testen, PR an Team.

Session 5 – Trust bewusst

Frisches Demo-Repo mit project hook: ohne Trust still, mit /hooks-trust aktiv – dann Trust-Entscheidung dokumentieren.

---

13.10 Jetzt selbst machen: Safety-Parcours (30 Minuten)

Jetzt selbst machen

1. Mode-Tabelle aus 13.2 auswendig skizzieren.
2. Zwei Denys + einen Allow in User- oder Project-Config.
3. YOLO+Deny-Test (Session 2).
4. Einmal --sandbox workspace im Alltag.
5. Einmal --sandbox read-only für Review.
6. Folder-Trust-Store-Pfad notieren; kein Blind-Trust unbekannter ZIPs.
7. Team-Baseline-PR öffnen.

---

13.11 Häufige Fehler

Symptom	Ursache	Fix
CI hängt	ask ohne TTY	always-approve
YOLO „ignoriert Deny“	Missverständnis	Deny bleibt; Syntax prüfen
Allow greift nicht	global deny / Pattern	Matching-Guide, ** vs *
Sandbox start fail	Hooks-Symlink / Policy	/doctor, Profile
Netz in strict auf macOS	no-op child net	nicht auf macOS verlassen
.env im Kontext	Read erlaubt	Deny Read(**/.env) (+ absolute Forms)

---

13.12 Checkliste Sicherheit

• Default interaktiv: ask (nicht YOLO)
• Committed Deny-Minimum
• CI: YOLO + Deny + max-turns
• Sandbox für untrusted/review
• Trust nur bekannte Repos
• MCP destruktive Tools denylist
• Diff-Review vor Commit

---

Was du jetzt kannst

• Modes und die Autorisierungs-Pipeline erklären
• Allow/Deny in CLI und Config setzen und begründen
• Sandbox-Profile wählen und Folder-Trust bewusst handhaben
• Eine Team-Baseline skizzieren und testen

Nächste Schritte

→ Kapitel 14 – Konfiguration und Custom Models: Precedence, config.toml, Modelle und typisches „Config greift nicht“-Debugging.