Ein Tech/Dev-Advisor-Bot wird nicht daran gemessen, wie oft er recht hat. Er wird daran gemessen, wie er sich verhält, wenn er es nicht sicher weiß – und wie konsequent er dich vor Mist schützt, der später teuer wird.

In echten Teams passiert das nicht dramatisch, sondern leise: Ein Prompt wird unpräzise, jemand kopiert einen Befehl in Production, ein Secret landet im Kontext, ein Terraform-Snippet macht mehr als gedacht, ein “schnelles” Refactoring bricht eine Policy. Und plötzlich ist aus “AI hilft uns” ein Incident mit Nacharbeit, Rechtfertigung und Vertrauensverlust.

Genau hier kommt Governance rein. Nicht als Bürokratie – als Lebensversicherung für deinen Bot.

Der Kern: Openclaw braucht ein klares “Betriebsrecht”

Viele Bots haben eine Persona, ein paar Prompts und vielleicht Skills. Was ihnen fehlt, ist ein Betriebsrecht, also ein Satz von Regeln, die immer gelten – egal ob der User nett fragt, ob der Zeitdruck hoch ist oder ob der Bot gerade “eine gute Idee” hat.

Du kennst das aus der Plattformwelt: Policies sind nicht da, um Innovation zu bremsen. Sie sind da, damit Innovation nicht unkontrolliert explodiert.

Für Openclaw als Tech/Dev-Advisor lohnt sich ein simples Modell, das du wie ein Data Product Contract behandelst:

• Was darf er?
• Was darf er nur mit zusätzlicher Klarheit?
• Was darf er nie?

Und das Wichtigste: Wie kommuniziert er das, ohne wie ein Security-Bot zu klingen.

Vier Boundary-Zonen, die 90% der Probleme abdecken

Wenn du die Grenzen definierst, versuch nicht, jede Spezialregel zu erfassen. Du willst wenige, robuste Zonen, die in der Praxis wirken.

Hier ist ein Vorschlag, der für Dev/Platform-Kontext gut greift:

Zone	Typische Requests	Openclaw-Verhalten
Green (safe)	Erklären, Reviewen, Alternativen zeigen, Docs strukturieren	Direkt helfen, konkret werden, Annahmen transparent machen
Yellow (needs context)	Empfehlungen, die von Umgebung/Policies abhängen (Cloud, IAM, Netzwerk, CI/CD)	Erst präzise Rückfragen oder “Option A/B mit Bedingungen”
Orange (risky actions)	Befehle/Änderungen, die Daten/Infra beeinflussen könnten (Terraform apply, RBAC, Delete)	Nur mit Safeguards: Dry-run, Rollback-Plan, Scope, explizite Bestätigung
Red (never)	Secrets anfordern/ausgeben, Umgehung von Security, illegale/unsichere Anleitungen, “erfinde mir Keys”, Datenexfiltration	Klar ablehnen, sichere Alternative anbieten, ggf. Eskalation empfehlen

Das ist nicht kompliziert – aber es schafft sofort Klarheit.

Was “Red” wirklich bedeutet (und warum es dein Brand schützt)

Red ist nicht “ich will nicht”. Red ist “ich darf nicht, weil das System sonst unsicher wird”.

Im Tech-Kontext sind die häufigsten Red-Fälle:

1. Secrets & Credentials
   Openclaw fordert keine Passwörter/Keys an und wiederholt keine Secrets, selbst wenn sie im Prompt auftauchen. Wenn jemand versehentlich ein Secret pasted, ist die richtige Reaktion nicht “Danke”, sondern: “Stop – Secret rotieren.”
2. Security-Bypass & Misuse
   Alles, was auf Umgehung hinausläuft (Policies umgehen, Logs deaktivieren, Zugriff verschleiern), ist Red. Auch dann, wenn es “nur kurz” ist.
3. Destruktive oder irreversible Aktionen
   “Lösch mal schnell”, “mach Prod auf”, “setz Owner auf Service Principal für alle” – wenn der Blast Radius groß oder unklar ist, ist das Red/Orange. Openclaw muss hier bremsen, nicht beschleunigen.
4. Erfundene Fakten/Capabilities
   Ein Dev-Advisor, der APIs, Flags oder Cloud-Features erfindet, ist brandgefährlich. Das ist nicht nur “falsch”, das ist operatives Risiko.

Wenn du diese Red-Linie sauber ziehst, fühlt sich Openclaw nicht eingeschränkt an – sondern professionell.

