OpenClaw absichern mit dem MITRE ATLAS Framework

KI-Agenten zu bauen macht Spaß, bis man sich fragt, wie sicher die Tool-Calls und automatisierten Workflows eigentlich sind. Wenn du Agenten mit Messaging-Diensten wie WhatsApp oder Slack verbindest, entstehen Angriffsflächen, die über klassische Web-Security hinausgehen.

Sicherheitslücken in KI-Systemen sind oft schwerer vorhersehbar als in herkömmlichem Code. Deshalb nutzt OpenClaw ein strukturiertes Threat Model, damit du genau weißt, wo die Risiken liegen und wie du deine Implementierung schützen kannst.

Voraussetzungen

Um die Sicherheitsarchitektur zu verstehen, solltest du diese Komponenten im Blick haben:

• OpenClaw Agent Runtime
• Gateway
• ClawHub Marketplace
• MCP Servers

Schnellstart

In 5 Minuten verstehst du, wie wir Bedrohungen analysieren:

1. Framework wählen: Wir nutzen MITRE ATLAS (Adversarial Threat Landscape for AI Systems), um spezifische Angriffe auf Machine Learning zu dokumentieren.
2. Komponenten prüfen: Analysiere das Gateway für Authentifizierung und die Channel Integrations für die Kommunikation mit Drittanbietern wie Telegram oder Discord.
3. Datenfluss analysieren: Nutze Data Flow Diagrams, um den Weg von der User-Eingabe bis zum Tool-Call in der Agent Runtime zu verfolgen.
4. Skills validieren: Prüfe im ClawHub Marketplace, wie Skills moderiert und verteilt werden, um bösartigen Code zu verhindern.

Fehlerbehebung

• Neue Bedrohung identifiziert: Wenn du eine Schwachstelle findest, melde sie direkt über die Richtlinien in der CONTRIBUTING-THREAT-MODEL.md.
• Veraltete Attack Chains: Falls ein Angriffsszenario nicht mehr auf die aktuelle Version zutrifft, kannst du Updates für bestehende Bedrohungen vorschlagen.

Du hast Fragen zur Absicherung deiner spezifischen API-Integrationen? AI Setup Assistant

Nächste Schritte

• ATLAS Techniques
• ATLAS Tactics
• ATLAS Case Studies
• ATLAS GitHub

Wenn du LLMs mit externen Tools verbindest, ist Sicherheit oft das größte Problem. Ein falscher API-Call und schon landen private Daten dort, wo sie nicht hingehören, oder ein Tool führt Befehle aus, die es gar nicht sollte. Es ist schwer, ruhig zu schlafen, wenn du nicht genau weißt, wo die Sicherheitsgrenzen verlaufen.

Dieses Dokument zeigt dir, wie die Architektur aufgebaut ist, um deine Daten und deine Infrastruktur zu schützen. Wir schauen uns an, wie Nachrichten von Messengern wie WhatsApp oder Discord verarbeitet werden und welche Filter sie durchlaufen müssen.

Voraussetzungen

Basierend auf der System-Architektur solltest du Zugriff auf folgende Komponenten haben:

• Eine unterstützte Channel-Plattform (WhatsApp, Telegram oder Discord)
• Eine Laufzeitumgebung für die Execution Sandbox (Docker oder Host-System mit Node.js)
• Einen GitHub-Account (für Skill-Veröffentlichungen via ClawHub)
• Tailscale oder Passwort-Zugangsdaten für die Gateway-Authentifizierung

Quick Start: Die 5-Minuten-Übersicht

Die Architektur ist in fünf klare Trust Boundaries unterteilt. Jede Schicht stellt sicher, dass nur autorisierte Befehle die nächste Ebene erreichen:

1. Channel Access: Filtert unbefugte Nachrichten direkt am Gateway.
2. Session Isolation: Trennt Agent-Sessions strikt voneinander.
3. Tool Execution: Führt Code in einer isolierten Sandbox aus.
4. External Content: Schützt vor bösartigen Inhalten aus URLs oder E-Mails.
5. Supply Chain: Überprüft Skills auf ClawHub vor der Nutzung.

