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.

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.

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 1

Ogni 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.

"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.

FAQ

Cosa chiedono i team di piattaforma.

Perché gli agenti hanno bisogno di identità quando hanno già dei ruoli?

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.

Cos'è il problema degli agenti orfani?

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.

Come funziona il ciclo di vita?

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.

Cosa dimostra realmente l'attestazione?

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.

Come si integra con il nostro IAM?

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.

Registra il tuo primo agente in un minuto, localmente e gratuitamente — o parlaci di un rollout della flotta con SCIM e SPIFFE coinvolti.