Confier à un agent une identification à portée limitée

Ceci est le volet identification de Agent-Safe Change Control : comment forger une clé qu'un agent peut détenir en toute sécurité, et la lui transmettre sans en divulguer une plus puissante. Le volet application — budgets, couloirs, lint de risque, politique de promotion — est Guardrails. Disponible aujourd'hui.

Une identification sûre pour un agent est une clé API Kisenon assortie de trois bornes — capacité, portée et expiration — remise à l'agent dans un environnement propre. La règle en une ligne : limitez la portée de l'identification de l'agent, et ne laissez pas traîner une identification plus puissante à sa portée.

1. Provisionner une identification d'agent à portée limitée

Forgez une clé API dont les trois dimensions sont fixées :

• capability = agent — peut piloter des sandboxes, mais keon connection-string main (et toute route en écriture sur main) renvoie 403. L'agent peut proposer des changements ; il ne détient jamais d'identification qui écrit en production.
• scope = project — confiné à un seul projet. Une fuite ne peut pas atteindre vos autres projets.
• expires_at (court) — un rayon d'explosion borné en cas de fuite. Des jours, pas l'éternité.

Forgez-la dans la console — Settings → API keys sur kisenon.com — avec Capability = agent, Scope = un projet et Expires défini. Les clés API sont forgées à partir d'une session de navigateur authentifiée ; une simple clé CLI ne peut pas forger une autre clé. L'utilisation de la clé sur une route en écriture sur main renvoie exactement :

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

2. La transmettre correctement à l'agent

Donnez à l'agent sa clé à portée limitée comme seule identification, dans un shell ou un conteneur propre :

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.

Règle en deux parties, toutes deux requises :

• Limiter la portée de l'identification que vous remettez à l'agent (étape 1).
• Retirer les plus puissantes qu'il pourrait autrement récupérer — un DATABASE_URL complet, un ~/.pgpass, ou une session keon connectée dans le même shell.

3. La boucle sûre

L'agent propose ; un humain — ou sa propre promotion bornée — dispose :

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

keon sandbox run fork la branche, forge un jeton d'agent éphémère dans un home isolé, et injecte l'URL à portée limitée du fork comme DATABASE_URL pour votre commande — de sorte que même une commande qui tente keon connection-string main à l'intérieur du sandbox tombe sur la clé d'agent et obtient 403. Examinez le diff capturé, puis promouvez selon le promote_mode du projet :

Activez la revue humaine avec keon projects update --promote-mode human.

Ce que c'est (et ce que ce n'est pas)

• Un garde-fou pour un agent coopératif, pas une prison pour du code hostile. Limiter la portée de l'identification borne ce que vous remettez à l'agent ; cela ne contient pas un sous-processus qui a déjà accès au système de fichiers hôte ou au réseau. Un véritable confinement — un environnement nettoyé, aucun accès aux identifications de l'hôte, une sortie limitée au point de terminaison du sandbox — est une couche distincte. Ajoutez-la aussi lorsque le code de l'agent n'est pas de confiance.
• cp est le seul rédacteur sur main. La promotion rejoue les instructions capturées côté serveur ; l'agent ne détient jamais d'identification en écriture sur main.

Bris de glace

Il n'existe pas de mécanisme spécial de « bris de glace », par conception. Le chemin direct en écriture sur main n'est qu'une identification read_write ordinaire détenue par un humain (keon connection-string main, ou la console) — délibérément inaccessible depuis la clé d'agent. Pour un chemin d'incident audité, un opérateur utilise sa propre session read_write ; chaque promotion et approbation est attribuée côté serveur.