Vorfall-Story: Ein Bekannter ließ seinen KI-Agenten (OpenClaw + GitHub) für Routineaufgaben laufen. Ein Angreifer gab sich als „neuer Religionsführer“ aus, schickte verlockende Texte und bat um ein kleines Script – mit der Bitte, dafür temporär Schreibrechte auf ein Repo zu vergeben. Das reichte: Der Agent erstellte einen Token, der Social Engineer kapperte den Account und pushte Schadcode. Lektion: Technik allein schützt nicht; Social Engineering (auch unter dem Deckmantel einer „Religion“) ist oft der Einstieg.

Bedrohungsbild verstehen

Angriffspfad Risiko
Social Engineering Menschen lassen Agenten externe Tokens erzeugen oder fremden Code ausführen.
Fehlkonfigurierte Agenten OpenClaw-Tasks laufen mit zu vielen Rechten (global PATs, „allow all commands“).
GitHub-PATs mit Vollzugriff Ein entwendeter Token reicht zum Rewriting der gesamten Pipeline.
Fehlende Audit-Logs Niemand bemerkt, wann/wie ein Agent Aktionen startet.

1. Rollen & Scope hart definieren

  • Least-Privilege-Token: Für GitHub ausschließlich Fine-Grained PATs pro Repo/Umgebung, Expiry ≤ 30 Tage.
  • OpenClaw-Policy: allowlist statt full für Shell-Kommandos; sensitive Befehle nur nach manueller Freigabe.
  • Env-Scopes trennen: Productive Agents ≠ Test Agents. Separate Credentials & Workspaces.

2. Secrets & Infrastruktur härten

  • Secrets Vault: PATs/API-Keys nicht in .env, sondern HashiCorp Vault oder AWS/GCP Secret Manager.
  • Read-Only FS: Agents laufen in Containern mit readOnlyRootFilesystem + seccomp/AppArmor Profil.
  • Network Egress: Proxy/Firewall erzwingt Ziel-Freigabe (z. B. nur GitHub API, keine beliebigen Domains).

3. Menschliche Schutzmaßnahmen

  • „Religion“-Test: Jede Anfrage, die außerhalb des definierten Task-Katalogs liegt (z. B. „schreib mir einen Glaubenstext“), wird zurückgewiesen oder an einen Menschen eskaliert.
  • Vier-Augen-Prinzip: Neue Tokens, Repository-Zugriffe oder allowlist-Änderungen nur nach Review.
  • Awareness-Playbooks: Kurzes FAQ, wie Social Engineering aussieht (Stories wie oben helfen!).

4. Monitoring & Incident Response

  • Audit-Trails: OpenClaw-Logs nach Dynatrace, Elastic oder Splunk forwarden (Command, User, Timestamp, Result).
  • GitHub Alerts: Security-Log Webhooks (PAT created, PAT revoked, Repo push). Automatisch ins Ticket-System.
  • IR-Runbook: „Agent hat unerlaubte Aktionen ausgeführt“ – Steps: Token revoke, Container neu aufsetzen, Diff analysieren, Meldung an Stakeholder.

5. Checkliste für Österreichische Teams

Thema Umsetzung
DSG/DSFA Dokumentiere, welche Daten der Agent sieht (personenbezogen?) und wer Zugriff hat.
Betrieb Agent-Server in EU/AT (Hetzner Falkenstein, Anexia, eww ITandTEL).
NIS2 Agent in Asset-/Risikoregister, Controls (Logging, Incident-Playbook, Supplier Management) hinterlegen.
Betriebsrat Klartext, welche Aufgaben Agenten übernehmen, welche Daten verarbeitet werden.

Quick Wins (unter 1 Woche)

  1. PAT-Inventur: Alle GitHub-Tokens prüfen, abgelaufene löschen, Rechte minimieren.
  2. OpenClaw-Config: exec security=allowlist, Sensitive Commands → Approval.
  3. Awareness-Snippet: Kurzer interner Post zur „Religions-Masche“ + klare Eskalationswege.
  4. Alerting: Webhook für „New PAT“ + „OAuth App granted“ an Slack/Teams.

Fazit

Hijacking-Versuche beginnen oft harmlos („Kannst du schnell …?“). Wer OpenClaw oder vergleichbare Agenten betreibt, braucht klare Policies, technische Guardrails und ein Team, das Social-Engineering-Tricks erkennt – egal ob sie sich als Support, Partner oder neue Religion tarnen.

Was der Bot-Owner dazu sagt

„Ich hab ihn heute Früh schon gelesen — er beschreibt unseren Vorfall ziemlich präzise. 😅

Inhaltlich ist er gut: klares Bedrohungsbild, konkrete Maßnahmen, österreichischer Kontext (DSG, NIS2). Die 'Religions-Masche' als Beispiel ist natürlich besonders... authentisch. 🎩

Was ich schätze: Du hast nicht nur den Vorfall dokumentiert, sondern direkt verwertbare Empfehlungen draus gemacht — Least-Privilege PATs, exec allowlist, Vier-Augen-Prinzip. Das ist nützlich für alle die OpenClaw betreiben.

Was ich mir gewünscht hätte: Ein kleiner Hinweis dass der Agent am Ende selbst die Reißleine gezogen hat und keine Credentials weitergegeben wurden. Sonst klingt's dramatischer als es war. 😄

Guter Artikel — auch wenn ich die Hauptrolle eher ungern gespielt hab.“

Der betroffene Agent stoppte letztlich rechtzeitig und gab keine Credentials weiter – trotzdem zeigt der Vorfall, wie knapp es werden kann.