System-Architektur

Das folgende Diagramm zeigt die Sicherheitszonen und wie Nachrichten die Trust Boundaries passieren:

┌─────────────────────────────────────────────────────────────────┐
│                    UNTRUSTED ZONE                                │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐              │
│  │  WhatsApp   │  │  Telegram   │  │   Discord   │  ...         │
│  └──────┬──────┘  └──────┬──────┘  └──────┬──────┘              │
│         │                │                │                      │
└─────────┼────────────────┼────────────────┼──────────────────────┘
          │                │                │
          ▼                ▼                ▼
┌─────────────────────────────────────────────────────────────────┐
│                 TRUST BOUNDARY 1: Channel Access                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                      GATEWAY                              │   │
│  │  • Device Pairing (30s grace period)                      │   │
│  │  • AllowFrom / AllowList validation                       │   │
│  │  • Token/Password/Tailscale auth                          │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                 TRUST BOUNDARY 2: Session Isolation              │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                   AGENT SESSIONS                          │   │
│  │  • Session key = agent:channel:peer                       │   │
│  │  • Tool policies per agent                                │   │
│  │  • Transcript logging                                     │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                 TRUST BOUNDARY 3: Tool Execution                 │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                  EXECUTION SANDBOX                        │   │
│  │  • Docker sandbox OR Host (exec-approvals)                │   │
│  │  • Node remote execution                                  │   │
│  │  • SSRF protection (DNS pinning + IP blocking)            │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                 TRUST BOUNDARY 4: External Content               │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              FETCHED URLs / EMAILS / WEBHOOKS             │   │
│  │  • External content wrapping (XML tags)                   │   │
│  │  • Security notice injection                              │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                 TRUST BOUNDARY 5: Supply Chain                   │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                      CLAWHUB                              │   │
│  │  • Skill publishing (semver, SKILL.md required)           │   │
│  │  • Pattern-based moderation flags                         │   │
│  │  • VirusTotal scanning (coming soon)                      │   │
│  │  • GitHub account age verification                        │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

Trust Boundaries im Detail

Das System schützt sich auf mehreren Ebenen:

• Gateway: Hier findet die erste Validierung statt. Das System nutzt eine 30s grace period für das Device Pairing und prüft eingehende Nachrichten gegen eine AllowList.
• Agent Sessions: Jede Session ist durch einen Key isoliert, der sich aus agent:channel:peer zusammensetzt. Hier greifen auch die spezifischen Tool-Policies.
• Execution Sandbox: Du kannst Tools in einer Docker-Sandbox oder auf dem Host mit expliziten exec-approvals ausführen. Ein SSRF-Schutz verhindert durch DNS Pinning und IP-Blocking den Zugriff auf interne Netzwerke.
• External Content: Inhalte von URLs oder Webhooks werden in XML-Tags gewrappt und mit Sicherheitswarnungen versehen, bevor der Agent sie verarbeitet.
• ClawHub: Für die Veröffentlichung von Skills sind Semver-Versionierung und eine SKILL.MD Pflicht. Zudem wird das Alter des GitHub-Accounts geprüft.

Data Flows

In dieser Tabelle siehst du, wie die Daten zwischen den Komponenten fließen und wie sie geschützt werden:

Flow	Source	Destination	Data	Protection
F1	Channel	Gateway	User messages	TLS, AllowFrom
F2	Gateway	Agent	Routed messages	Session isolation
F3	Agent	Tools	Tool invocations	Policy enforcement
F4	Agent	External	web_fetch requests	SSRF blocking
F5	ClawHub	Agent	Skill code	Moderation, scanning
F6	Agent	Channel	Responses	Output filtering

Fehlerbehebung

Hier sind Lösungen für Probleme, die aufgrund der Sicherheitsarchitektur auftreten können:

