Sandboxes & promote

Teil von Agent-Safe Change Control. Die keon sandbox- und keon ledger-Befehle sowie die hier beschriebene Konsolen-Sandboxes-Ansicht sind live — ein aktuelles keon ist erforderlich (cli-v0.1.46+).

Kisenon lässt Sie einem Coding-Agenten (Claude Code, Cursor, Ihrem eigenen) eine Datenbank übergeben, die er frei ändern kann — ohne die Produktion zu gefährden. Eine Sandbox ist ein Pro-Lauf-Fork Ihres Branches mit einer eingeschränkten Anmeldeinformation, einem Live-Aktionsprotokoll und einem serverseitigen Promote-Schritt. Diese Seite deckt die vollständige Schleife ab: erfassen → arbeiten → promoten → landen (umkehrbar) → beweisen.

Warum es sicher ist

Zwei Garantien, beide deterministisch — kein LLM sitzt im Vertrauenspfad:

• Der Agent kann die Produktion nicht berühren. Er verbindet sich mit einer eingeschränkten, nicht-superuser Anmeldeinformation zu einem Fork. Er hält niemals eine Anmeldeinformation, die main schreiben kann. Die Promotion läuft serverseitig und wendet nur Änderungen an, die bereits in der Sandbox bestanden haben.
• Sie sehen genau, was er tat. Jede Anweisung wird zugeordnet und an eine schreibgeschützte Konsole gestreamt — das echte SQL, keine Zusammenfassung.

Die Schleife

keon sandbox run \
  --migrate "alembic upgrade head" \
  --verify  "pytest tests/db"
# → green/red verdict + schema diff + a sandbox you can inspect

keon sandbox promote <id>   # cp applies the validated changes to main

Der Agent behält die Kontrolle über die Schleife; die Grenze ist es, die sie sicher macht.

Dauerhafte Erfassung

Das Aktionsprotokoll ist die Wahrheitsquelle für Promote, also muss es vollständig sein. Jede Sandbox trägt einen capture_state — ok oder lost. Wird die Erfassung jemals kompromittiert, kippt der Zustand auf lost und bleibt dort: eine verlorene Sandbox kann nicht promoten (409 sandbox_capture_lost) und wendet niemals still eine partielle Änderung an. Es gibt keine Auto-Heilung — verwerfen Sie sie und führen Sie die Arbeit in einer frischen Sandbox erneut aus. keon sandbox get / list zeigen die Erfassungsgesundheit.

Promote: self-serve oder von Menschen genehmigt

Jedes Projekt wählt einen promote_mode:

Explosionsradius-Trockenlauf

Bevor Sie promoten, können Sie die Plattform bitten, zu messen, was das Promote tun würde — echte Lock-Level, echte Lock-Halte-Dauern, echte Zeilenzahlen — statt aus dem Anweisungstext zu raten:

keon sandbox dry-run <id>

Die Plattform spielt den exakten Anweisungssatz der Sandbox gegen zwei kurzlebige Wegwerf-Forks des Elternteils ab — einen am aktuellen HEAD des Elternteils (wo Locks, Dauern und Zeilen gemessen werden) und einen am Fork-Punkt der Sandbox (die Divergenz-Baseline) — und zerstört dann beide. Es berührt niemals main, und der Agent erhält niemals eine Anmeldeinformation zu einem der Forks. Der Trockenlauf ist beratend: er erzeugt den Bericht, er blockiert niemals ein Promote.

Er beantwortet auch die Frage, die ein statisches Diff nicht kann: hat sich die Realität unter dem Agenten bewegt? Jede Anweisung, die einen Fehler wirft oder eine andere Anzahl von Zeilen betrifft, an Eltern-HEAD als am Fork-Punkt, wird als Konflikt aufgezeigt — z. B. ein UPDATE ... WHERE id = 2, dessen Zielzeile auf main nach dem Fork gelöscht wurde.

Der abgeschlossene Bericht trägt:

Die Endpunkte sind POST /v1/sandboxes/{id}/dry-run (startet einen asynchronen Lauf, 202) und GET /v1/sandboxes/{id}/dry-run (der neueste Datensatz). Ein fehlgeschlagener Trockenlauf trägt einen maschinenlesbaren error_code (capture_fence_failed, incomplete_capture, fork_failed, compute_unreachable, replay_infra_failed, timeout). Das Blast radius- Panel auf der Sandbox-Detailseite rendert denselben Bericht in der Konsole.

