Entregar a un agente una credencial acotada

Esta es la mitad de credenciales de Agent-Safe Change Control: cómo acuñar una clave que un agente pueda sostener de forma segura y entregarla sin filtrar una más potente. La mitad de aplicación — presupuestos, carriles, análisis de riesgo, política de promoción — es Salvaguardas. Disponible hoy.

Una credencial segura para un agente es una clave de API de Kisenon con tres límites — capacidad, alcance y expiración — entregada al agente en un entorno limpio. La regla en una línea: acote la credencial del agente y no deje una más potente donde el agente pueda alcanzarla.

1. Aprovisionar una credencial de agente acotada

Acuñe una clave de API con las tres dimensiones establecidas:

• capability = agent — puede operar sandboxes, pero keon connection-string main (y toda ruta con escritura en main) devuelve 403. El agente puede proponer cambios; nunca sostiene una credencial que escriba en producción.
• scope = project — confinada a un solo proyecto. Una filtración no puede alcanzar sus otros proyectos.
• expires_at (corto) — un radio de impacto acotado ante una filtración. Días, no para siempre.

Acúñela en la consola — Settings → API keys en kisenon.com — con Capability = agent, Scope = a project y Expires establecido. Las claves de API se acuñan desde una sesión de navegador con sesión iniciada; una clave de CLI simple no puede acuñar otra clave. Usar la clave en una ruta con escritura en main devuelve exactamente:

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

2. Entregarla al agente correctamente

Dé al agente su clave acotada como su única credencial, en un shell o contenedor limpio:

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.

Regla de dos partes, ambas obligatorias:

• Acote la credencial que entrega al agente (paso 1).
• Retire las más potentes que de lo contrario podría recoger — una DATABASE_URL completa, un ~/.pgpass o una sesión keon con sesión iniciada en el mismo shell.

3. El bucle seguro

El agente propone; un humano — o su propia promoción acotada — dispone:

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

keon sandbox run bifurca la rama, acuña un token de agente efímero en un home aislado e inyecta la URL acotada de la bifurcación como DATABASE_URL para su comando — de modo que incluso un comando que intente keon connection-string main dentro del sandbox choca con la clave de agente y obtiene 403. Revise el diff capturado y luego promocione según el promote_mode del proyecto:

Active la revisión humana con keon projects update --promote-mode human.

Qué es esto (y qué no)

• Una barrera de protección para un agente cooperativo, no una cárcel para código hostil. Acotar la credencial limita lo que entrega al agente; no contiene un subproceso que ya tiene acceso al sistema de archivos o a la red del host. La contención real — un entorno depurado, sin acceso a las credenciales del host, salida limitada al endpoint del sandbox — es una capa aparte. Añádala también cuando el código del agente no sea de confianza.
• cp es el único escritor en main. La promoción reproduce las sentencias capturadas del lado del servidor; el agente nunca sostiene una credencial con escritura en main.

Rotura de cristal

No hay un interruptor especial de «rotura de cristal», por diseño. La ruta directa con escritura en main es solo una credencial read_write normal en manos de un humano (keon connection-string main, o la consola) — deliberadamente inalcanzable desde la clave de agente. Para una ruta de incidente auditada, un operador usa su propia sesión read_write; cada promote y approve se atribuye del lado del servidor.