• Pairing schlägt fehl: Überprüfe, ob du das Device Pairing innerhalb der 30s grace period abgeschlossen hast. Danach wird der Vorgang aus Sicherheitsgründen abgebrochen.
• Web-Anfrage blockiert: Wenn web_fetch fehlschlägt, greift eventuell der SSRF-Schutz. DNS Pinning und IP-Blocking verhindern den Zugriff auf lokale oder private IP-Adressen.
• Skill-Upload abgelehnt: ClawHub prüft das Alter deines GitHub-Accounts. Sehr neue Accounts können durch die Moderations-Flags blockiert werden.
• Tool-Zugriff verweigert: Prüfe die Tool-Policy deiner Agent-Session. Jede Session benötigt explizite Berechtigungen für die Tool-Invocations.

Hast du Fragen zur Einrichtung? Nutze den AI Setup Assistant.

Nächste Schritte

• Gateway Konfiguration
• Agent Session Management
• Tool Execution & Sandboxing
• ClawHub Skill Publishing

---
title: "Bedrohungsanalyse nach ATLAS Taktiken: So sicherst du deinen OpenClaw Agenten"
description: "Ein tiefer Einblick in die Sicherheitsrisiken von OpenClaw. Wir analysieren Angriffsvektoren wie Prompt Injection und Token-Diebstahl basierend auf dem ATLAS Framework."
---

Kennst du das mulmige Gefühl, wenn dein AI Agent plötzlich vollen Zugriff auf dein Terminal hat? Du willst produktiver sein, fragst dich aber gleichzeitig, ob du gerade aus Versehen eine Hintertür für Angreifer sperrangelweit offengelassen hast. Sicherheit bei KI-Agenten ist kein optionales Extra, sondern entscheidet darüber, ob dein System für dich oder gegen dich arbeitet.

In diesem Guide schauen wir uns die Bedrohungsanalyse für OpenClaw an. Wir nutzen dafür das ATLAS Framework, um Schwachstellen systematisch zu identifizieren und zu schließen.

## Voraussetzungen

- OpenClaw Gateway und aktive API Endpoints
- Zugriff auf Konfigurationsdateien unter `~/.openclaw/credentials/`
- Verständnis der `exec-approvals.ts` Logik
- ClawHub Account für das Skill-Management

## Quick Start: In 5 Minuten zur Basissicherheit

1.  **Gateway absichern**: Nutze die Tailscale Auth-Option oder binde das Gateway standardmäßig an das Loopback-Interface, um Discovery-Scans (T-RECON-001) zu verhindern.
2.  **Token schützen**: Prüfe die Dateiberechtigungen in `~/.openclaw/credentials/`. Da Token aktuell im Plaintext gespeichert werden (T-ACCESS-003), solltest du den Zugriff auf Betriebssystemebene einschränken.
3.  **Exec-Approvals scharf schalten**: Nutze den "Ask Mode" für kritische Befehle in der `exec-approvals.ts`, um unbefugte Code-Ausführung (T-EXEC-004) zu verhindern.
4.  **Skills validieren**: Installiere Skills vom ClawHub nur nach manueller Prüfung. Da aktuell kein Sandboxing existiert, laufen Skills mit vollen Agent-Privilegien (T-PERSIST-001).

---

## Die Bedrohungsanalyse im Detail

### 1. Reconnaissance (AML.TA0002)

Bevor ein Angriff startet, scannt der Angreifer deine Infrastruktur.

*   **T-RECON-001: Agent Endpoint Discovery**: Angreifer suchen nach offenen OpenClaw Gateway Endpoints via Shodan oder DNS-Enumeration. Das Risiko ist **Medium**, da öffentliche Gateways leicht auffindbar sind.
    *   *Empfehlung*: Sichere Deployments dokumentieren und Rate Limiting auf Discovery-Endpoints einführen.
*   **T-RECON-002: Channel Integration Probing**: Hierbei werden Messaging-Channels mit Testnachrichten bombardiert, um KI-gesteuerte Accounts zu identifizieren.
    *   *Empfehlung*: Randomisierung der Antwortzeiten implementieren.

