kisenon
Agent-Safe Change Control

Agent-Safe Change Control (ASCC)

The system that lets you point an AI agent at a real database safely — bounded, attributed, reviewed, reversible.

Live today. Every ASCC track is shipped and running — the last wave completed 2026-07-17 (cli-v0.1.46+). Capabilities keep maturing; tell us what breaks.

ASCC is Kisenon's agent-safety system. Sandboxing is one part of it. The claim, in one line: the only Postgres where an AI agent's changes are contained, reviewable, and reversible.

The moat is structural, not a checklist of features. cp is the sole writer to production, and promote is a single governed checkpoint every agent change funnels through — not a branch you can quietly merge around. Two guarantees hold beneath it, both deterministic, with no LLM in the trust path:

  • The agent connects with a scoped, non-superuser credential to a fork and never holds a credential that can write main.
  • Every statement is attributed to a read-only action log — the real SQL, not a summary.

The lifecycle

An agent change moves through five stages. This is the spine of everything below.

Enter safely → Work observably → Promote through a gate → Land reversibly → Prove it afterward.

What are you afraid of?

What are you afraid of?StageWhat stops it
It destroys dataPromote / LandLINT + POLICY + UNDO
It leaks PII into the agentEnterMASK
It takes prod down (locks, runaway)Enter + GateLEASH + BLAST
I can't tell what it didProveDIFF
I can't prove it laterProveLEDGER
The agent exceeds its laneEnterSCOPE
I can't undo a bad promoteLandUNDO
My schema-of-record driftsProveEMIT

The tracks

Each track is one guarantee. Grouped by the stage it belongs to.

Enter — how the agent gets in, bounded.

  • SCOPE — lane-derived grants; the credential can only touch its lane.
  • LEASH — per-sandbox budgets on statements, compute, and wall-clock.
  • MASK — masked forks; PII never enters the fork the agent sees.

See Guardrails and Masked forks.

Work — what you see while it runs.

  • capture + a live action log of every statement.
  • DIFF — a deterministic, human-readable diff of the change.
  • BLAST — a blast-radius dry-run: measured locks, durations, row counts.

See Sandboxes & promote.

Gate — what promote checks before it lands.

  • LINT — static risk classification of the statement set.
  • POLICY — per-project promote-policy tiers.

See Guardrails.

Land — how the change reaches main, reversibly.

  • promote — self-serve or human-approved.
  • UNDO — one-click reversible promote.
  • EMIT — deterministic up/down migrations.

See Sandboxes & promote.

Prove — what you can show afterward.

  • LEDGER — offline-verifiable signed attestations of what landed.

See Sandboxes & promote.

The invariant no feature weakens

Beneath every ASCC feature sit three hardcoded promote gates. No track ever relaxes them:

  • a green-verdict requirement — the change must have passed in the sandbox;
  • a volatile-guard — statements whose replay result can't be trusted are refused;
  • a fail-closed sequence-gap check — a gap in the attributed statement sequence blocks the promote rather than waving it through.

A feature can add friction on top. None can subtract these.

Start here

New to this? Start with Sandboxes & promote. Before you wire an agent up, read Common pitfalls — the anti-patterns that quietly defeat these guarantees.