Claude Code Permission Risk Register: Erlaubnisse festlegen, bevor der Agent handelt

Warum ein eigenes Artefakt nötig ist

Dieser Artikel baut ein Permission Risk Register für Teams, die von Solo-Nutzung zu gemeinsamen Approval-Regeln wechseln. Der häufige Fehler ist einfach: das Team diskutiert Rechte erst, nachdem der Agent editiert, deployed oder einen riskanten Befehl angefordert hat. Ein Claude-Code-Workflow endet nicht bei einer selbstsicheren Antwort. Er braucht ein Artefakt, das eine andere Person prüfen kann. Hier ist das ein kleines Register mit Aktion, Standardentscheidung, Nachweis und Owner.

Behandle das Artefakt als Vertrag zwischen Prompt, Kommandozeile und öffentlicher Seite. Es zeigt, was Claude Code gelesen hat, was geändert wurde, welcher Befehl den Erfolg beweist und welchen Umsatzpfad der Leser danach sieht. Darum gehört es zu harness engineering, getting started und permissions.

Der operative Loop

Der Loop hat fünf Schritte: Aktion definieren, Nachweis wählen, Claude Code die kleinste nützliche Arbeit machen lassen, Output prüfen und die nächste Umsatzaktion notieren. Der Nachweis ist hier nicht nur “Code läuft”. Beobachte Approval-Zahl, abgelehnte Befehle, Rollback-Notizen, Deploy-Nachweis und Beratungsabsicht. Wenn diese Felder sichtbar sind, verbesserst du ohne Raten.

1. Read-only Repo-Mapping kann erlaubt sein, wenn die Abschlussnotiz die gelesenen Bereiche nennt.

2. Content-Edits sind vertretbar, wenn Diff-Review, Build und öffentliche URL Pflicht sind.

3. Secrets, Billing, Kundendaten und Force Push bleiben Owner-approved, selbst wenn der Agent treffsicher ist.

Kopierbarer Starter

permission_risk_register:
  - action: "read repository files"
    default: "allow"
    proof: "list files read in the final note"
  - action: "edit content files"
    default: "allow after diff review"
    proof: "build passes and URL matches the slug"
  - action: "deploy production"
    default: "ask first"
    proof: "build log, deploy URL, rollback note"
  - action: "touch secrets or billing"
    default: "never without owner approval"
    proof: "human approval id"

Drei Praxisbeispiele

Beispiel 1. Read-only Repo-Mapping kann erlaubt sein, wenn die Abschlussnotiz die gelesenen Bereiche nennt.

Beispiel 2. Content-Edits sind vertretbar, wenn Diff-Review, Build und öffentliche URL Pflicht sind.

Beispiel 3. Secrets, Billing, Kundendaten und Force Push bleiben Owner-approved, selbst wenn der Agent treffsicher ist.

Self-Review-Checkliste

Bevor dieser Workflow zur Gewohnheit wird, prüfe den Artikel wie eine Release Note. Der erste Check ist Scope: Leser müssen wissen, wann ein Permission Risk Register sinnvoll ist und wann eine kleinere Checkliste reicht. Der zweite Check ist Nachweis: Jede Empfehlung sollte auf Befehl, URL, Diff oder Metrik zeigen. Der dritte Check ist Routing: kostenloses PDF, Gumroad-Guide und Beratung sollen nicht konkurrieren, sondern unterschiedliche Dringlichkeiten beantworten.

Nutze eine kleine Ownership-Regel. Eine Person besitzt das Artefakt, eine die Verifikation und eine das nächste CTA-Experiment. Im Solo-Workflow kann das dieselbe Person sein, aber die Rollen sollten im Hinweis benannt werden. So behandelt Claude Code Publishing, Messen und Verkaufen nicht als eine verschwommene Aufgabe. Der nächste Lauf weiß außerdem, wo er fortsetzen soll.

Die praktische Frage lautet: Was macht diesen Artikel morgen früh leichter prüfbar? Ist die Antwort ein Screenshot, speichere ihn. Ist es ein stärkerer Prompt, kommt er in das Prompt Pack. Ist es eine klarere Grenze, gehört sie in die Setup-Notizen. ein kleines Register mit Aktion, Standardentscheidung, Nachweis und Owner ist nur nützlich, wenn es die nächste Sitzung übersteht.

Fehlerfälle

Der erste Fehler ist, Pageviews als einzigen Score zu behandeln. Der zweite ist Approval ohne Proof-Befehl. Der dritte ist, jeden Leser zum gleichen Kaufprodukt zu schicken, obwohl PDF oder Beratung besser passt. Schreibe die Routing-Regel, bevor du den CTA änderst.

Umsatzpfad

Route nach Engpass. Bei fehlender Command-Sicherheit passt das kostenlose PDF oder das kostenlose Gumroad-Cheatsheet. Bei wiederholter Arbeit passen 50 Prompt Templates oder Setup Guide. Bei Rollout, Risiko oder Umsatzdesign passt Beratung. Für diesen Artikel gilt: der Setup Guide liefert die Policy-Basis, Beratung hilft bei Production- und Revenue-Approvals.

Verifikationsmetriken

Nach dem Publishing reicht HTTP 200 nicht. Prüfe h1, canonical, hero image, Einstiegstext, CTA-Links, mobile layout und Sprache. Danach beobachte Approval-Zahl, abgelehnte Befehle, Rollback-Notizen, Deploy-Nachweis und Beratungsabsicht. Wenn nichts steigt, verbessere zuerst den CTA beim ersten konkreten Beispiel.