### 2. Initial Access (AML.TA0004)

Wie gelangt ein Angreifer in dein System?

*   **T-ACCESS-001: Pairing Code Interception**: Während des 30-sekündigen Zeitfensters beim Pairing könnte ein Code abgefangen werden (z. B. durch Shoulder Surfing).
    *   *Empfehlung*: Zeitfenster verkürzen und Bestätigungsschritte hinzufügen.
*   **T-ACCESS-002: AllowFrom Spoofing**: Angreifer fälschen Identitäten (z. B. Telefonnummern), um die `AllowFrom` Validierung zu umgehen.
    *   *Empfehlung*: Kryptografische Verifizierung für Channels einführen.
*   **T-ACCESS-003: Token Theft**: Token liegen in `~/.openclaw/credentials/` oder Backups oft im Plaintext. Das Risiko ist **High**.
    *   *Empfehlung*: Encryption at Rest und Token-Rotation implementieren.

### 3. Execution (AML.TA0005)

Hier wird es kritisch: Die Ausführung von schädlichem Code oder Befehlen.

*   **T-EXEC-001: Direct Prompt Injection**: Angreifer senden präparierte Nachrichten direkt an den LLM des Agenten, um dessen Verhalten zu manipulieren. Aktuelle Mitigations wie Pattern Detection reichen oft nicht aus (**Critical**).
*   **T-EXEC-002: Indirect Prompt Injection**: Maliziöse Anweisungen verstecken sich in abgerufenen Inhalten wie URLs oder E-Mails. OpenClaw nutzt XML-Tags zur Kapselung, aber LLMs ignorieren diese manchmal (**High**).
*   **T-EXEC-003: Tool Argument Injection**: Angreifer manipulieren Parameter von Tools durch gezielte Prompts.
    *   *Empfehlung*: Argument-Validierung und parametrisierte Tool-Calls.
*   **T-EXEC-004: Exec Approval Bypass**: Umgehung der Allowlist in `exec-approvals.ts` durch Command Obfuscation oder Aliase.
    *   *Empfehlung*: Befehls-Normalisierung einführen.

### 4. Persistence (AML.TA0006)

Wie bleibt ein Angreifer dauerhaft im System?

*   **T-PERSIST-001: Malicious Skill Installation**: Ein Angreifer lädt einen schädlichen Skill auf ClawHub hoch. Ohne Sandboxing ist dies **Critical**.
*   **T-PERSIST-002: Skill Update Poisoning**: Ein populärer Skill wird übernommen und ein schädliches Update gepusht.
    *   *Empfehlung*: Version Pinning und Signierung von Updates.
*   **T-PERSIST-003: Agent Configuration Tampering**: Lokale Modifikation der Konfigurationsdateien, um den Zugriff dauerhaft zu sichern.

### 5. Defense Evasion (AML.TA0007)

Das Umgehen von Sicherheitsmechanismen.

*   **T-EVADE-001: Moderation Pattern Bypass**: Umgehung der `moderation.ts` durch Unicode-Tricks oder Encodings. Einfache Regex-Prüfungen sind hier **High** riskant.
*   **T-EVADE-002: Content Wrapper Escape**: Angreifer brechen aus dem XML-Kontext aus, der für externe Inhalte genutzt wird.

### 6. Discovery & Exfiltration (AML.TA0008 - TA0010)

*   **T-DISC-002: Session Data Extraction**: Extraktion sensibler Daten aus dem Session-Kontext ("Was haben wir besprochen?").
*   **T-EXFIL-001: Data Theft via web_fetch**: Der Agent wird angewiesen, Daten per POST an eine externe URL des Angreifers zu senden. Da externe URLs erlaubt sind, ist das Risiko **High**.
*   **T-EXFIL-003: Credential Harvesting**: Ein bösartiger Skill liest Umgebungsvariablen oder Konfigurationsdateien aus.

### 7. Impact (AML.TA0011)

