Einem Agenten eine eingeschränkte Anmeldeinformation übergeben

Dies ist die Anmeldeinformations-Hälfte von Agent-Safe Change Control: wie man einen Schlüssel prägt, den ein Agent sicher halten kann, und ihn übergibt, ohne einen stärkeren preiszugeben. Die Durchsetzungs-Hälfte — Budgets, Bahnen, Risiko-Lint, Promote- Policy — ist Guardrails. Ab heute verfügbar.

Eine agentensichere Anmeldeinformation ist ein Kisenon-API-Schlüssel mit drei Grenzen — Fähigkeit, Geltungsbereich und Ablauf — der dem Agenten in einer sauberen Umgebung übergeben wird. Die Regel in einer Zeile: Schränken Sie die Anmeldeinformation des Agenten ein, und lassen Sie keine stärkere dort, wo der Agent sie erreichen kann.

1. Eine eingeschränkte Agenten-Anmeldeinformation 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 niemals eine Anmeldeinformation, die die Produktion schreibt.
• scope = project — auf ein Projekt beschränkt. Ein Leck kann Ihre anderen Projekte nicht erreichen.
• expires_at (kurz) — ein begrenzter Explosionsradius bei einem Leck. Tage, nicht für immer.

Prägen Sie ihn in der Konsole — Settings → API keys unter kisenon.com — mit Capability = agent, Scope = a project und gesetztem Expires. API-Schlüssel werden aus einer angemeldeten Browser-Sitzung geprägt; ein einfacher CLI-Schlüssel kann keinen weiteren Schlüssel prägen. Die Verwendung des Schlüssels auf einer in main schreibbaren Route gibt genau zurück:

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

2. Übergeben Sie sie dem Agenten korrekt

Geben Sie dem Agenten seinen eingeschränkten Schlüssel als seine einzige Anmeldeinformation, in einer sauberen Shell oder einem sauberen 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:

• Schränken Sie die Anmeldeinformation ein, die Sie dem Agenten übergeben (Schritt 1).
• Entfernen Sie die stärkeren, die er andernfalls aufgreifen 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 eingeschränkte URL des Forks als DATABASE_URL für Ihren Befehl — sodass selbst ein Befehl, der keon connection-string main innerhalb der Sandbox versucht, auf den Agenten-Schlüssel trifft und 403 erhält. Prüfen Sie das erfasste Diff und promoten Sie dann gemäß dem promote_mode des Projekts:

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

Was dies ist (und was nicht)

• Ein Schutzgeländer für einen kooperierenden Agenten, kein Gefängnis für feindlichen Code. Das Einschränken der Anmeldeinformation begrenzt, was Sie dem Agenten übergeben; es enthält keinen Subprozess, der bereits Zugriff auf das Host-Dateisystem oder Netzwerk hat. Echte Eindämmung — eine bereinigte Umgebung, kein Zugriff auf Host-Anmeldeinformationen, 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 zu main. Die Promotion spielt die erfassten Anweisungen serverseitig ab; der Agent hält niemals eine in main schreibbare Anmeldeinformation.

Break-Glass

Es gibt bewusst keinen speziellen „Break-Glass"-Schalter. Der direkte in main schreibbare Pfad ist einfach eine normale read_write-Anmeldeinformation, die von einem Menschen gehalten wird (keon connection-string main oder die Konsole) — vom Agenten-Schlüssel aus bewusst unerreichbar. Für einen auditierten Vorfallspfad verwendet ein Operator seine eigene read_write-Sitzung; jedes Promote und Approve wird serverseitig zugeordnet.