Einem Agenten ein begrenztes Credential übergeben

Stellen Sie einen nach Capability, Projekt und Ablauf begrenzten API-Schlüssel bereit und lassen Sie einen KI-Agenten sicher gegen Ihre Datenbank laufen.

Dies ist die Credential-Hälfte der KI-Agent-Sandboxes: wie man einen Schlüssel prägt, den ein Agent sicher halten kann, und wie man ihn übergibt, ohne einen stärkeren zu verlieren. Ab heute verfügbar.

Ein agentensicheres Credential ist ein Kisenon-API-Schlüssel mit drei Grenzen — Capability, Scope und Ablauf — der dem Agenten in einer sauberen Umgebung übergeben wird. Die Regel in einem Satz: begrenzen Sie das Credential des Agenten und lassen Sie kein stärkeres dort, wo der Agent es erreichen kann.

1. Ein begrenztes Agenten-Credential bereitstellen

Prägen Sie einen API-Schlüssel mit allen drei Dimensionen gesetzt:

capability = agent — kann Sandboxes steuern, aber keon connection-string main (und jede in main schreibbare Route) gibt 403 zurück. Der Agent kann Änderungen vorschlagen; er hält nie ein Credential, das in die Produktion schreibt.
scope = project — auf ein Projekt beschränkt. Ein Leck kann Ihre anderen Projekte nicht erreichen.
expires_at (kurz) — ein begrenzter Wirkungsradius bei einem Leck. Tage, nicht für immer.

Prägen Sie ihn in der Konsole — Einstellungen → API-Schlüssel unter kisenon.com — mit Capability = agent, Scope = ein Projekt und gesetztem Ablauf. API-Schlüssel werden aus einer angemeldeten Browsersitzung geprägt; ein einfacher CLI-Schlüssel kann keinen weiteren Schlüssel prägen. Wird der Schlüssel auf einer in main schreibbaren Route verwendet, gibt er genau dies zurück:

agent-scoped API keys cannot retrieve data-plane credentials or perform
branch-admin role/database operations; use the sandbox flow

2. Ihn korrekt an den Agenten übergeben

Geben Sie dem Agenten seinen begrenzten Schlüssel als sein einziges Credential, in einer sauberen Shell oder einem Container:

export KEON_API_KEY=nsk_<agent-key>   # the scoped agent key, and ONLY this
unset DATABASE_URL                    # no full connection string in the env
# also: no personal `keon login` session (no ~/.config/keon/credentials.json),
# no ~/.pgpass, no admin DATABASE_URL reachable from the agent's process.

Zweiteilige Regel, beide erforderlich:

Begrenzen Sie das Credential, das Sie dem Agenten übergeben (Schritt 1).
Entfernen Sie die stärkeren, die er sich sonst greifen könnte — eine vollständige DATABASE_URL, eine ~/.pgpass oder eine angemeldete keon-Sitzung in derselben Shell.

3. Die sichere Schleife

Der Agent schlägt vor; ein Mensch — oder sein eigenes begrenztes Promote — entscheidet:

keon sandbox run \
  --migrate "alembic upgrade head" \
  --verify  "pytest tests/db"

keon sandbox run forkt den Branch, prägt ein kurzlebiges Agenten-Token in ein isoliertes Home und injiziert die begrenzte URL des Forks als DATABASE_URL für Ihren Befehl — sodass selbst ein Befehl, der innerhalb der Sandbox keon connection-string main versucht, auf den Agentenschlüssel trifft und 403 erhält. Prüfen Sie das erfasste Diff und promoten Sie dann gemäß dem promote_mode des Projekts:

`promote_mode`	Who commits to `main`
`self` (default)	Der Agent führt `keon sandbox promote <id>` aus, sobald seine Prüfungen bestehen.
`human`	Der Agent schlägt vor; ein Owner/Admin führt `keon sandbox approve <id>` aus, nachdem er Diff + Log geprüft hat.

Aktivieren Sie die menschliche Prüfung mit keon projects update --promote-mode human.

Was das ist (und was nicht)

Eine Leitplanke für einen kooperierenden Agenten, kein Gefängnis für feindseligen Code. Das Begrenzen des Credentials schränkt ein, was Sie dem Agenten übergeben; es fängt keinen Subprozess ein, der bereits Zugriff auf das Host-Dateisystem oder Netzwerk hat. Echte Eindämmung — eine bereinigte Umgebung, kein Zugriff auf Host-Credentials, auf den Sandbox-Endpunkt begrenzter Egress — ist eine separate Schicht. Fügen Sie sie ebenfalls hinzu, wenn der Code des Agenten nicht vertrauenswürdig ist.
cp ist der einzige Schreiber auf main. Das Promoten spielt die erfassten Anweisungen serverseitig ab; der Agent hält nie ein in main schreibbares Credential.

Break-Glass

Es gibt bewusst keinen speziellen „Break-Glass"-Schalter. Der direkte in main schreibbare Pfad ist nur ein normales read_write-Credential in der Hand eines Menschen (keon connection-string main oder die Konsole) — vom Agentenschlüssel aus absichtlich unerreichbar. Für einen auditierten Vorfallpfad verwendet ein Operator seine eigene read_write-Sitzung; jedes Promote und Approve wird serverseitig zugeordnet.