Ein Promote rückgängig machen

Ein Promote ist umkehrbar. Bevor cp die validierten Anweisungen auf main anwendet, verankert es den exakten Vor-Promote-Zustand des Eltern-Branches (eine LSN). Ein Befehl rollt den Branch zurück zu diesem Anker:

keon sandbox undo <id>   # restore the parent branch to its pre-promote state

Der Connection-String des Elternteils ist unverändert — Clients verbinden sich erneut mit demselben Endpunkt. Undo ist eine Owner/Admin-Aktion; Anmeldeinformationen mit Agenten-Fähigkeit werden abgelehnt (403 scope_insufficient), weil ein Undo verwirft, was auch immer auf dem Branch nach dem Anker gelandet ist.

keon sandbox get <id> trägt ein undo-Objekt — undoable, restored_lsn, undone_at und einen blocked_reason, wenn es nicht laufen kann (superseded_by_later_promote, already_undone). Undo zielt nur auf das jüngste Promote und lehnt mit 409 ab (sandbox_not_promoted, undo_anchor_missing, undo_anchor_invalidated), sobald der Anker weg ist. Es bleibt verfügbar, solange der Anker gültig ist und innerhalb Ihrer Speicher- Aufbewahrung — es gibt keinen separaten Countdown.

Undo stellt per LSN wieder her: es rollt alles nach dem Anker zurück, nicht nur die promotete Änderung — einschließlich direkter Writes und späterer Agenten-Sitzungen auf diesem Branch. Siehe Common pitfalls.

Emittierte Migrationen

Jedes gelandete Promote emittiert eine deterministische up/down-SQL-Migration — kein LLM, generiert aus der erfassten Schemaänderung und rundlauf-validiert auf einem Wegwerf-Fork, bevor es angeboten wird. Rufen Sie es ab:

keon sandbox migration <id> --out ./migrations --wait

Das Artefakt trägt das up- und down-SQL (files[], jede mit einer role), ein coverage-Flag (full oder partial), down_fidelity, etwaige uncovered_seqs, ein validation-Ergebnis und eine sha256. Terminale Zustände sind validated, validation_failed, emission_failed und no_schema_changes. v1 emittiert sql; GET /v1/sandboxes/{id}/migration (und .../migration/files/{role}) liefern es. Die Emission läuft, nachdem das Promote landet, und blockiert oder kehrt es niemals um — ein reines Daten-Promote meldet einfach no_schema_changes.

Signiertes Ledger

Jedes Promote und Undo hängt einen signierten, hash-verketteten Datensatz an ein Pro-Projekt-Ledger an — eine offline-verifizierbare Attestierung dessen, was sich geändert hat. Die Verifizierung braucht kein Netzwerk und vertraut Kisenon nicht:

keon ledger list --project <id>          # the chain (reports chain_ok)
keon ledger export <id> --out att.json   # one attestation document
keon ledger verify att.json              # offline; exit 0 iff valid
keon ledger keys --save                  # pin the signing keys you trust

keon ledger verify prüft die Ed25519-Signaturen und die Hash-Kette und meldet präzise Fehler (signature_invalid, statement_chain_mismatch, seq_gap, key_untrusted, chain_broken, …); Vertrauen ist dreiwertig (trusted / untrusted / unverified). Routen: GET /v1/sandboxes/{id}/ledger, GET /v1/projects/{projectId}/ledger, GET /v1/ledger/keys.

Hat cp keinen signierenden Schlüssel konfiguriert, gelingen Promotes weiterhin, sind aber unsigniert (ledger_enabled: false) — das Signieren ist nicht bedingungslos.

Was eine Sandbox nicht ist

• Keine Code-Sandbox — sie schränkt Ihre Datenbank ein, nicht den Prozess des Agenten.
• Kein LLM-Richter — Erfassung, Replay und Prüfung sind byte-deterministisch.

Probieren Sie es aus

Probieren Sie es aus auf kisenon.com und sehen Sie den quickstart.