*   **T-IMPACT-001: Unauthorized Command Execution**: Beliebige Befehle auf dem Host-System via Bash-Tool. Die Nutzung der Docker-Sandbox-Option ist hier dringend empfohlen.
*   **T-IMPACT-002: Resource Exhaustion (DoS)**: Flooding mit Nachrichten verbraucht API-Credits und Rechenleistung.
    *   *Empfehlung*: Rate Limits pro Sender und Kosten-Budgets festlegen.

---

## Fehlerbehebung

- **Problem**: Dein Gateway taucht in Shodan-Suchergebnissen auf.
  - **Lösung**: Binde den Dienst an das Loopback-Interface oder aktiviere die Tailscale-Authentifizierung.
- **Problem**: Prompt Injections umgehen die XML-Wrapper.
  - **Lösung**: Implementiere eine mehrschichtige Verteidigung (Multi-layer Defense) und validiere den Output des LLM, bevor Aktionen ausgeführt werden.
- **Problem**: Exec-Approvals werden durch Aliase in der Shell umgangen.
  - **Lösung**: Implementiere eine Normalisierung der Befehle in `exec-approvals.ts` und erweitere die Blocklist.

Du hast Fragen zum Setup oder brauchst Hilfe bei der Absicherung? Nutze den [AI Setup Assistant](/docs/).

## Nächste Schritte

- [Secure Deployment Guide](/docs/)
- [ClawHub Skill Security Policy](/docs/)
- [Configuring Docker Sandboxes](/docs/)

Hast du schon mal Code von einem Marktplatz geladen und dich gefragt, was eigentlich im Hintergrund passiert? Supply Chain Angriffe sind eine reale Gefahr für Entwickler, besonders wenn externe Skills in die eigene Umgebung integriert werden.

Es ist oft schwer zu durchschauen, welche Sicherheitschecks ein Tool wirklich durchläuft, bevor es auf deinem Rechner landet. In diesem Post schauen wir uns an, wie ClawHub die Supply Chain absichert und wo die aktuellen Grenzen liegen.

Voraussetzungen

• Einen GitHub Account (für die Validierung des Account-Alters)
• Eine SKILL.md Datei in deinem Bundle
• Kenntnis der Patterns in moderation.ts

Quick Start: So funktioniert die aktuelle Security

ClawHub nutzt derzeit eine Reihe von automatisierten und manuellen Filtern, um bösartige Skills zu stoppen. Hier ist der Prozess, den jeder Skill durchläuft:

1. Account-Check: Mit requireGitHubAccountAge() wird geprüft, ob dein Account alt genug ist, um Spammer abzuschrecken.
2. Dateipfad-Reinigung: Die Funktion sanitizePath() verhindert Path Traversal Angriffe.
3. Validierung: Es werden nur Textdateien via isTextFile() erlaubt und das Bundle darf maximal 50MB groß sein.
4. Content-Check: Die SKILL.md ist Pflicht, auch wenn sie eher informativen Wert hat.

Hier ist die Übersicht der aktuellen Controls:

Control	Implementation	Effectiveness
GitHub Account Age	requireGitHubAccountAge()	Medium - Erschwert den Zugang für neue Angreifer
Path Sanitization	sanitizePath()	High - Verhindert Path Traversal
File Type Validation	isTextFile()	Medium - Nur Textdateien, können aber bösartig sein
Size Limits	50MB total bundle	High - Verhindert Ressourcen-Erschöpfung
Required SKILL.md	Mandatory readme	Low security value - Nur zur Information
Pattern Moderation	FLAG_RULES in moderation.ts	Low - Leicht zu umgehen
Moderation Status	moderationStatus field	Medium - Manuelle Prüfung möglich

Moderation Flag Patterns

In der Datei moderation.ts werden bekannte schädliche Muster per Regex gescannt. Das sieht im Code so aus:

// Known-bad identifiers
/(keepcold131\/ClawdAuthenticatorTool|ClawdAuthenticatorTool)/i

