kisenon
Agent-Safe Change Control

Agent-Safe Change Control (ASCC)

Das System, mit dem Sie einen KI-Agenten sicher auf eine echte Datenbank richten können — begrenzt, zugeordnet, geprüft, umkehrbar.

Ab heute live. Jede ASCC-Bahn ist ausgeliefert und läuft — die letzte Welle wurde am 2026-07-17 abgeschlossen (cli-v0.1.46+). Die Fähigkeiten reifen weiter; sagen Sie uns, was kaputtgeht.

ASCC ist das Agentensicherheitssystem von Kisenon. Sandboxing ist ein Teil davon. Der Anspruch in einer Zeile: das einzige Postgres, bei dem die Änderungen eines KI-Agenten eingedämmt, prüfbar und umkehrbar sind.

Der Burggraben ist strukturell, keine Checkliste von Funktionen. cp ist der einzige Schreiber zur Produktion, und Promote ist ein einziger geregelter Prüfpunkt, durch den jede Agenten- Änderung geleitet wird — kein Branch, um den man sich still herummergen kann. Zwei Garantien halten darunter, beide deterministisch, mit keinem LLM im Vertrauenspfad:

  • Der Agent verbindet sich mit einer eingeschränkten, nicht-superuser Anmeldeinformation zu einem Fork und hält niemals eine Anmeldeinformation, die main schreiben kann.
  • Jede Anweisung wird einem schreibgeschützten Aktionsprotokoll zugeordnet — das echte SQL, keine Zusammenfassung.

Der Lebenszyklus

Eine Agenten-Änderung durchläuft fünf Stufen. Dies ist das Rückgrat von allem darunter.

Sicher eintreten → Beobachtbar arbeiten → Durch ein Gate promoten → Umkehrbar landen → Es danach beweisen.

Wovor haben Sie Angst?

Wovor haben Sie Angst?StufeWas es stoppt
Es zerstört DatenPromote / LandLINT + POLICY + UNDO
Es leakt PII in den AgentenEnterMASK
Es legt die Produktion lahm (Locks, Amoklauf)Enter + GateLEASH + BLAST
Ich kann nicht erkennen, was es tatProveDIFF
Ich kann es später nicht beweisenProveLEDGER
Der Agent überschreitet seine BahnEnterSCOPE
Ich kann ein schlechtes Promote nicht rückgängig machenLandUNDO
Mein Schema-of-Record driftet abProveEMIT

Die Bahnen

Jede Bahn ist eine Garantie. Gruppiert nach der Stufe, zu der sie gehört.

Enter — wie der Agent hineinkommt, begrenzt.

  • SCOPE — bahnabgeleitete Grants; die Anmeldeinformation kann nur ihre Bahn berühren.
  • LEASH — Pro-Sandbox-Budgets für Anweisungen, Compute und Wanduhr.
  • MASK — maskierte Forks; PII gelangt niemals in den Fork, den der Agent sieht.

Siehe Guardrails und Masked forks.

Work — was Sie sehen, während es läuft.

  • Erfassung + ein Live-Aktionsprotokoll jeder Anweisung.
  • DIFF — ein deterministisches, menschenlesbares Diff der Änderung.
  • BLAST — ein Explosionsradius-Trockenlauf: gemessene Locks, Dauern, Zeilenzahlen.

Siehe Sandboxes & promote.

Gate — was Promote prüft, bevor es landet.

  • LINT — statische Risikoklassifizierung des Anweisungssatzes.
  • POLICY — Pro-Projekt-Promote-Policy-Stufen.

Siehe Guardrails.

Land — wie die Änderung main erreicht, umkehrbar.

  • Promote — self-serve oder von Menschen genehmigt.
  • UNDO — Ein-Klick-umkehrbares Promote.
  • EMIT — deterministische up/down-Migrationen.

Siehe Sandboxes & promote.

Prove — was Sie danach zeigen können.

  • LEDGER — offline-verifizierbare signierte Attestierungen dessen, was gelandet ist.

Siehe Sandboxes & promote.

Die Invariante, die keine Funktion schwächt

Unter jeder ASCC-Funktion sitzen drei fest codierte Promote-Gates. Keine Bahn lockert sie jemals:

  • eine Grün-Verdikt-Anforderung — die Änderung muss in der Sandbox bestanden haben;
  • ein Volatile-Guard — Anweisungen, deren Replay-Ergebnis nicht vertrauenswürdig ist, werden abgelehnt;
  • eine fail-closed Sequenzlücken-Prüfung — eine Lücke in der zugeordneten Anweisungs- sequenz blockiert das Promote, statt es durchzuwinken.

Eine Funktion kann obendrauf Reibung hinzufügen. Keine kann diese subtrahieren.

Hier starten

Neu hier? Beginnen Sie mit Sandboxes & promote. Bevor Sie einen Agenten verkabeln, lesen Sie Common pitfalls — die Anti-Patterns, die diese Garantien still zunichtemachen.