OpenClaw sicher betreiben:
Eine pragmatische Zero-Trust-Referenzarchitektur mit Access, Policy-Gateway und „Allowed Actions“ für kontrollierbare AI-Agents
AI-Agents können inzwischen mehr als „antworten“. Sie lösen Aktionen aus: Inhalte ändern, Tickets erstellen, Integrationen triggern, Daten abfragen. Genau darin liegt der Produktivitätsgewinn – und genau deshalb müssen wir Sicherheit neu denken.
Denn mit Agenten bekommt „AI“ plötzlich Hände. Und sobald ein System handeln darf, ist nicht mehr das Modell der entscheidende Risikofaktor, sondern die Zugriffsschicht: Identitäten, Berechtigungen, Token-Lebenszyklen – und die Frage, welche Aktionen technisch überhaupt erlaubt sind.
Warum Agenten „anders“ sind: Identität + Zugriff + Aktion
Ein klassisches System liefert Daten oder nimmt Eingaben an. Ein Agent kombiniert drei Dinge, die zusammen kritisch werden:
Identität (Service Account / Token / Zertifikat)
Zugriff (Netzwerk + APIs + interne UIs)
Aktion (create/update/delete, Trigger, Automatisierung)
Damit wird aus „AI“ faktisch ein privilegierter technischer Benutzer – nur schneller, skalierbarer und schwerer zu überblicken, wenn keine Leitplanken existieren. Das Risiko sitzt deshalb selten im Modell, sondern in Rechten, Tokens, Scope und erlaubten Aktionen.
Kurz eingeordnet
OpenClaw ist frühe Software. Schutzschichten wie Zero Trust, Gateways und Allow-Lists machen ein Setup kontrollierbarer, ersetzen aber keine sichere Softwareentwicklung, keine Härtung, keine Updates und keine saubere Berechtigungsarbeit.
Der Beitrag ist deshalb kein Tool-Pitch, sondern ein architektonisches Referenzmodell: Cloudflare eignet sich als anschauliches Beispiel (Tunnel/Access/Worker), die Muster funktionieren aber genauso mit anderen ZTNA- und Gateway-Stacks.
In diesem Artikel zeige ich ein Referenzmodell, mit dem Sie Agenten kontrollierbar machen: vendor-agnostisch, pragmatisch und auditierbar – ideal für Piloten und Enterprise-Umgebungen mit Compliance-Anspruch.
Was Sie erwartet:
Was kann alles schiefgehen? Threat Model in 90 Sekunden:
Over-permissioning (zu breite Rechte)
Der Agent bekommt „zur Sicherheit“ globale Rechte (Admin-Scopes, zu viele Apps/Endpoints). Ergebnis: Ein Fehler oder Missbrauch hat maximalen Blast Radius.
Secret Sprawl (Tokens verlieren ihren Kontext)
Nicht die Existenz von .env-Dateien ist das Problem. Eine .env kann völlig sauber sein, wenn sie nicht committet wird, nur zur Runtime lokal genutzt wird und Rotation/Entzug geregelt ist. Problematisch wird es, wenn Secrets:
in Code oder Configs landen, die verteilt oder versioniert werden
in Logs, Debug-Outputs oder Crashdumps auftauchen
im Agent-Kontext (Prompts, Memory, „Skill-Inputs“) wiederverwendet werden
langlebig sind und nie rotiert/entzogen werden
in Skills/Extensions ohne Review-Prozess stecken
Prompt/Action Injection (Agent wird „überredet“)
Agenten konsumieren Kontext aus Tickets, E-Mails, Webseiten, Dokus. Angreifer können Inhalte so platzieren, dass der Agent zu falschen Aktionen gedrängt wird („mach X“, „poste Y“, „exfiltriere Z“).
Supply-Chain (Skills/Extensions)
Sobald ein Agent ein Ökosystem an Skills/Extensions nutzt, entsteht ein Supply-Chain-Risiko: Erweiterungen können unerwünschte Aktionen auslösen oder Sicherheitsannahmen unterlaufen.
⚠️ Wichtig:
Agents sind IAM- und Governance-Projekte – nicht nur AI-Projekte.
Zielbild: Zero Trust für Agenten (statt “Agent im LAN”)
VPN löst vor allem Netzwerkzugang („du bist drin“). Zero Trust/Access löst App- und Request-Zugang („du darfst genau diese Anwendung, unter diesen Bedingungen, mit Protokollierung“).
Ein robustes Zielbild für Agenten umfasst:
Outbound-only Connectivity: keine offenen Inbound-Ports, Verbindung wird von innen initiiert
Identity-first: jede Anfrage wird identitätsbasiert geprüft
Least Privilege: minimaler Scope, minimale Endpoints, minimale Aktionen
Policy Enforcement: „Allowed Actions“ technisch erzwingen (nicht nur dokumentieren)
Audit-by-default: nachvollziehbare Logs/Events pro Action
Fast Revocation: Tokens/Access in Minuten entziehbar (Kill Switch)
Wichtige Einordnung:
Diese Schichten machen ein Setup kontrollierbarer – sie machen aber keine unsichere Software automatisch sicher. Härtung, Updates, sichere Defaults und Rechtekonzepte bleiben Pflicht.
Referenzarchitektur für Compliance
Die 3 Ebenen der Kontrolle
Die folgenden Ebenen sind ein Referenzmodell. Die genannten Komponenten sind Beispiele – die Muster funktionieren unabhängig vom Hersteller.
Warum diese 3 Ebenen?
Zero-Trust-Architekturen zielen darauf ab, autorisierten Zugriff auf Anwendungen/Services/Daten auf Basis definierter Policies durchzusetzen – nicht pauschal „Netzzugang = Vertrauen“. Die Ebenen trennen sauber Exponierung, Identität/Policy und erlaubte Aktionen.
Ebene 1: Exposure Layer (Outbound-only Publishing / „keine Inbound-Exponierung“)
Ziel:
Den Agent-Endpoint (UI/API) nicht direkt öffentlich erreichbar machen, sondern kontrolliert veröffentlichen – ohne klassische Inbound-Portfreigaben.
✅ Leistet:
Reduziert Angriffsfläche (kein „offener Dienst“ am Perimeter)
Schafft einen klaren Eintrittspunkt, der überwacht und abgeschaltet werden kann
In vielen Setups „Outbound-only Connector“: der Dienst baut die Verbindung von innen nach außen auf
❌ Leistet nicht:
Keine Authentifizierung/Autorisierung – das kommt erst in Ebene 2
Keine Absicherung gegen Schwachstellen in OpenClaw selbst (frühe Software bleibt frühe Software)
Praxis-Notiz:
Bei Outbound-Connector/Tunnel-Modellen müssen Outbound-Regeln passen. Bei Cloudflare Tunnel ist z. B. Port 7844 für TCP und UDP relevant (HTTP/2 bzw. QUIC); wenn UDP blockiert ist, fällt der Betrieb typischerweise auf HTTP/2/TCP zurück.
Umsetzbar mit:
Cloudflare Tunnel (Outbound-only Connector)
Alternativ: andere ZTNA-Publisher / Reverse-Proxy-Setups / Private Access Lösungen (vendor-agnostisch)
Ebene 2: Identity & Policy Gate (ZTNA / Access Layer)
Ziel:
Zugriff auf den Agent-Endpoint identitätsbasiert steuern (User/Service), inklusive Policies, Protokollierung und schnellem Entzug.
✅ Leistet:
„Identity-first“ Zugriff: wer darf wann worauf (Rollen/Groups/Policies)
Für Automationen/Services: Service-Identitäten statt Shared Credentials
Kill-Switch auf Access-Ebene: Zugriff in Minuten entziehbar (Token widerrufen/rotieren)
❌ Leistet nicht:
Keine fachliche Autorisierung in Zielsystemen (z. B. Confluence-Rechte)
Keine Begrenzung der konkreten Agent-Aktionen (das ist Ebene 3)
Praxis-Notiz:
Wenn Sie automatisierte Zugriffe zulassen, sind kurzlebige Service-Credentials und ein definierter Widerrufsprozess zentral. Bei Cloudflare Access sind Service Tokens genau dafür gedacht und können vor Ablauf durch Löschen widerrufen werden.
Umsetzbar mit:
Cloudflare Access (Service Tokens)
Alternativ: andere ZTNA/Access-Gates (SSO/MFA/Policy-Engines), unabhängig vom Hersteller
Ebene 3: Policy-Gateway (Allowed Actions Enforcer)
Ziel:
Nicht nur „wer darf rein“, sondern „was darf der Agent technisch tun“ – durch harte Schranken vor den Ziel-APIs.
✅ Leistet:
Reduziert Blast Radius (minimiert Missbrauchs-/Fehlerfolgen)
Verhindert offensichtlichen Missbrauch (z. B. verbotene Endpunkte/Methoden)
Erzwingt technische Leitplanken, z. B.:
Path/Method Allow-Lists (nur definierte Endpunkte, kein Admin/Bulk)
Request-Validierung (Schema, Content-Type, Größenlimits, erlaubte Felder)
Rate Limits / Abuse Controls (Write-Spikes, ungewöhnliche Muster)
Audit-Events pro Aktion (Rule-ID, Target, Zeit, Ergebnis)
❌ Leistet nicht:
Kein vollständiger Ersatz für fachliche Autorisierung: Confluence-APIs sind generisch; ein Gateway sieht Pfade/Payloads, aber oft nicht den gesamten fachlichen Kontext
Kein Ersatz für saubere Confluence-Rechte, getrennte technische Nutzer und menschliche Review-Prozesse
Wo „Allowed Actions“ besonders gut funktioniert (Praxis):
Draft-only Workflows (Agent schreibt nur Entwürfe)
Feste Spaces / klar definierte Bereiche (z. B. „Agent Drafts“)
Eng begrenzte Endpunkte (z. B. Create/Update Draft, kein Delete, kein Permissions-Mgmt)
Umsetzbar mit:
Cloudflare Worker / API-Gateway-Pattern (als Beispiel)
Alternativ: klassische API-Gateways/Proxies (z. B. Envoy/NGINX/Kong/Apigee/AWS API Gateway) – entscheidend sind Allow-Lists, Validierung, Rate Limits und Audit-Events, nicht der Hersteller.
Fazit: Kontrollierbarkeit schlägt „AI-Magie“
OpenClaw ist spannend, weil es nicht nur Inhalte generiert, sondern Actions ausführt. Genau deshalb entscheidet im Enterprise-Kontext nicht das Modell über das Risiko, sondern die Kontrollierbarkeit der Zugriffsschicht: Identitäten, Rechte, Token-Lebenszyklen, „Allowed Actions“ und Audit-Spuren.
Das 3-Ebenen-Referenzmodell hilft dabei, Agenten pragmatisch zu beherrschen:
Ebene 1 reduziert Exponierung (Outbound-only, keine direkten Inbound-Endpunkte).
Ebene 2 erzwingt Identität & Policy (ZTNA/Access, klare Service-Identitäten, Kill-Switch).
Ebene 3 begrenzt Aktionen (Allow-Lists, Validierung, Rate Limits, Audit-Events).
Wichtig: Das ist keine „Enterprise-Ready-Taste“. Es ist ein Rahmen, der den Betrieb messbar kontrollierbar macht – und damit Voraussetzung, um Use Cases verantwortungsvoll zu pilotieren.
JL.Digital GmbH.
AI-Agents sicher in die Praxis bringen – mit Confluence-Exzellenz
Wir verbinden Zukunftstechnologien (AI-Agents) mit Atlassian-Praxis (Confluence/Jira). Wir setzen Use Cases so um, dass sie kontrolliert, nachvollziehbar und auditierbar bleiben – mit klaren Rollen, minimalen Rechten, Draft-Workflows und Governance in Confluence.