Identità registrata
Ogni agente è un record: stable agent_id, ruolo, key binding Ed25519, data di creazione. Basta indovinare quale processo ha fatto cosa — il registro è la fonte di verità su chi esiste.
Enterprise · Governance degli Agent
I tuoi agenti hanno nomi e proprietari e un interruttore di spegnimento.
Entro il 2027, le flotte — e una flotta di processi anonimi è un rischio. LeanCTX rende ogni agente un identità registrata: unica, di proprietà umana, gestita nel ciclo di vita, attestata e revocabile — con ogni transizione nella traccia di audit a prova di manomissione.
Il modello
L'identità è chi risponde. Il ruolo è ciò che esegue.
I ruoli rimangono profili di permessi riutilizzabili. L'identità aggiunge la responsabilità: agent_id, owner, status, key binding, attestation, heartbeat. Quattro proprietà rendono una flotta governabile.
Di proprietà, sempre
La registrazione senza un proprietario umano viene rifiutata. La responsabilità è strutturale: ogni voce di audit, ogni evento del ciclo di vita, ogni bundle di prove fa riferimento a una persona che risponde per l'agente.
Revocabile in una transazione
Sospendi un agente, o disattiva un proprietario e sospendi l'intera sua flotta atomicamente — ogni sospensione è auditata individualmente. Il decommissioning è definitivo e scrive l'entrata di chiusura dell'audit.
Attestato, onestamente
Hash binari e del ruolo alla registrazione e ad ogni heartbeat. La deriva viene rilevata immediatamente (exit code 3) — aggiorna, modifica la configurazione o manomissione. Documentiamo ciò che questo NON protegge.
In pratica
Una flotta, cinque comandi.
Tutto è CLI-first e onesto riguardo agli exit code, così i tuoi pipeline e il tuo monitoraggio possono agire su di esso.
$ 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 1Ogni transizione scrive un'entrata di audit a prova di manomissione: registrato, sospeso, riattivato, dismesso sono tipi di evento standardizzati (OCP Part 4), quindi la cronologia delle identità viene automaticamente inserita nei tuoi pacchetti di prove. Modello completo del modello e della minaccia: documentazione agent-identity.
Every agent registered. Every action auditable.
"Cosa succede quando qualcuno se ne va?"
I loro agenti smettono di funzionare. Meccanicamente. L'eliminazione dell'utente proprietario sospende ogni agente attivo di quell'utente in una singola transazione bloccata, collegata al tuo flusso SCIM di deprovisioning o eseguita dalla checklist del dipendente che lascia. Gli agenti orfani sono gli account di servizio dimenticati dell'era degli agenti; LeanCTX li rende strutturalmente impossibili.
Cosa chiedono i team di piattaforma. ask.
Un ruolo dice cosa può fare un processo; un'identità dice chi ne è responsabile. Con le flotte, le domande importanti sono operative: chi possiede questo agente, quando era stato attivo l'ultima volta, chi lo ha spento e perché, cosa succede ai suoi permessi quando il proprietario se ne va? Il registro risponde meccanicamente a queste domande: identità (chi) rimane separata dal ruolo (cosa), in modo che i ruoli rimangano profili riutilizzabili.
Un agente di cui l'utente proprietario se n'è andato dall'azienda, ma che continua a funzionare con le sue credenziali: la versione dell'account di servizio dimenticato dell'era degli agenti, tranne che legge codice ed esegue comandi. LeanCTX chiude questa lacuna strutturalmente: i proprietari sono obbligatori al momento della registrazione e un singolo comando (o il tuo flusso SCIM di deprovisioning) sospende l'intera flotta attiva di un proprietario in una singola transazione bloccata, con ogni sospensione sottoposta ad audit.
attivo → sospeso ⇄ attivo → dismesso. La sospensione riporta un motivo ed è reversibile; lo smantellamento è definitivo per design: il record non viene mai cancellato e non viene mai riattivato, perché l'identità fa parte della cronologia di audit. Ogni transizione scrive un'entrata di audit a prova di manomissione utilizzando tipi di evento standardizzati (agent_registered, agent_suspended, agent_resumed, agent_decommissioned — OCP Part 4), in modo che i cambiamenti di identità appaiano automaticamente nei pacchetti di prove.
La registrazione e ogni heartbeat hashano il binario in esecuzione e il file del ruolo attivo. Un hash modificato significa che qualcosa è cambiato: un aggiornamento, una modifica della configurazione o un manomissione, e viene rilevato come deriva con un codice di uscita non zero su cui il tuo monitoraggio può avvisare. Si tratta di rilevamento di deriva, non di attestazione remota: un attaccante con pieno controllo dell'host può falsificare gli hash, e il nostro modello di minaccia lo afferma esplicitamente. Integra, ma non sostituisce, l'hardening dell'host e la firma del codice.
Tre hook. SPIFFE: ogni record mappa a spiffe://<trust-domain>/agent/<role>/<agent_id>, in modo che l'identità workload K8s (SPIRE) e quella LeanCTX siano lo stesso nome. SCIM: collega il tuo flusso di deprovisioning alla chiamata di eliminazione dell'utente proprietario. Modalità enforce: la check API è un singolo punto decisionale — agenti non registrati o sospesi sono negati; inizia in modalità monitor, passa a enforce una volta che la flotta è stata registrata.
Governa la forza lavoro degli agenti.agent workforce.
Registra il tuo primo agente in un minuto, localmente e gratuitamente — o parlaci di un rollout della flotta con SCIM e SPIFFE coinvolti.