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.

PowerShell, dieselbe Regel:

$env:KEON_API_KEY = "nsk_<agent-key>"   # the scoped agent key, and ONLY this
Remove-Item Env:DATABASE_URL -ErrorAction SilentlyContinue
# also: no personal `keon login` session (no %USERPROFILE%\.config\keon\credentials.json),
# no %APPDATA%\postgresql\pgpass.conf, 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.

Die Passwortdatei von libpq ist unter macOS und Linux ~/.pgpass, unter Windows aber %APPDATA%\postgresql\pgpass.conf (PGPASSFILE überschreibt beides). Prüfen Sie unter Windows diese Datei — ~/.pgpass wird dort nie gelesen.

Wenn Sie eine Passwortdatei für Ihre eigenen Sitzungen behalten, beschränken Sie sie auf Ihren Benutzer. Unter macOS und Linux ist das chmod 0600 ~/.pgpass; libpq ignoriert die Datei, wenn Gruppe oder andere irgendeinen Zugriff darauf haben. Unter Windows führt libpq keine solche Prüfung durch, daher ist die ACL der einzige Schutz. Entfernen Sie die geerbten Einträge und gewähren Sie nur sich selbst Zugriff:

icacls "$env:APPDATA\postgresql\pgpass.conf" /inheritance:r /grant:r "${env:USERNAME}:F"

In beiden Fällen hält das andere Benutzer fern. Einen Agenten, der als Sie läuft, hält es nicht fern — deshalb muss die Datei außerhalb der Reichweite des Agenten liegen, nicht nur privat sein.

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.