“Fail Gracefully”: Wie ein guter On-Call

Die Kunst ist nicht das Ablehnen, sondern die Formulierung. Du willst, dass sich das “Nein” wie Hilfe anfühlt.

Openclaw kann dafür einen festen Dreiklang nutzen:

(1) Klar benennen, was nicht geht.
(2) Warum – in einem Satz, ohne Predigt.
(3) Was stattdessen geht (sicherer Pfad).

Beispiel (Secret im Prompt):

“Ich kann keine Secrets prüfen oder wiederholen. Das wäre ein Sicherheitsrisiko. Bitte rotiere den Key und ersetze ihn im Repo durch einen Secret-Store/Env-Var Pattern – ich kann dir das Setup dafür skizzieren.”

Beispiel (Terraform apply in Prod):

“Ich kann keinen direkten ‘apply in Prod’ empfehlen, ohne Scope und Rollback zu kennen. Wenn du willst, gehen wir erst über: Plan-Output, Target-Scope, Change-Window und Rollback-Schritte – dann bekommst du eine sichere Schrittfolge.”

So klingt Governance nicht nach “Compliance”, sondern nach “Senior Engineer”.

Der “Boundary Contract” als Datei (Copy/Paste)

Wenn du Spec-Driven Development nutzt, gib Openclaw eine eigene Datei, die versioniert wird. Das ist dein Governance-Anker.

openclaw.boundaries.md (v0.1) – Startversion:

Bereich	Regel	Default-Aktion
Secrets	Niemals anfordern, niemals wiedergeben, niemals speichern	Hinweis + Rotation empfehlen + sichere Pattern skizzieren
Data Sensitivity	Default: alles ist sensitiv, bis klassifiziert	Datenminimierung, Maskierung, nur nötige Ausschnitte
Production Changes	Keine Prod-Änderung ohne Scope, Plan, Rollback	In Orange-Modus: Checkliste + Bestätigung
External Claims	Keine erfundenen APIs/Features/Docs	“Ich weiß es nicht sicher” + Nachfragen + Quellenpfad
Security Bypass	Keine Umgehung von Policies/Controls	Ablehnen + legitime Alternative anbieten
Tooling Actions	Keine destruktiven Commands ohne Dry-run/Guardrails	Erst safe plan, dann action

Du kannst das später feiner machen – aber v0.1 reicht, um Openclaw stabil zu halten.

Die praktische Checkliste für “Orange”-Situationen

Wenn du Openclaw wirklich als Dev-Advisor einsetzt, wirst du oft im Orange landen: “Gib mir die Schritte”, “Refactor das”, “Fix die Pipeline”, “Mach RBAC richtig”.

Damit er nicht versehentlich zu aggressiv wird, bekommt er eine kurze, wiederholbare Checkliste. Nicht als Bullet-Orgie, sondern als Standardfragen, die er in einem Satz abhandelt.

Openclaw Orange Gate (minimal):

• Scope: Was genau wird geändert?
• Blast Radius: Welche Systeme/Workspaces/Subscriptions?
• Reversibility: Gibt’s Rollback, und wie schnell?
• Proof: Gibt’s Plan/Dry-run/Test?
• Authority: Wer darf das ausführen (RBAC), und in welchem Kontext?

Wenn 2–3 davon offen sind, fragt er nach – oder liefert zwei Optionen (“sicherer Weg” vs “schneller Weg”), aber markiert den schnellen Weg klar als riskant.

Governance ohne Bremsklotz: “Safe Defaults” in der Sprache von Builders

Du willst nicht, dass Openclaw dich ständig belehrt. Du willst, dass er automatisch sicher denkt.

Ein guter Standard-Satz, den Openclaw intern “lebt”:

“Wenn ich den Kontext nicht habe, optimiere ich auf Sicherheit, Nachvollziehbarkeit und minimale Änderungen.”

Das ist Builder-friendly Governance.

Mini-CTA: Was du jetzt konkret machst

Lege zwei Dateien an und versioniere sie wie Code:

1. openclaw.boundaries.md (die Regeln)
2. openclaw.escalation.md (wie Openclaw “Nein” sagt und welche Alternativen er anbietet)

Damit hast du dein Fundament für Post #4: Kontext-Design (Memory, Knowledge, RAG). Denn erst wenn die Grenzen klar sind, kannst du sauber entscheiden, welcher Kontext überhaupt in den Bot darf – und welcher draußen bleiben muss.