Policy zur Ausführungszeit schreiben, nicht zur Deploy-Zeit
Zugriffsentscheidungen, die bei Deploy festgelegt werden, sind veraltet, bis sie zählen. Wir werten den Policy-Graph in dem Moment aus, in dem ein Agent handelt. Das bringt Ihnen das.
Deploy-Zeit-Policy ist eine Momentaufnahme
Wenn Sie Zugriff zur Deploy-Zeit entscheiden, frieren Sie ein Bild der Welt ein und hoffen, dass es wahr bleibt. Aber Sponsoren wechseln, Agenten werden kompromittiert, Risikostufen verschieben sich. Bis der Agent handelt, kann die Momentaufnahme Wochen alt sein.
Ausführungszeit-Policy stellt die Frage genau dann, wenn sie wirklich zählt: dieser Agent, diese Aktion, dieser Scope, jetzt gerade. Die Antwort spiegelt den aktuellen Zustand des Graphen wider, nicht den Zustand beim letzten Deploy.
Autonomie, wo es sicher ist, Schranken, wo es das nicht ist
Auswertung zur Ausführungszeit erlaubt Ihnen, Entscheidungen nach Risiko zu bewerten. Freigaben mit geringem Risiko laufen autonom — der Agent wartet nie auf einen Menschen für etwas Routinemäßiges. Freigaben mit hohem Risiko, Geld und sensible Daten und neue externe Systeme, eskalieren zum namentlich benannten Sponsor.
Das Ergebnis ist kein Engpass. Die meisten Aktionen werden sofort freigegeben. Die wenigen, bei denen eine Person innehalten sollte, tun das tatsächlich, und jede Entscheidung — autonom oder mit Schranke — landet in einem attestierungsfähigen Protokoll.
- #Policy
- #Autorisierung
- #Laufzeit
More field notes
Kurzlebige Zugangsdaten in der Praxis
Alle sind sich einig, dass Keys ablaufen sollten. Dann setzt jemand die TTL auf ein Jahr, damit nichts kaputtgeht. So machen wir minutenlange Zugangsdaten alltagstauglich für echte Workloads.
Priya Nandakumar · Head of Platform
7 Min. Lesezeit
Null dauerhafte Keys: ein Migrationsleitfaden
Zu keinen langlebigen Secrets zu kommen ist ein Projekt, kein Schalter. Das ist die Reihenfolge, die wir empfehlen, und die Fallen in jeder Phase.
Priya Nandakumar · Head of Platform
9 Min. Lesezeit