Confier un identifiant cantonné à un agent

Ceci est le volet identifiant des bacs à sable d'agents IA : comment forger une clé qu'un agent peut détenir en toute sécurité, et comment la lui remettre sans laisser fuiter une clé plus puissante. Disponible dès aujourd'hui.

Un identifiant sûr pour un agent est une clé API Kisenon dotée de trois bornes — capacité, cantonnement et expiration — remise à l'agent dans un environnement propre. La règle en une ligne : cantonnez l'identifiant de l'agent, et ne laissez pas un plus puissant à sa portée.

1. Provisionner un identifiant d'agent cantonné

Forgez une clé API avec les trois dimensions définies :

• capability = agent — peut piloter les bacs à sable, mais keon connection-string main (et toute route en écriture sur main) renvoie 403. L'agent peut proposer des modifications ; il ne détient jamais un identifiant 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'impact borné en cas de fuite. Des jours, pas pour toujours.

Forgez-la dans la console — Paramètres → Clés API sur kisenon.com — avec Capacité = agent, Cantonnement = un projet et Expiration définie. Les clés API sont forgées depuis une session de navigateur authentifiée ; une simple clé CLI ne peut pas forger une autre clé. Utiliser 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 remettre correctement à l'agent

Donnez à l'agent sa clé cantonnée comme son unique identifiant, 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, les deux obligatoires :

• Cantonnez l'identifiant que vous remettez à l'agent (étape 1).
• Retirez les plus puissants qu'il pourrait sinon récupérer — une DATABASE_URL complète, un ~/.pgpass, ou une session keon connectée dans le même shell.

3. La boucle sûre

L'agent propose ; un humain — ou son propre promote borné — dispose :

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

keon sandbox run bifurque la branche, forge un jeton d'agent éphémère dans un home isolé, et injecte l'URL cantonnée de la bifurcation comme DATABASE_URL pour votre commande — de sorte que même une commande qui tente keon connection-string main à l'intérieur du bac à sable 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. Cantonner l'identifiant limite ce que vous remettez à l'agent ; cela ne contient pas un sous-processus qui a déjà accès au système de fichiers ou au réseau de l'hôte. Le confinement réel — un environnement nettoyé, aucun accès aux identifiants de l'hôte, une sortie limitée au point de terminaison du bac à sable — est une couche distincte. Ajoutez-la aussi lorsque le code de l'agent n'est pas de confiance.
• cp est le seul écrivain sur main. La promotion rejoue les instructions capturées côté serveur ; l'agent ne détient jamais d'identifiant en écriture sur main.

Bris de glace

Il n'y a pas d'interrupteur spécial de « bris de glace », par conception. Le chemin direct en écriture sur main n'est qu'un identifiant read_write normal détenu 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 promote et approve est attribué côté serveur.