Identité enregistrée
Chaque agent est un enregistrement : agent_id stable, rôle, liaison clé Ed25519, date de création. Fini les suppositions sur le processus qui a fait quoi — le registre est la source de vérité pour savoir qui existe.
Dès 2027, les flottes — et une flotte de processus anonymes est un passif. LeanCTX fait de chaque agent une identité enregistrée: unique, détenue par un humain, gérée dans son cycle de vie, attestée et révocable — avec chaque transition dans la piste d'audit inviolable.
Les rôles restent des profils de permissions réutilisables. L'identité y ajoute la responsabilité : agent_id, propriétaire, statut, liaison clé, attestation, battement de cœur. Quatre propriétés rendent une flotte gérable.
Chaque agent est un enregistrement : agent_id stable, rôle, liaison clé Ed25519, date de création. Fini les suppositions sur le processus qui a fait quoi — le registre est la source de vérité pour savoir qui existe.
L'enregistrement sans propriétaire humain est rejeté. La responsabilité est structurelle : chaque entrée d'audit, chaque événement de cycle de vie, chaque paquet de preuves remonte à une personne qui répond pour l'agent.
Suspendre un agent, ou retirer un propriétaire et suspendre toute sa flotte de manière atomique — chaque suspension est auditée individuellement. Le décommissionnement est définitif et écrit l'entrée de clôture d'audit.
Hashes binaires et de rôle à l'enregistrement et à chaque battement de cœur. La dérive apparaît immédiatement (code de sortie 3) — mise à niveau, modification de configuration ou falsification. Nous documentons ce que cela ne protège PAS.
Tout est conçu pour la CLI et honnête en code de sortie, afin que vos pipelines et votre surveillance puissent agir dessus.
$ lean-ctx agent register --id ci-reviewer-1 --role reviewer --owner alice@org registered: ci-reviewer-1 (role reviewer, owner alice@org) spiffe id: spiffe://org.example/agent/reviewer/ci-reviewer-1 $ lean-ctx agent heartbeat ci-reviewer-1 # liveness + drift; exit 3 on drift $ lean-ctx agent offboard-owner alice@org --reason "left company" suspended 2 agent(s): ci-coder-1, ci-reviewer-1 $ lean-ctx agent check ci-reviewer-1 # enforce-path decision point ci-reviewer-1: DENIED — suspended: left company # exit 1
Chaque transition écrit une entrée d'audit inviolable — enregistré, suspendu, repris, décommissionné sont des types d'événements standardisés (OCP Part 4), de sorte que l'historique d'identité arrive automatiquement dans vos paquets de preuves. Modèle et modèle de menace complets : docs sur l'identité des agents.
"Que se passe-t-il quand quelqu'un part ?"
Leurs agents s'arrêtent. Mécaniquement. Le retrait d'un propriétaire suspend chaque agent actif de ce propriétaire en une seule transaction verrouillée — connecté à votre flux de déprovisionnement SCIM ou exécuté depuis la liste de contrôle du départ. Les agents orphelins sont les comptes de service oubliés de l'ère des agents ; LeanCTX les rend structurellement impossibles.
Un rôle indique ce qu'un processus peut faire ; une identité indique qui en est responsable. Avec les flottes, les questions importantes sont opérationnelles : qui possède cet agent, quand était-il actif pour la dernière fois, qui l'a arrêté et pourquoi, que devient ses permissions lorsque son propriétaire part ? Le registre y répond mécaniquement — l'identité (qui) reste séparée du rôle (quoi), de sorte que les rôles restent des profils réutilisables.
Un agent dont le propriétaire humain a quitté l'entreprise mais qui continue de fonctionner avec ses identifiants — la version de l'ancien compte de service oublié, sauf qu'il lit du code et exécute des commandes. LeanCTX y remédie structurellement : les propriétaires sont obligatoires lors de l'enregistrement, et une seule commande (ou votre flux de déprovisionnement SCIM) suspend toute flotte active d'un propriétaire en une transaction verrouillée unique, chaque suspension étant auditée.
actif → suspendu ⇄ actif → mis hors service. La suspension porte une raison et est réversible ; la mise hors service est définitive par conception — l'enregistrement n'est jamais supprimé ni réactivé, car l'identité fait partie de l'historique d'audit. Chaque transition écrit une entrée d'audit non falsifiable en utilisant des types d'événements standardisés (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Part 4), de sorte que les changements d'identité apparaissent automatiquement dans les paquets de preuves.
L'enregistrement et chaque hash de battement cardiaque hachent le binaire en cours d'exécution et le fichier de rôle actif. Un hash modifié signifie que quelque chose a changé — une mise à niveau, une modification de configuration ou un piratage — et apparaît comme une dérive avec un code de sortie non nul sur lequel votre surveillance peut alerter. Il s'agit de la détection de dérive, pas d'attestation à distance : un attaquant ayant le contrôle total de l'hôte peut falsifier les hashes, et notre modèle de menace le stipule explicitement. Cela complète, sans remplacer, le durcissement de l'hôte et la signature de code.
Trois hooks. SPIFFE : chaque enregistrement est mappé à spiffe://<trust-domain>/agent/<role>/<agent_id>, de sorte que l'identité des charges de travail K8s (SPIRE) et celle de LeanCTX sont le même nom. SCIM : reliez votre flux de déprovisionnement à l'appel de départ du propriétaire. Mode d'application : l'API de vérification est un point de décision unique — les agents non enregistrés ou suspendus sont refusés ; commencez en mode moniteur, passez au mode d'application une fois que la flotte est enregistrée.
Enregistrez votre premier agent en une minute, localement et gratuitement — ou parlez-nous du déploiement de flottes avec SCIM et SPIFFE en jeu.