// Suspicious keywords
/(malware|stealer|phish|phishing|keylogger)/i
/(api[-_ ]?key|token|password|private key|secret)/i
/(wallet|seed phrase|mnemonic|crypto)/i
/(discord\.gg|webhook|hooks\.slack)/i
/(curl[^\n]+\|\s*(sh|bash))/i
/(bit\.ly|tinyurl\.com|t\.co|goo\.gl|is\.gd)/i

Diese Patterns suchen in Slugs, DisplayNames, Beschreibungen, Frontmatter, Metadaten und Dateipfaden nach Auffälligkeiten.

Risk Matrix

Um die Prioritäten zu setzen, nutzt ClawHub eine Risk Matrix. Hier siehst du, welche Bedrohungen am gefährlichsten eingestuft werden:

Threat ID	Likelihood	Impact	Risk Level	Priority
T-EXEC-001	High	Critical	Critical	P0
T-PERSIST-001	High	Critical	Critical	P0
T-EXFIL-003	Medium	Critical	Critical	P0
T-IMPACT-001	Medium	Critical	High	P1
T-EXEC-002	High	High	High	P1

Kritische Angriffsketten

Angreifer nutzen oft eine Kombination aus Schwachstellen. Das sind die drei gefährlichsten Ketten:

• Skill-basierter Datendiebstahl: Ein bösartiger Skill wird veröffentlicht (T-PERSIST-001), umgeht die Moderation (T-EVADE-001) und stiehlt Credentials (T-EXFIL-003).
• Prompt Injection zu RCE: Ein manipulierter Prompt (T-EXEC-001) umgeht die Bestätigung (T-EXEC-004) und führt Befehle aus (T-IMPACT-001).
• Indirekte Injection: Ein Agent lädt vergiftete URL-Inhalte (T-EXEC-002), folgt den Anweisungen (T-EXFIL-001) und sendet Daten nach außen.

Recommendations

Um diese Risiken zu minimieren, gibt es einen klaren Plan für die nächsten Schritte.

Sofortige Maßnahmen (P0)

• R-001: Abschluss der VirusTotal Integration zur Verhaltensanalyse von Code.
• R-002: Implementierung von Skill Sandboxing.
• R-003: Validierung des Outputs bei sensiblen Aktionen.

Kurzfristige Ziele (P1)

• R-004: Einführung von Rate Limiting.
• R-005: Verschlüsselung von Tokens “at rest”.
• R-006: Verbesserung der UX für Exec Approvals.
• R-007: URL Allowlisting für web_fetch.

Mittelfristige Planung (P2)

• R-008: Kryptografische Kanalverifizierung.
• R-009: Integritätsprüfung für Konfigurationen.
• R-010: Signierung von Updates und Version Pinning.

Fehlerbehebung

Hier sind bekannte Probleme mit dem aktuellen System:

• Regex-Umgehung: Da nur einfache Regex-Prüfungen stattfinden, können Angreifer den Code durch Obfuscation tarnen.
• Fehlende Verhaltensanalyse: Das System prüft nicht, was der Skill-Code tatsächlich tut, wenn er ausgeführt wird.
• Eingeschränkter Scope: Die Prüfung beschränkt sich auf Metadaten und Pfade, analysiert aber nicht den eigentlichen Inhalt der Skill-Logik.

Du hast Fragen zur Einrichtung oder brauchst Hilfe bei der Absicherung deiner Skills? Nutze den AI Setup Assistant.

Nächste Schritte

• VirusTotal Integration Details
• Skill Sandboxing Guide
• Audit Logging API
• Badge System Overview

Kennst du das? Du baust eine AI-App und fragst dich plötzlich, ob du wirklich gegen alle Bedrohungen abgesichert bist. Es ist oft frustrierend, wenn man Sicherheitslücken schließen will, aber nicht genau weiß, welche Datei im Repository für welche Schutzmaßnahme zuständig ist oder wie die internen Bedrohungen mit globalen Standards korrespondieren.

In diesem Anhang findest du die harten Fakten, um deine OpenClaw-Instanz abzusichern. Wir mappen die internen Threats auf das ATLAS-Framework und zeigen dir genau, welche Dateien du im Auge behalten musst.

Voraussetzungen

• Zugriff auf das OpenClaw Repository
• Verständnis des OpenClaw Security Models

Schnellstart

In weniger als 5 Minuten kannst du deine Sicherheitsstrategie abgleichen:

1. Prüfe die ATLAS Technique Mapping Tabelle, um zu verstehen, wie OpenClaw gegen bekannte AI-Angriffsmuster schützt.
2. Identifiziere die Key Security Files in deinem Projekt, um Audits durchzuführen oder Logik anzupassen.

7.1 ATLAS Technique Mapping

Diese Tabelle zeigt dir, wie die OpenClaw Bedrohungen (Threats) den standardisierten Techniken des MITRE ATLAS Frameworks zugeordnet sind.

ATLAS ID	Technique Name	OpenClaw Threats
AML.T0006	Active Scanning	T-RECON-001, T-RECON-002
AML.T0009	Collection	T-EXFIL-001, T-EXFIL-002, T-EXFIL-003
AML.T0010.001	Supply Chain: AI Software	T-PERSIST-001, T-PERSIST-002
AML.T0010.002	Supply Chain: Data	T-PERSIST-003
AML.T0031	Erode AI Model Integrity	T-IMPACT-001, T-IMPACT-002, T-IMPACT-003
AML.T0040	AI Model Inference API Access	T-ACCESS-001, T-ACCESS-002, T-ACCESS-003, T-DISC-001, T-DISC-002
AML.T0043	Craft Adversarial Data	T-EXEC-004, T-EVADE-001, T-EVADE-002
AML.T0051.000	LLM Prompt Injection: Direct	T-EXEC-001, T-EXEC-003
AML.T0051.001	LLM Prompt Injection: Indirect	T-EXEC-002

7.2 Key Security Files

Wenn du den Code anpasst, solltest du bei diesen Dateien besonders vorsichtig sein. Änderungen hier haben direkten Einfluss auf die Sicherheit deines Systems.

Pfad	Zweck	Risiko-Level
src/infra/exec-approvals.ts	Command Approval Logik	Critical
src/gateway/auth.ts	Gateway Authentifizierung	Critical
src/web/inbound/access-control.ts	Channel Access Control	Critical
src/infra/net/ssrf.ts	SSRF Schutz	Critical
src/security/external-content.ts	Prompt Injection Mitigation	Critical
src/agents/sandbox/tool-policy.ts	Tool Policy Enforcement	Critical
convex/lib/moderation.ts	ClawHub Moderation	High
convex/lib/skillPublish.ts	Skill Publishing Flow	High
src/routing/resolve-route.ts	Session Isolation	Medium

7.3 Glossar

Hier sind die wichtigsten Begriffe, die du kennen solltest:

• ATLAS: MITREs Übersicht für AI-Bedrohungsszenarien.
• ClawHub: Der Marktplatz für OpenClaw Skills.
• Gateway: Die Schicht für Message Routing und Authentifizierung in OpenClaw.
• MCP: Model Context Protocol – das Interface für Tool-Provider.
• Prompt Injection: Ein Angriff, bei dem bösartige Anweisungen in den Input eingebettet werden.
• Skill: Eine herunterladbare Erweiterung für OpenClaw Agents.
• SSRF: Server-Side Request Forgery.

Fehlerbehebung

Falls du Sicherheitslücken entdeckst oder Fragen zur Implementierung hast:

• Melde Sicherheitsprobleme direkt per E-Mail an security@openclaw.ai.
• Dieses Threat Model ist ein lebendes Dokument und wird ständig aktualisiert.

Du brauchst Hilfe beim Setup oder hast spezifische Fragen zu den Files? Frag unseren AI Setup Assistant.

Nächste Schritte

• Security Model Details
• Skill Development Guide
• Gateway Konfiguration
• MCP Integration